Release and release candidate FAQs (expanded branching model)

What happens if I add commits to an included feature branch?

When a feature is merged into a release branch, it should be in a tested, verified and ready-to-release state. Due to this, unlike the classic promotion branch behavior explained here, Pipelines won't automatically layer on extra commits made to the original feature branch into a release branch.

To include the new commits:

Before promotion for both release and release candidate: Remove the feature and add it again. You may also need to remove features added to a release or release candidate after it because removal follows merge order. See Add or remove features from a release or release candidate.
After promoting a release candidate to the final environment: The release candidate becomes a release, and you can no longer remove its features but can only abandon and recreate it. To include commits added to the original feature branches, abandon the resulting release and create it again using the updated branches.

If you promote the release branch before abandoning/recreating to include the new changes to the feature branch, a special Sync PR will open against that final environment to pull in the missing change.

Can I rename a release or release candidate?

You can rename the release pull request manually in your version control provider. It can’t be renamed from within Gearset.

Alternatively, you can abandon the release and re-create it with a new name. Read more about abandoning the release here.

What happens when a release is promoted?

When a release is promoted to Production:

Gearset uses the validated package created from the release branch.
The promotion starts manually or at its scheduled time.
The release branch is merged into main or master.
The merge triggers the delta CI deployment from main or master to the Production org.
Gearset uses quick deploy when the validated package is still eligible.

Quick deploy depends on whether the target org (Prod) has changed since the original validation. Changes from another deployment or changes made directly in the org can make the package ineligible, so Quick deployability is not guaranteed..

When a release candidate is promoted from the penultimate environment, it first appears as a release in the final environment. The process above applies when that resulting release is promoted to Production.

Note about back propagation after Release deployment

Back Propagation Releases will back-propagate releases as a single PR.

As a best practice we recommend syncing up all environments to your default base branch (main/master) after a release. This is to prevent unexpected differences in future pull requests.

What should I do before moving to another data region?

Before moving a pipeline to another data region, abandon any active releases and release candidates in that pipeline.

Release packages only work in the data region where they were created. After switching regions, recreate the pipeline and any required release packages.

Why can’t Gearset add features to my release?

You may see the following error:

Gearset couldn't merge these features into the release branch automatically due to a feature tracking failure. Please contact us via the in-app chat for help with this issue.

This can happen when the package was created in one data region but you’re attempting to add features while working in another. For example, creating the release in the EU region and later accessing it from the US region.

Contact Gearset Support through the in-app chat and include a screenshot of the error.