All Collections
Automation
Pipelines
Gearset pipeline management
Deployment rollback in pipelines (using the command line)
Deployment rollback in pipelines (using the command line)

There are a few methods to roll back changes in pipelines, and this article explains how to use git commands to help achieve that.

Samuel Crossland avatar
Written by Samuel Crossland
Updated over a week ago

The following document highlights how to revert a merge using git commands and the Source Control UI, ensuring it reflects throughout your pipeline and orgs.

Example flow:

  1. Make a new feature branch from your developer sandbox, and then start making changes as usual to head through pipelines. In the example below, we added a new custom field to the Lead object and pushed that into the branch feature/LeadSecondaryPhone using Gearset’s pipelines feature (more information here).

  2. Pipelines can then be used to open Pull Requests (PRs) to the next environments, which in this case were Dev1Sync > Integration > UAT, to simulate that feature promoting through as normal.

  3. Once the feature is promoted fully into the UAT org, you can see the Secondary Phone Number field appear in the UAT Org’s Salesforce UI as expected, showing the CI Jobs are taking the feature forward and into orgs as expected.

  4. Production then receives a promotion request as expected for the new feature. However, during UAT testing we find that we actually no longer need that feature at all, and make the decision to revert everything back out. This could be due to a number of reasons (superseded by other features, change in direction/scope, or simply wanting to fully back it out to start again). To start this process, we close the Pull Request opened against Production (as we don’t want to send the change there unnecessarily) before beginning the revert process.

  5. Now we dive into our IDE (Visual Studio Code here), open up the right repository and get on the right feature branch (which is feature/LeadSecondaryPhone in this case), to locate the change we’re looking to revert. This will likely already be downloaded if development work has been undertaken before, but if not please utilize git clone and git checkout (noted here and here) to get to this step.

  6. Git commands can then be used in the terminal to back the change out (revert) and push it back to the feature branch.

    1. Using git log we can find out the various commits that have occurred in this branch. In this example it’s only 1 (the other 2 below are merges from previous back propagations), but this could be several depending on the complexity/size of the changes in your feature.

    2. Using the findings from git log, we can then find out the unique commit ID (ending ‘866a’ in this example).

    3. We then use the command git revert <commitID> to actually back the changes out, and modify the commit message from the default in the editor (if we don't want to edit the default, pop in --no-edit and it will skip that modification step).

      1. If dealing with more than 1 commit, see the git revert command line reference here for details to revert multiple commits (usually looking something like git revert HEAD~5..HEAD~2’to hoover up everything in-between 2 points in time commit-wise).

    4. Once happy, since git revert has already taken care of the new commit for us, we can simply git push to get that reversion into the feature branch in source control.

  7. We can now head to source control (GitHub in this instance), and see the feature branch compared with the final environment we originally merged it to, which is UAT in this case. GitHub shows us we have 1 commit difference and that’s effectively the deletion.

  8. We then create a pull request directly from GitHub (using the Create pull request button offered), which lets Gearset kickoff the usual behavior in CI Jobs; it picks up a new PR, closes the original feature PR, and opens us up a gs-pipeline promotion PR, which will then appear in the pipelines UI.

  9. Now we can go back to the pipelines view and see a new PR opened against UAT containing the revert. We can then go ahead and promote changes into that environment to effectively delete the feature from the org (please ensure deleted items is ticked on the relevant CI Jobs before continuing with this step).

  10. Now depending on our create back propagation pull request setting within the pipeline settings (referenced here), the following steps will need to occur:

    1. Adjacent environments - we will immediately get the back propagation PRs open up to environments upstream, which we can then go ahead and start merging in to remove the feature from orgs it has already passed through (in my example that would be Integration and Dev1 Sandbox

    2. Final environment - we would get a PR open up again to the next environment along (in this example that’s our final one, Production), ready to finish the flow. This is the flow the rest of the example will follow.

  11. We can see from the above screenshot that the only 2 commits involved are the initial change, and then a reversion. We can safely promote this 'change’ into the final environment (since it’s effectively 'nothing changes') in order to force the pipeline to recognize a merged change and then back propagate to the other environments. Note - if you don’t want to merge into your final environment to kick off automatic PRs for back propagation, you would need to look at manually raising the PR against each upstream environment and handling them individually.

  12. After that change has finished promoting into the final environment, we can then see the rest of the back propagations open up to environments already passed through. Click on the relevant PR and ‘promote changes’ as normal to revert the feature from those orgs (in this case, deleting that added field from the Lead object)

  13. Once they’ve all completed, you can use the Recent promotion history tab on the environments to see exactly what's been reverted, and then verify inside the org itself that the change has been reverted as expected.

Following the steps above you can see how reverting features involves elements in the Gearset pipelines UI, an IDE such as Visual Studio Code, git commands, and your Version Control System UI also to bring everything together.

For alternative rollback options, please refer to this article.

Did this answer your question?