Rollback Based on Snapshots Differences

Updated 1 week ago by Copado Solutions

When you want to roll back your changes, you can do it by following the instructions provided in the Copado Rollback article, but you can also do it by running snapshots differences.

There are some cases in which you may need to perform the rollback through Snapshot Differences:

  1. Changes were made directly in an environment, without using promotions or deployments.
  2. You want to rollback changes in an environment for which you have not activated the promotion-based Rollback feature (such as non-business-critical or developer environments).
  3. You have deployed changes to an environment by using any of the deployment steps not supported in the Rollback feature (see supported steps in the Copado Rollback article).

To run snapshot differences, you will need to perform some steps before and after the deployment.

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/main branch, create a “master_backup” or “main_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 on 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:
Frequency

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: 
    Snapshot Difference record

  1. Once the difference calculation is finished, select the files that you would like to deploy to the destination org:
    Difference calculation grid
  2. Click on Create Deployment and then follow the steps 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 only tracks full files, so nested components will not 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 the 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.

The following elements are sample metadata which handle deletions of nested components/references:

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

The following elements are sample metadata which disregard 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.

  • For an overview of the rollback functionality, scopes and supported capabilities, outcomes and other considerations, please refer to the Copado Rollback article.
  • For FAQs, please refer to the Rollback FAQs article.


How did we do?