Rollback

Updated 1 month ago by Copado Solutions

By following Copado's best practices in your release management process, you will be able to identify issues with your metadata changes as they are being deployed from one environment to the next one. While enforcing quality gates, you will be able to troubleshoot the issues before the changes arrive to production. Hence, the probability of errors in production is minimal or non-existent.

However, what if there is an unexpected behavior in production? A rollback process could imply losing information in components that are automatically removed, but this could be resolved by creating a bug user story, committing the fix and deploying it to production. By this means, the bug user story will have to go through all the quality gates you have implemented in your release management process. Nevertheless, you can take a shortcut by enabling a hotfix environment that is directly linked to production, as shown in the diagram below:

If you still need to perform a rollback, continue reading to learn how this process works.

Before a Deployment

A prerequisite for performing rollbacks is to have a backup of your org in a branch in your Git repository. We recommend scheduling frequent backups by using Copado scheduled jobs, or every time you deploy changes to the org.

For frequent backups, you can do the following:

  1. Create a backup branch in the Git repository for the relevant working branch. For example, for the master branch, create a “master_backup” branch. 
  2. Create a Git Snapshot record in Copado and fill in the details as follows:
    1. Enter a descriptive name, like 'Production Backup'.
    2. Select your Git repository.
    3. Enter the backup branch name. In our example 'master_backup'.
    4. In the Git Snapshots Permission field, select Allow Snapshots Only. This will prevent anyone from committing to this branch and altering the backup version.
    5. Select a frequency to schedule the backup on a daily or weekly basis, depending how often you deploy to that org. 
    6. In the Org Credential field, select the org from where the metadata will be retrieved. In this example, select production since you are backing up from master:

Alternatively, if you want to execute a backup only for specific deployments, create a URL Callout step in the Deployment record prior to the actual Git Promotion step. Select the Take a Git Snapshot webhook and select the backup Git snapshot to be executed, or simply open the backup Git Snapshot record and click on Take Snapshot Now to manually perform the backup.

After a Deployment

In order to compare files and execute the rollback, follow these steps:

  1. Create a Snapshot Difference to compare the latest backup commit in the backup branch (master_backup in this example), against the destination org: 

  1. Once the difference calculation is finished, select the files that you would like to deploy to the destination org.:
  2. Click on Create Deployment and then follow the steps in order to deploy the metadata components from the Git backup.

Delete corresponds to components that were created during the latest deployment, but don’t exist in the latest backup. They will be deleted in destination if selected. 

Git can only track full files, so nested components won’t be automatically removed.

Create corresponds to components that were deleted in the destination org during the last deployment, but are available in the latest backup. They will be created in destination if selected. 

Update corresponds to components that were modified/updated during the last deployment. By using the Show Diff link you can see a side-by-side comparison of the files:

This deployment is a Git to org deployment. The destination’s org branch won’t be updated during this process. In order to update the destination’s org branch (in this example, master), we’ll need to commit these changes by retrieving them from the org and pushing them to git.

  1. Once the deployment is successfully completed, go to the Git Snapshot record of the destination org (production in our example), click on Commit Changes and select the metadata components that were rolled back and commit them. This will ensure that the changes in the org's branch are in sync with the org itself.

Additional Considerations

Given the way Salesforce handles some of the metadata, items which should be deleted are disregarded. Although fields or workflow rules/actions can be selected as single metadata elements, they will be added to one big object definition or object workflow file (e.g. Opportunity.object or Opportunity.workflow). The items that are added to those files will be created, but if an item (e.g. a field) is removed from the file, and this file is deployed (Opportunity.object), Salesforce will disregard the field instead of deleting it. 

In order to make sure these items are deleted, you will need to add a Delete Metadata step with the items to be deleted to the deployment resulting from the snapshot difference.

Sample metadata which handles deletions of nested components/references:

  • Layouts
  • Classes 
  • Reports 
  • Custom Report Types
  • Flows

Sample metadata which disregards deletions of nested components/references:

  • Objects 
  • Workflows 
  • Profiles 
  • Labels 
  • Any metadata you can construct atomically, but which in the background is stored in one single file.

For more information about the metadata types, check out the article Commit Changes Overview.


How did we do?