Rollback: A Necessary Safety Net
Rollback is a situation you hope to avoid but should always be prepared for. While the likelihood of needing to revert a deployment is reduced by using a tool like FlexDeploy, it’s reassuring to know that you can quickly roll back if issues arise. FlexDeploy 9.0 enhances this process with the introduction of deployment rollbacks, allowing you to submit a rollback request for a project or package after identifying a problem. FlexDeploy will handle the rest.
How it Works
A rollback simply reverts a target to a previous version of a project. When you submit a rollback request, it runs all the steps of a typical deployment based on the selected project or file versions.
Standard Project Rollback
Initiating a rollback for standard projects is straightforward. The request form resembles a regular deployment request, with a couple of key differences:
- Version Field: This is the build version you want to roll back to. The dropdown will default to the last successful deployment version for the selected target, displaying the state of the latest deployment for each version. This context helps you quickly identify the correct version to revert to.
- Notes Field: New in 9.0, this field is required for rollback requests and is available for all workflow request types. After submission, you can review the notes in the project execution history or reports.
Once the rollback completes, you can review the steps taken and see which deployment was rolled back via a link in the rollback execution row.
Package-Based Rollback
Rollback for packages can be more complex, which is why FlexDeploy offers ample flexibility and control at the file level for these requests.
Request Form
The first step in the request form is the same as for a deployment, including the notes field. The second step allows you to specify how to source each file for the rollback. You have four options:
- Project Version: Typically, you’ll select a previous build version to roll back to, sourcing the correct file version from the artifact repository. This is the default for most project types, with the version auto-set to the last successful deployment of the file.
- SCM Revision: Choose a specific SCM revision to roll back to, retrieving the file directly from your source control repository.
- Rollback File: Deploy a different project file to revert the current file. This is common for database scripts, where a rollback script accompanies the original file. The latest version of the selected rollback file will be retrieved from source control.
- Backup Repository: If your project is configured to take backups before deployment, you can retrieve the selected file version from your backup repository, which defaults to the most recent backup.
In addition to the source of each file, there are two more options for rollback:
- Skip: You can choose to skip any files that don’t need to be rolled back, even if they are listed in your package.
- Destructive: If supported for your project type, you’ll see a “Delete” column that you can enable to undeploy the file on the target. This option is automatically enabled if the file was newly deployed as part of the deployment you’re rolling back since there’s no previous version to revert to in that case.
Submitting a Rollback Request
When you submit a rollback request for a package, a new rollback package is created based on the details provided. This rollback package is then built and deployed to your target.
.
Customizing Rollback
Rollback requires no prior setup, meaning you can enter all details directly in the rollback request form. However, you have options for customization:
If you need to modify the deployment process for rollbacks, a workflow variable is available for use in deployment workflows to implement conditional logic for adding or skipping steps.
The rollback source type and rollback file on the request form are file attributes, allowing you to customize list data and default values using a Groovy script on the Project Types page. For example, you can set a default value for a rollback file according to a naming convention you use for rollback files (e.g., using R_XXHR_PER_SOCIETIES.sql as the rollback file for XXHR_PER_SOCIETIES.sql).
Conclusion
While it’s rare for a deployment rollback to be necessary, having a quick option available offers peace of mind. With the release of FlexDeploy 9.0, project and package-level rollbacks are now accessible, and there are plans to expand this feature to include release-level rollbacks in a future update.