We can all think of an occasion when having an ‘undo’ button has saved our skin. For Salesforce developers, hitting deploy can often feel like the moment of truth. What if something goes wrong? How will I revert my changes if they’re not right?
Trying to roll back a Salesforce org to an earlier state is normally a difficult, slow and frustrating process in which developers and admins must revert changes one at a time—manually. But with Gearset, you can easily roll back any changes with just a few clicks, whether that’s reverting an entire package or removing just a few specific items. If you’re using Gearset’s full toolkit, you can roll back any metadata changes in your org—no matter how they got there. Not bad, eh?
Why do teams need Salesforce rollback?
You may be wondering when you would find yourself needing to roll back changes to your Salesforce org. There are three main reasons for wanting to roll back:
- As humans, we’re prone to mistakes: you may release something, then realise it was an error, or perhaps a change was something experimental that was never supposed to make it to production.
- You may release a feature to production, and then find it doesn’t work. Unless you can figure out a hotfix, the best option is probably to roll back, work out what went wrong, then try again.
- You may release changes to production, then find out they’re not quite what the end user wanted. If end users have been involved in the development process, however, this shouldn’t happen too much.
Another reason to roll back could also come from your monitoring job flagging some change to the metadata in production. Gearset’s monitoring tool will flag any unexpected changes that happen within your environments. Being alerted to these changes and then being able to roll back will save you a lot of time and a fair few headaches.
What tools are available for Salesforce rollback?
Having a tool ready to go that makes this ‘undo’ process seamless means that you can roll back faster. We all know mistakes happen, but for something as important as Salesforce, we should take special precautions as admins and developers to make sure that those mistakes can be dealt with quickly, confidently and simply.
Neither of the native deployment tools on Salesforce—change sets and the new DevOps Center—offer any rollback functionality. Some other tools can do a rollback of sorts, but only if you take a manual snapshot first.
While other solutions offer a painful and manual workflow, Gearset automatically keeps a snapshot of the target org before deployment, so you can always roll back seamlessly.
Better yet, we offer partial rollbacks: so if you spot a small thing you want to change, you can do that without having to ‘undo’ everything. You also can’t deploy deletions with change sets, but with Gearset—you guessed it!—you can.
How do rollbacks work in Gearset?
Thanks to Gearset’s unique comparison engine, every time you run a deployment, Gearset takes a snapshot of your target org which is automatically saved just prior to deployment.
That means if you ever need to roll back changes, Gearset will run a new comparison between the stored snapshot and the org’s current state. This will highlight what changes have been made since the snapshot, and let you selectively roll back any of the changes. Rollbacks take advantage of Gearset’s unique problem analyzers to make sure the rollback deployment succeeds.
There’s no limit to how far back in your Gearset deployment history you can go to perform a rollback, although it’s worth noting that if you try to roll back a deployment from some time ago, you may see a large number of detected changes between the snapshot and the org’s live state.
Rollbacks can also be performed for source control in exactly the same way.
What about metadata dependencies?
We all know dependencies can make or break metadata deployments! Rolling back changes in Salesforce isn’t simply a case of reversing what you deployed. Creating and then removing changes can impact a wider set of objects than just the items in your original deployment package as a result of dependencies. This means that simply ‘undoing’ the deployment won’t always work, and this is where other approaches to rollback falter.
Gearset’s deep understanding of the metadata in your orgs means it can resolve these complications. When you perform a rollback with Gearset, new object dependencies created by the original deployment are automatically identified, making the rollback process faster and more reliable. You can easily select the changes you want to revert, including any dependencies, and quickly complete the roll back.
How to roll back a deployment with Gearset
First, find the deployment you want to roll back from your deployment history, and click Roll back.
Gearset will then compare the org’s current state with a snapshot of the org taken just before the original deployment you want to roll back. From this comparison, you can then choose exactly which changes to roll back. In this example, we’re removing a couple of Apex classes that were deployed earlier.
After selecting the items to roll back, click Next to be taken to the pre-deployment summary. Then click Deploy now to complete the rollback process, or validate the rollback changes first by clicking Validate deployment.
After successfully rolling back your changes, your rollback deployment will be stored in your deployment history, tagged as a rollback. Like any other deployment in your history, you can view the usual deployment report, download the deployment package, and even roll back the rollback if you wish!
Save your skin with seamless Salesforce org rollbacks
Hopefully you’re on a roll with deployments at the moment, but sooner or later you’ll need rollback. New users can try out rollback for free, along with all other parts of the app, by starting a 30-day trial of Gearset—just click the link below to get started.
Access to Gearset’s rollback option comes with our Enterprise license. If you’d like to upgrade from a Pro license in order to get access to rollback and other Enterprise features, simply email us at [email protected].