CI Job Rollback
Last updated
Was this helpful?
Last updated
Was this helpful?
The CI JOBS screen is best viewed when the zoom setting is set to 80% on your chrome/firefox browser.
The rollback feature is very useful to roll back a deployment as soon as you realize that something went wrong with the CI job or you accidentally deploy something unwanted.
Here we will learn how to roll back deployment with your CI Jobs. The objective is to roll back to the old release or version of a deployment.
The Rollback checkbox is selected while creating a new CI job
Go to the CI JOB RESULTS screen and choose the deployment label from the list for which you would like to trigger the rollback.
Click on the Rollback () icon.
Find the list of metadata components that will be rollbacked (under the API Supported > Constructive changes section). By default, all the components that were part of the deployment are selected.
In the "Choose your Pre/ Post Destructive Changes," you’ll see the list of metadata components that are present in your target environment but not in your source environment. Simply tick the box next to a component you want to delete, and that component will be deleted when you deploy. The excluded component's details are logged and can be found in Rollback Iteration Log.
You can choose the destructive changes method to delete your components from your target environment to sync up the changes.
Post Destructive Changes: The post destructive changes feature will delete the unwanted fields or metadata components from your destination environment when the deployment is successful.
Pre-Destructive Changes: Pre-destructive changes will delete unwanted fields or metadata components from your destination environment before the deployments begin.
Point to Remember: For active flow metadata, you must add the version number before continuing with destructive changes. See the FlowDefinition guide for more detail.
The API Un-Supported section will list down all the unsupported API metadata types. You can include these components as a part of pre or post-destructive changes as well.
Point to Note: We advise against using the unsupported APIs components during the rollback process, as this might result in deployment rollback failure.
Under Additional Deployment Options, you have below options to choose from:
Validate Only: This allows you to prevalidate the deployment so you can catch any problematic changes early and make sure that when the time comes to deploy, you’ll be able to release successfully. Actual deployment doesn't happen when this feature has been opted.
Deploy purge on delete: Salesforce uses a Recycle Bin metaphor for data that users delete. Instead of removing the data, Salesforce flags the data as deleted and makes it visible through the Recycle Bin. AutoRABIT has a provision to identify the components that users want to delete and permanently delete them from their Salesforce environment instead of keeping the deleted components in recycle bin. Once purged, they can not be recovered.
Ignore warnings: This option will allow the rollback to continue even if there are warnings that can cause the deployment to fail.
Select the Apex Test level to validate your deployment. For detailed information on each test level, refer to the article: Apex Unit Tests
Click Rollback.
After successfully rolling back your changes, your deployment will be stored in the CI Job Results screen, tagged as a rollback. From here, you can view the usual deployment report, download the package, and even re-deploy the rollback if you wish!
