1. How do I abandon my release?
You can abandon a release at different points depending in your pipeline.
The release PR has not be opened against production
Open the release node and select the Abandon button:
Choose whether you want to delete the release branch, then select Abandon to confirm:
The release PR is already open against production
Select your production environment and open the Releases tab:
Select the menu next to Deploy release and choose Close release PR:
The release will still appear on your release node. If you want to fully remove it, follow the steps described in The release PR has not been opened against production.
2. What do I do if I need to make a fix on my release branch?
💡
This workflow will be brought into the Gitflow Pipelines UI in an upcoming slice of work. The following steps are the recommended interim approach.
Sometimes issues are discovered during testing of a release branch, such as failures in UAT, unexpected integration behaviour, or missing components. In these cases, you may need to add more changes to your open release.
There are two recommended approaches:
C&D: Direct Commits
Note the name of your release branch (
gs-gitflow-release/<GUID>) shown at the top of the release node. This is the branch you will commit to:
Using Gearset’s C&D, select the release branch as your target, and use a sandbox (ideally one from your Integration stage to ensure the correct metadata baseline) as the source:
Work through the C&D flow:
Select the required fixes
Review any Problem Analysis results
Link tickets if needed
Commit the changes into the release branch
After committing:
The new commit will appear in the Changes tab of the release:
You must redeploy the release to the Release & Testing environment so it includes the new changes that you’ve committed.
In this method, your changes are not validated before committing them into the release branch. The release will be automatically re-validated after the changes are committed.
C&D: Pull Requests
If you'd prefer to validate changes before merging them into the release branch:
Follow steps 1–2 above, but before selecting Compare now, choose Create new branch from
gs-gitflow-release/<GUID>and give the branch a name:
Work through the C&D steps and commit to this new fix branch.
Select Create pull request:
3. Enter your pull request details and select Create pull request, ensuring the PR target is your release branch (gs-gitflow-release/<GUID>).
Your PR will appear under Open pull requests for the release environment and will automatically be validated (as if it were combined with your release branch). After validation, promote the PR to merge your changes into the release branch:
💡You can also perform the above workflows directly in your VCS/CLI.
Syncing changes back to your integration branch
Any additional commits added to a release branch must be synced back to your designated develop/integration branch to ensure they are aligned.
To create a sync PR:
Select the static environment in your Release & Testing stage and choose Create sync PRs:
2. Select Create pull requests:
You’ll now see a sync PR opened against your Integration environment:
3. What do I do if I need to make a hotfix to production?
💡The ability to link a dedicated hotfix sandbox to production, similar to current Pipelines, is coming soon.
In the interim, you should follow the workflow described above for creating PRs against main. We do not recommend directly committing to this branch.
Syncing hotfix changes back upstream
You can do this by creating a sync PR from the release environment:
Select your Production environment and choose Create sync PRs:
Select Create pull requests:
You should now see sync PRs opened against:
Your Integration environment:
Your Release & Testing environment (if a release is open):
Transitioning from an Expanded Branching Model Pipeline to a Gitflow Pipeline
The 2 pipeline styles are fundamentally different (as outlined in many ways above), and there is no transition wizard or capability in Gearset to do this for the customers, however, depending on the existing and target setup, there could be some shortcuts.
Considerations
If possible, this should really be treated as a sizeable way-of-working shift, that would be cleaner to take place during a code freeze when there’s not tons of WIP to account for, so promoting all work through to main/production and completely synchronizing everywhere else would be the smoothest.
If this isn’t possible, there are a few considerations though:
Any existing branches across your current pipeline (that will be used in the new gitflow pipeline) will still showcase on existing branches, e.g the ‘develop’ and ‘main’ CI jobs if you’re reusing them, but the propagation/synchronization/feature branch deletion needs to be considered
Main - would this even work and show the gs-pipeline/ branches? or do they all need merging first?
Any branches and CI jobs that align to specific environments (UAT, Staging etc) will not be needed, and can be archived accordingly
Any
gs-pipeline/branches will no longer be required at all as per here, so should be cleaned up in your existing repository, and merged for production
Steps
Configure the new Gitflow pipeline as per here, making sure to consider if you’re going to be creating a new main/integration branch, or leveraging existing ones
If there’s an existing single CI job that acts as your ‘production’ (main) final stage, as outlined here, that CI job could be reused and added into your new Gitflow pipeline
Why are some features in Pipelines not available in Gitflow?
Some Pipeline features are not yet available in Gitflow. We are actively working towards parity. Current gaps include:
Linking hotfix sandboxes to production
Pre- and post-deployment steps for individual PRs and releases
Continuous delivery rules
Linking ServiceNow change records to production releases
Automatic creation of sync PRs
In-app DevOps performance (DORA) metrics