When an application process has a predefined rollback step and the application deployment fails, you can restore the deployment model to a previous state. Application rollback occurs only for components that were not skipped (because of branching) in the application process. You can define multiple rollback steps.
How CloudBees CD/RO determines the rollback deployment
When a rollback step is encountered because of a deployment failure, one of the following options is invoked based on the rollback step configuration:
Roll back to a previous state—CloudBees CD/RO looks for a successful deployment with the same process name. Then, it starts the rollback using the same process and parameters from that deployment with component versions determined by the inventory state before the failed deployment. If a successful deployment is not found, the rollback fails. This option requires a successful deployment even when you are deploying with a snapshot. The last successful deployment could be part of a snapshot deployment or a regular application deployment.
Roll back to a snapshot—CloudBees CD/RO uses a user-specified snapshot for the rollback. The last successful deployment process and parameters that are stored as part of the environment snapshot are used for the rollback. Component versions are defined as part of the snapshot. If this snapshot is an application snapshot, CloudBees CD/RO looks for a successful deployment of the process with the same name, which is the same as the first option.
For both options, a combination of component definitions and deployment runtime parameters determine the version of the components that will be deployed.
Ways to perform rollback
CloudBees CD/RO provides these ways to do rollback:
Automatic rollback—CloudBees CD/RO automatically reverses what was deployed up to the failure point in the process flow. See Automatic Rollback for more information.
Snapshots—You manually create and save snapshots of successful deployments and run a snapshot the next time the application is deployed. See Snapshots for more information.
A component process defined as an undeploy process–When defining a component process, select Undeploy as the process type.
Triggering rollback even if undeploy fails
You can trigger rollback even if undeploy fails. To do so, use the Continue running option in the Application Process Step dialog box when configuring a rollback step.
Enabling rollback only on components that successfully undeployed
You can limit rollback to those components that undeployed successfully. To do so, use the Rollback only successfully undeployed components option in the Define Step dialog box when defining a rollback step.
Enabling rollback only on failed components
CloudBees CD/RO automatically tracks components that failed during application deployment and will roll back only those components. This option is useful when the components do not have version dependencies. You can use Component Level Rollback with automatic rollback and with snapshots.
Using automatic rollback
CloudBees CD/RO supports a rollback step in application processes. This allows an automatic rollback to the environment before a bad deployment or to any previous environment snapshot. This reduces the time to author the rollback logic.
During an application deployment, the predefined rollback operation is invoked when the rollback step runs. CloudBees CD/RO reverses what it executed in the process flow up to the application process step where the failure occurred.
This operation is supported only in application processes. It puts the deployment in the same state as the last successful deployment, which is usually the same as the previous deployment state.
If the Roll back to previous state option is enabled and no last good deployment exists (for the restore point), the rollback step is skipped. The undeploy step (if configured) will still run.
When you define an application process step as a rollback step, the application can roll back to the previous state up to where the deployment failed (the default) or to a specific snapshot. Also, you can specify how the application will be rolled back:
By default, the Smart Deploy option is enabled. If you want to execute a full or partial run the next time the application is deployed, disable this option.
When the Undeploy Application before Rollback option and the application process that you want to undeploy (in the Select Process field) are selected, the environment inventory record is removed before the rollback operation is executed. This allows dirty files in the bad deployment to be removed automatically. When you use the Undeploy Application before Rollback option with the Component Level Rollback option, failed components are undeployed and then rolled back.
When a specific snapshot is selected for rollback, CloudBees CD/RO tries to determine the last successfully-deployed process and then tries to execute it from the snapshot. While a native rollback step is available, you have complete control over creating a custom rollback handling operation and using that as part of the error handling logic.
|If the last successful deployment was a partial deployment and the rollback job is reverted, CloudBees CD/RO reverts only the components included in the partial deployment.|
Requirements for using rollback
Enable change history.
Redeploy an application successfully before using rollback after a full import.
Keep the original application process name. If you rename it after a successful deployment, and if rollback to the previous state is configured, CloudBees CD/RO cannot determine the last successful deployment. In this case, rollback will fail (but the undeploy process will still occur).
Guidelines for a successful rollback
Use environment snapshots for rollback (not application snapshots).
Use smart deployments instead of partial deployments:
If the last successful deploysment was a partial deployment, the rollback job reverts only components in the partial deployment.
If you use partial deployments, you should take a manual snapshot (using EF-Utilities) and use it with the rollback step.
$property reference to reference the snapshot so that it can be dynamically set.
Use environment snapshots instead of application snapshots for reliable software deployments.