The learning circle lab workbook for IBM Urbancode Deploy (here) helps you create a PetStore scenario where you can deploy new versions to a couple test environments. The challenge is that if you want show someone what you've done - or perform a demo of the product, you can't really rollback the changes you made to the database. Trying to redeploy the 1.0 version of the database will not remove the 1.1 updates.
Rollbacks in UrbanCode Deploy
There are basically two strategies to rolling back code in UrbanCode deploy. One is to simply redeploy an old version. That works really well for things like web applications where a file or set of files simply represents the version of the application and can be redeployed. It can work for configuration settings as well since UCD tracks configuration versions and can bind configuration versions to specific snapshots.
The other approach is to do a special rollback process. For cases like a database where rolling back a change might mean combining columns that had been split, rolling back changes means taking an action reversing each in a sequence of updates. This can also apply to certain changes on the mainframe, or to content changes where a version contains the handful of files to be updated, but not the rest of the site.
Our database change falls squarely in the second category, so we need a process that rolls back a database change.
Add a Rollback component process to the Petstore-DB component
Create a second process on the Petstore database component. This means going to Components > Petstore-db > Processes and clicking the new process button.
The key here, is to choose a different process type. Unlike everything else in the lab so far, you will choose Uninstall rather than Deployment.
The component process itself is a pretty simple. Our 1.1 version of the database knows how to uninstall itself. So it just needs to be downloaded to the target and have its rollback plan/script called rather than the deployment. Choose the Rollback DB step from the same plugin that was used for the deployment of the database code. It will have many of the same inputs as the deployment step you configured for the database.
The odd bit here is the "Target Version". Done correctly, we'd have a clever lookup to see how far back we want to go. In our simple case, just putting version "1" in there will work fine and get back to the 1.0 stat.
Create a new Application Process
We'll need to create a new Application Process. This could be something simple like a "Rollback DB changes" process that would call only our new process. But where's the fun in that?
Instead, let's exploit the model driven nature of UrbanCode Deploy. Create a new Application Process called "Apply a Snapshot".
Choose "Rollback Component" from the pallette and add the Rollback process from the database component somewhere before the deployment of the database changes.The key is to set the Rollback Type to "Remove Undesired Incremental Versions". What this does is look at the Snapshot and compare it to the Inventory for the environment. Every incremental version of the component that is in the Environment but not in the Snapshot will have the rollback process run against it - in the reverse order of deployment. So if we have 1.0, then deploy 1.1, then deploy 1.2 and then rollback to 1.0 the Rollback process would be run first on 1.2 then on 1.1.
At this point, all you need to rollback to the "starting point" is to create a snapshot containing the 1.0 versions of all the components. You can then run the "Apply a Snapshot" process against it to rollback to the start. The neat thing is that you can run the same Apploy a Snapshot process when deploying snapshots from SIT to UAT. Due to the incremental rollback, it won't work when deploying just a single component to SIT though. You won't be allowed to request deployments for it that don't contain Snapshots.