In Salesforce development, rollback capabilities are essential for managing and mitigating issues that arise from deployments. Rollback allows you to revert changes and restore the system to a previous, stable state. FlexDeploy, a comprehensive DevOps tool, offers several methods to facilitate rollback, including Versioned Artifacts, File Revisions, and Backups Repository. This documentation provides an overview of these rollback methods and guides you through their implementation in FlexDeploy.
Understanding Rollback
What is Rollback?
Rollback is the process of reverting a system to a previous state. In Salesforce, this often means undoing changes to metadata such as Lightning Web Components, Lightning Flows, Apex Classes, and Layouts. Rollbacks are essential for correcting errors, addressing unforeseen issues, or reverting to a stable version of an application after a failed deployment.
Why is Rollback Necessary?
Error Correction: During deployment, changes can introduce errors or conflicts. Rollback allows you to undo these changes and restore system functionality.
System Stability: Rolling back helps maintain system stability by reverting to a previously tested and stable state.
User Satisfaction: If a deployment causes issues for users, rolling back can quickly restore the previous, functional version, minimizing disruptions.
FlexDeploy and Rollback
FlexDeploy offers several options to rollbacks, each providing flexibility depending on the rollback needs.
1. Versioned Artifacts
FlexDeploy maintains a history of builds and deployments through versioned artifacts. Each build creates a new version of the package, allowing you to deploy any previous version of a package if you need to rollback to a prior state.
When to Use This Option: When you need to revert to a previous state for all files in a package, you can use versioned artifacts for rollback. This option is ideal if you want to restore the entire package to a prior version.
a. Navigate to the Package Execution and identify the previous version.
b. Select the Version and Submit it for redeployment.
2. SCM File Revision
When files are committed to a source control system (such as GitHub, GitLab, or Azure), a commit history and file revisions are created. FlexDeploy can leverage these revisions for rollback.
When to Use This Option: When you need to revert to a prior state for one or specific files within a package, you can use SCM file revisions for those files. This option is ideal if you only need to restore individual files or a subset of files to a previous version in a package.
a. In FlexDeploy, click on Build and select the second option, File Revisions. Choose the previous file revision you want to restore or roll back.
3. Backups Repository
FlexDeploy takes backup of the metadata from the target org before deployment and stores these backups in a designated Backups Repository on the FlexDeploy server. Backup Repository needs to be configured in order to use this option.
When to Use This Option: When you need to revert to the previous state of files that were affected by the current deployment, you can use the Backups Repository for rollback. This option is particularly useful if you want to restore files to their pre-deployment state. Before deployment, FlexDeploy saves a backup of the affected files, allowing you to deploy these backups if a rollback is necessary. This option ensures that you can restore files to their original state before the recent changes were applied.
a. To view or download a backup, navigate to the deployment where the backup was created. Click on Artifacts, and the Backups will be displayed below the Artifacts.
b. To restore the backed-up files, you can create a deploy input that replaces the current artifacts with the backups and then deploy them. You can either create a separate workflow for Rollback Deployment to use instead of the Deploy Salesforce workflow, or modify the existing Deploy Salesforce workflow and add execute step before deploySalesforce step. Ensure that the modified version is not activated. When deploying backup files, select the appropriate workflow version from Deploy Request > Advanced > Workflow Version.
Use following Code Snippet (shell) in execute step -
if [ -f ${FD_BACKUPS_DIR}/*.zip ]
then
echo "Back file exist"
ls -ltr ${FD_BACKUPS_DIR}
rm -r ${FD_ARTIFACTS_DIR}/*.zip
cp ${FD_BACKUPS_DIR}/*.zip ${FD_ARTIFACTS_DIR}
else
echo "Backup file does not exist."
fi
c. Alternatively, you can add the backed-up files to source control and manually build and deploy them.
4. Destructive Change Management
The above rollback options do not directly support the deletion of files, that were newly deployed. This option helps you remove unnecessary files from the target org or delete files that were mistakenly deployed.
If you wants to delete files or components from the target Salesforce Org as a part of a rollback, then you must use the Destructive Changes functionality. This functionality allows you to remove components that are no longer needed. For detailed information on how to implement destructive changes, please refer to - https://flexagon.atlassian.net/wiki/spaces/FD90/pages/10926703549/Salesforce+Tutorial#Support-of-Destructive-Packages
Rollback capabilities in FlexDeploy for Salesforce development offer flexibility, precision, and confidence in deployment management. Whether you are reverting a full deployment or rolling back specific components, FlexDeploy’s versioned artifacts, file revisions, and backups repository provide the tools necessary to ensure system stability and minimize downtime. By integrating rollback strategies into your deployment workflow, you can ensure smoother, more reliable Salesforce development and maintenance.