How you can pre-validate your release in Salesforce and have a rollback ready - just in case.
Have you ever had to do a Salesforce rollback while the clock was ticking? It’s not very fun! That’s why for this week’s CTO Corner we wanted to relay a quick story from a fairly advanced Salesforce team that we met recently.
Not only do they pre-validate every major release in a recently created sandbox before pushing to production (something that many teams do), they also pre-validate the rollback of said release before they push the release to production (which very few teams do).
We hadn’t yet encountered this kind of diligence yet so we thought we’d share it as an interesting practice for teams that want to be extra cautious with their Salesforce releases.
This team releases every two weeks. Before each release they spin up a sandbox directly from production to establish as close an approximation of production as possible. We think this is brilliant. Far too many of our customers have sandboxes that have not been refreshed in months or years. The validation and testing that a team can do on such an out of date sandbox is frankly rather risky.
Next, they would build a package.xml and deploy all of their changes for the release for that into the newly created sandbox using the Ant migration tool for Salesforce. So far, fairly standard.
Here’s where it gets interesting. As soon as they’ve done that deployment they would create a reverse deployment which rolls back those changes. They create the destructiveChanges.xml and a corresponding package.xml to reverse the deployment. They could then validate that this deployment can be rolled back should anything go wrong.
Now they are ready to production. When they push to prod, they have experience rolling back the exact release they are deploying and they know that it can be undone if need be. This gives them the confidence to release knowing that they have a well tested and understood backup plan.
Now before you suggest that this is overly cautious and paranoid, consider this: Salesforce is mission critical to your business. For many of our customers, if Salesforce is down or buggy, trucks stop, food spoils, revenue is lost and customers get angry. So having a proper release management strategy with the capability to undo changes is fairly crucial. Imagine a multi-million dollar investment in Salesforce going down without speedy recourse. Heads would roll.
Having a pre-validated rollback ready to go allows teams to deploy with confidence. It’s a small upfront investment but it pays major dividends when something does go wrong. Anyone who has ever had to do a rollback under the gun knows how desperate and stressful it can be. Most teams using Salesforce today do not have any kind of source control or backups which they can quickly fall back on. And as any Salesforce developer can tell you, getting a change set to validate, especially under pressure can take hours and a lot of manual trial and error.
If you’ve ever been there you know you’ll wish you had spent 5 minutes setting up a pre-validated rollback.
A major reasons most teams don’t do this is that it’s time consuming and difficult to deploy. It’s hard for many teams to imagine doing two separate deployments on release day when they are struggling to get one out the door on time.
Because Blue Canvas makes deployments so straightforward and simple it removes a lot of the barriers to doing this kind of pre-validated rollback.
If you spin up a new sandbox from production you can connect it to Blue Canvas in just a few clicks. You can then deploy your release into that sandbox using Bulk Release deployments or a typical deployment.
Blue Canvas automatically creates the package.xml and handles destructive changes in Salesforce automatically. This saves a lot of time.
Once you’ve deployed into the sandbox you can roll it back in just a few clicks, using our rollback technology for Salesforce. You can grab the latest source snapshot and rollback the release and confirm that the release will successfully validate in reverse (which is should since you just deployed it cleanly). All of this takes just a few minutes to set up, and what you essentially have is a continuous backup of your Salesforce Metadata, which you can review and restore at any point in time.
Next, I can clone both releases and validate them against production before I deploy using the same pre-generated package.xml with all of the same changes.
In this case you simply clone each and point them towards production.
This will now validate just as you would expect. In this case, both deployments are sitting in a validated state. So all you have to do is Quick Deploy the release when you are ready.
Once that release is deployed, you can rest easily because you have a pre-validated rollback ready to go. The release can be undone with the click of a button.
.png)