Understanding Rollbacks in Release Management for Visual Studio

Posted by Daniel Mann - March 07, 2014

header-picture

We tend to focus on the "happy path" when it comes to Release Management. However, in the real world, we periodically find ourselves on the "unhappy path", where things don't go exactly as we expected.

So, what options do we have for getting back on the happy path when we stray off of it?

Option#1 : Fix the issue, do another release

The first option we have when a release fails is to simply do nothing. Something went wrong, we need to troubleshoot it and fix it. Once we fix the issue, we can do another release. That's fine for dev and QA environments, but probably isn't going to work well for production. Ideally, your production deployments should never fail -- after all, you're testing your deployment process every time you deploy to your dev and QA environments! -- but it does happen.

Option #2: Do a Rollback in Release Management for Visual Studio

That leads to our second option, which is to leverage rollback blocks in our release templates. A rollback block is just a container within our release template, that contains actions that will be taken only if the release fails. "Fails" is defined as "Any one of our deployment actions returning a non-0 status code". If that happens, Release Management executes the actions contained in your rollback blocks.

A rollback block is "tied" to the preceding action, so when you're using rollback blocks, you should have an action, followed by a rollback block containing the steps necessary to "undo" that action.

In addition to regular rollback blocks, there are "Rollback Always" blocks. As you'd expect, a Rollback Always block is always executed, regardless of where it occurs in your workflow.

Let's take a look at some scenarios. Here's a screenshot with some deployment actions, rollback blocks, and helpful text labels added by yours truly.

If D1 fails, the following rollbacks will execute, in order: RA1, R1, RA2.

If D2 fails, RA1, R1, R2, RA2 will execute.

If D3 fails, RA1, R1, R2, RA2 will execute, the same as for D2.

If D1, D2, and D3 all succeed, no rollback blocks will execute.

This is all you need to know about rolling back applications when deployments fail! If you have any questions, do not hesitate to send your comments using Disqus. If you want to learn more about Release Management, I wrote another article on deployment databases using RM for Visual Studio. My next articles will talk about branch and merging strategies.

Topics: Blog


Recent Posts

InCycle Named Azure Data Explorer (ADX) Partner

read more

OpsHub & InCycle Help Top Medical Device Company Accelerate Innovation

read more

InCycle Continues to Lead, Recognized by Microsoft for Industry Innovation. Earns Impact Award.

read more