GlobalRationalUserCommunity 270007QH7A 348 Views
Eric Minick 270006CB7G 1,223 Views
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.
We tried to download with our IBM user access.. but it looks like it needs different login for Urban code as it is redirecting to the following site:
Babji S Vundavilli
Version 2 of the UrbanCode Deploy Plug-in Development Kit has been released. The devkit can be downloaded from the following IBM DevOps Services project:
It is recommended that you delete version 1 of the UrbanCode Deploy Plug-in DevKit
before installing version 2 instead of simply upgrading.
1. Removed any reference to "uDeploy" and replaced with "UrbanCode Deploy"
2. There was an import wizard and an export wizard that simply overloaded the existing
zip file import/export wizards but did nothing but call the Eclipse archive
import/export wizards. These were removed.
3. Fixed the issue where the creation of new plug-in projects produced an error due to
the Eclipse installation location having a space in the path.
4. Added the capability to create a new plug-in project based on an existing plug-in
zip file. The new project is created with the default project structure. The project's
contents are then populated from the specified plug-in zip file.
1. The issue with the meta-data editor throwing errors still exists. There are some
cases where as long as you only have one xml file open in the editor you are fine.
Opening a second editor would throw an error. The workaround is to only have
one file open at a time.
Newly added to the learning roadmap is a milestone titled "Learn How To Build IBM UC Deploy Plugins". This milestone includes a hands on lab that teaches you how to use the UrbanCode Deploy Plugin Development Kit to build plugins. There is a powerpoint that takes you through the topics and a lab workbook with step by step instructions on building plugins.
Check it out.
If you have a question about UrbanCode products, want to search for an answer, or you are a Subject Matter Expert who can answer questions, please use this new UrbanCode answer site on developerWorks.