When I was working with a customer using TFS 2013, the software development manager recently asked me, "Why should we use Release Management for Visual Studio?", and after spending about 15 minutes listing reasons, I realized that other people might be asking themselves the same question!
So, let's start off with a high-level overview of what Release Management for Visual Studio does:
Release Management for Visual Studio makes release cycles repeatable, visible and more efficient by automating deployments through every environment from Team Foundation Server (TFS) up to production. Based on a business-approval workflow and a flexible and centralized configuration, Release Management is a common platform that improves coordination and communication between development, operations and quality assurance to decrease issues inherent to it such as: inefficiency, errors, frustration, high costs and delays.
Okay, so that's what it does. If I had to sum it up in two words, I'd use process visibility and reliability. Let's see how it helps with those things in more specific terms:
Visibility:
RM makes the process involved in deployments more transparent. Normally, the exact steps necessary to deploy an application exist in documents/wikis (and are probably out of date), in peoples’ heads, and encoded in build process templates, PowerShell scripts, and batch files. With RM, it’s expressed as a simple workflow that’s easy to follow. And because it’s easier to understand the process, it’s easier to modify the process. Along those lines, RM captures all of the output of the steps it runs during deployment, so when something goes wrong, you can see exactly what went wrong, which is valuable for diagnostics and resolution.
It gives insight into where your processes can improve. With RM, you can see what builds of software have “passed through” an environment, and whether the build was approved or rejected. This can be very informative. For example, you might see that you’re getting a lot of builds approved in the “DEV” environment, but then failed by the QA team in the “QA” environment. You can investigate the reason why the release was failed, and see that the QA team is failing the builds because they’re finding regressions during their manual tests. This enables you to go back to the dev team and let them know that they need to improve their automated test coverage, because you’d prefer that the QA team was automating their manual tests instead of spending tons of time manually testing builds, only to repeatedly fail them for the same reasons.
As a release manager, it’s easy to see who is responsible for an approval. As an approver, it’s easy to see what needs to be approved. Release Management has a web dashboard that anyone in your organization can visit, and see at a glance what releases are in progress and what they need to be approving in order to move the process forward.
Reliability:
By leveraging the same deployment process for every stage of your release, it gives you confidence that your production deployments are going to work right on the first try. Traditionally, we see that releases to production happen the least frequently, but have the most risk. So you have the least amount of practice where the software deploying properly is the most important. With RM, you test out the deployment process every time you go to Dev, to QA, to Staging, etc. So by the time you push your binaries to production, you have a high level of confidence that the deployment will be error-free.
It formalizes your release paths. Most organizations have some sort of release path (e.g. Dev -> QA -> Stage -> Prod), but you frequently see exceptions being made and someone taking some software from who-knows-where and pushing it out to a Prod environment. If your organization enforces that RM must be used for all deployments, then whatever paths you define are the only paths that can be used. No more skipping stages and risking introducing defects.
Of course, there are plenty more reasons, but those are some major benefits. And of course, if you're interested in improving your release process, you can contact us and we can discuss what we can do for you! For more information on how to get InRelease now Release Management for Visual Studio, you can read my previous post with the main FAQs.
