Rolling Back a Build
Microsoft Outlook has a seemingly nifty feature called Recall Message that seemingly
allows one to "unsend" a mistaken message. Unfortunately, due to the nature of email
(and the space-time continuum), it doesn't really work that well... and the flood
of "Jo Ann wants to Recall Message: Q3 Sales Data" emails makes everyone want to
read it that much more. Attempting to rollback changes to an application works about
as well and predictably.
Consider what would happen if you deployed changes that dropped a column in the
database. While you could certainly copy old files back, there's no way to resurrect
the lost column and its data. You could restore the database, but then you'd lose
any intermittently entered data.
Of course, that's just the tip of the iceberg: there's configuration changes, third-party
libraries, and all sorts of other not-so-straightforward changes that might have
occurred. Reliably rolling back everything to a perfect previous state is
nearly impossible. Writing a script to intelligently automate a rollback is even
This is precisely why we don't have a special "rollback plan" that's used only in
emergencies. Since such a plan would only get tested in rare cases (i.e. when something
went wrong), chances are it will be out of date and likely make things even worse.
But what we do have is a "Re-execute promotion", which can effectively be be used
to rollback changes. Assuming you have your deployment plan configured correctly,
of course.. Let's consider the state of a given application. You'll note below that
Release 3.5 (Build 16) was deployed to Production.
If we want to go back to Release 3.4 in production, we need to navigate to the promotion
details of the production-promoted build for that release.
You'll notice there's a big button called "Re-execute Promotion". Clicking on that
will run the production deployment plan using 3.4 Build 2's context. Here's what
the plan looks like.
The actions "Deploy Artifact" and "Deploy config files" are both designed to look
at the execution context to determine what to do. In this case, "Deploy
Artifact" will deploy the artifact associated with 3.4 Build 2. This will ensure
that whatever files were deployed with 3.4 Build 2 will always deployed with 3.4
Once the build has been re-deployed, the appropriate status is reflected in BuildMaster.
And like that, your changes are rolled back. Of course, this isn't a time machine
and nothing (not even a time machine) can reliably and perfectly rollback all changes
while keeping existing data. So, be careful using re-executions / rollbacks.