License requirements:
Releases are available to teams on any Automation tier.
Release candidates is available to teams on the Automation Enterprise tier.
Teams release changes to Production in different ways. Some promote features individually and release on demand, while others work to a regular cadence and combine multiple features into a single release. Gearset supports both individual and cadence-based delivery through releases and release candidates. Cadence-based allow teams to group features, identify merge conflicts, validate the combined package and test it before deployment.
This article explains how releases and release candidates fit into the pipeline workflow and helps you choose the right approach for your team.
If you are looking to learn about Releases in Gitflow, you'll want to go here.
How releases and release candidates relate
A release combines multiple features into a single package in the final environment, where it can be validated and deployed to Production.
A release candidate combines and tests those features earlier, in a nominated penultimate environment. It is an optional stage in the release lifecycle, rather than a separate deployment process. When promoted, Gearset automatically creates the corresponding release in the final environment.
Both supported workflows therefore produce a release in the final environment, you can either create it there directly or create and test it first as a release candidate.
How do these differ from Bundles?
A bundle is different from a release or release candidate:
It's created at a single environment earlier in your pipeline, typically where parallel work streams converge, rather than your final or penultimate environment.
It isn't representative of everything going to production, only the subset of related features you've chosen to combine at that environment.
It's promoted down your pipeline like any other PR, and can eventually become part of a release candidate or release later on, alongside other features, bundles, or projects.
For more on bundles, see our Bundles documentation.
Which workflow should you use?
Use a release candidate when
You regularly use releases to manage deployments to your production environment, and you have a production-like penultimate environment on which you do final testing of a release today. Creating a release candidate on this environment will give you a standardised way of creating, validating and deploying this as a single consistent package before it goes to production:
Combine the features into a release candidate in the nominated penultimate environment.
Validate and test the complete package there.
Promote it as a single package. Gearset automatically creates the corresponding release in the final environment.
Validate and deploy the release to Production.
Create the release in the final environment when
The penultimate environment is a standard UAT environment, where significant testing occurs and changes to the final package are common. We recommend promoting features individually and compiling the final release in Production using the releases functionality:
Promote features individually through the earlier pipeline environments.
Combine them into a release in the final environment.
Validate and deploy the release to Production.
Note: As best practice, it's recommended to manage and promote releases in Gearset rather than in your version control system.