Published 31 July 2019
When contingency planning for your system deployments, it's important to consider how you might handle a scenario in which a rollback is required.
However, any decision that is made needs to take into consideration the different types of assets being deployed:
- With application code, rolling back to an earlier version is pretty straight forward: you can simply replace the deployed artifacts with the previous working version
- Database rollbacks are hard due to the nature of persistent storage: the data within your schema must be preserved when rolling forward to allow a prior state to be restored at a later date (if a simple db backup/restore is not an option)
In essence, how you plan to roll back in the event of release failure entirely depends on the changes made to both your application code and database.
Rollback support in SQL Change Automation
We strongly recommend rolling forward instead of rolling back.
However, in understanding that it is often a requirement within organizations to have a contingency plan in place prior to deployment, SQL Change Automation does provide some functionality that can support your efforts to prepare for the scenario in which a rollback is needed:
Programmable object rollbacks