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. You can backup your main orgs either on a frequent basis (recommended) or every time you deploy changes to the org. For the first option, navigate to a Git Snapshot record and select a frequency to schedule the backup on a daily or weekly basis. Alternatively, if you want to execute a backup for every deployment, create a URL Callout step in the Deployment record and select a Git snapshot to be executed, or simply open the Git Snapshot record and click on Take Snapshot Now to manually perform the backup.

After a Deployment

  1. Create a snapshot difference to compare the backup commit against the destination org. 

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

  • The deletions correspond to files that were created after the latest backup of the org (Git can only track full files, so nested components won’t be automatically removed). 
  • In the updates, the Show Diff link will show you a preview of the changes.

  • Creations are components that are deleted in the org, but available in the latest backup.

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.

  1. If you’re using git as a source of truth with or without Branch Management, once the deployment of the metadata is completed, go to the Git Snapshot record linked to the relevant org and commit the metadata components that were rolled back into the environment branch. This is to ensure the information in the environment branch is in sync with the org.


How did we do?