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

Programmable objects are automatically rolled-back whenever the deployment package differs to the target environment (according to the checksum that is kept in the migration log table). To perform a rollback of all programmable objects, simply revert the appropriate changes in version control, and then build & deploy the project again. Note that, changes made to programmable objects outside version control are not included in rollbacks; in order to rollback out-of-process changes, the schema drift detection feature can be used instead.

SQL Change Automation 4

Rollbacks

Rollback support in SQL Change Automation