In this scenario, there is a feature that has failed the UAT testing and needs to be fixed to continue. This article will explain one method that users have available to them in order to deploy this fix with pipelines.

To view another method that allows users to complete this fully within Gearset see Committing more changes to your user story.

These steps will highlight how to complete this outside of Gearset. Allowing users to bypass certain environments.

In this scenario we have a feature going into UAT but it has not passed the tests at Integration, so needs to be updated accordingly.

1. Because the feature fixes need to be retested before going to UAT, all fixes will be first created in the Dev sandbox (where the feature was originally created). Next, we will add those fixes into the feature branch using the commit more changes button (after finding the original feature branch in the dropdown and selecting it).

2. After committing, this will automatically update the PR open against UAT (on branch gs-pipeline/[feature name]_-_UAT) with the new commits, and rerun the merge conflict checks. If the ‘validate PRs’ setting is ticked on the CI Job, the validation checks will also rerun.

3) If that Promotion Branch was merged into UAT, Pipelines would realize that Integration is missing a commit and open a back propagation ‘Sync’ PR to align everything together (depending on the Back Propagation settings). However, since testing is needed in Integration before promoting anything to UAT, do not merge that UAT PR, and manually go into the VCS to open a PR from your feature branch to your Integration branch.

4) This new PR will only show the extra commits added to the feature branch, since that’s the delta vs Integration, and be auto converted into a promotion branch for Integration (gs-pipeline/[feature name]_-_Integration)

5) That PR is reviewed as usual and can be merged, which will trigger the CI job to deploy the extra commits into Integration, and allow testing to begin in the sandbox. The QA testers can now retest my Feature1 in the Integration sandbox and feed back any further failures or a pass result before we continue.

6) If the feature now passes testing, the PR against UAT is primed to merge and continue testing there as it will have automatically updated with my extra commits and reran merge conflict checks/validation.

Note: If there are branch protection rules set up in the VCS to unapprove the PR if extra commits are added. The PR may need to be re-reviewed here before its mergeable.

7) Merge the PR into UAT, which kicks off the CI job to deploy to the sandbox, and then continue as normal without any further back syncing.

8) The feature continues the testing & deploying cycles up until Production, and once merging into master, is back propagated (fully, with all relevant commits) to all of the other environments.

Note: If a change is in a release branch then any updates in the feature branch will not be reflected in the release branch.