Release Management Approvals Explained

Microsoft’s Release Management for Visual Studio 2013 has a lot of great functionality around authorization and security for releases that are being promoted through environments within the enterprise. One of the great strengths of Release Management is its ability to track actions being performed around deployment in an auditable fashion. Every single approval and manual step performed by humans is captured by the tools (assuming you’re respecting the rules of the game), and every single automated action has an owner that is tracked as that automation is performed in a company’s IT environments.

A Release Path in Release Management defines the environments by which applications will be promoted. It contains the definition of which environments are relevant and who will be participating in that promotion process. The release path below is simple one that contains only a Dev and Prod:

For each environment below, one can define relevant approvers in the workflow. I’m highlighting what I think is the most important of these:

Acceptance: This person or group of people is responsible for accepting a new release into that environment. During the release process, Release Management (RM) will optionally email everyone that is named in that box. And if any one of them approve it, then Release Management will start the automated deployment process.

Validation: This person or group of people is responsible for indicating, generally, that the automated deployment worked. Perhaps as part of the process, the team decides to run a quick smoke test against the environment before considering it “validated.” The team has the ability to define what “validated” means and it could vary by team and environment. It could mean that the QA team has run a regression test, or perhaps the developers have performed a quick smoke test. In this case, as in the case of Acceptors, if any one member of the group approves, then the release is considered validated for that environment.

Approvers: After an environment is validated, then there’s another step called Approval. This is a separate from validation in that – it’s not indicating that the release is working in some fashion, but rather this is the chance for a person or team to approve that the release can be considered “worthy of being promoted beyond.” For a development environment, the development team may be signifying that the release is worthy of moving to QA or PROD. This Approval step is different from the other two kinds in that multiple people or groups can be added. All of the ones listed must approve before the release is considered “Approved” in that environment.


Below is an example chart that I’ve used to map out roles and responsibilities in the release process. This chart was created for a traditionally managed IT organization with separate QA and DEV teams.






[All Developers]

Recommend leaving automated to lower friction of deploying to a development environment.


[Testing Leads]

Recommended a small group make this acceptance to prevent any loss of work from testing team due to errant releases to the Test environment.

[Infrastructure Team Leads]

Team required to indicate that production was ready for a release and the change management process was respected.


[All Developers]

Recommend leaving this automated to prevent friction of deploying to development team.

[All Developers]

Likely, the developers would do a quick smoke test on the QA environment to ensure it’s in working order before testers start performing their tests.

[All Testers]

Whomever has the skills to indicate that the release successfully made it to the environment.


[Development Leads]


Agrees that the release is good enough for QA to begin testing.

[Testing Leads] and [Product Owner]


Required both sign offs before the release is readied for production.

[Product Owner]


Someone that signs off that the release was a success and new features are working as expected.


I have a few patterns that I’ve noticed that seem to be worthy of reminding:

  • Validation and Approval can be confusing. They both take place after the deployment, but I like to suggest that they mean very different things. Validation is something that happens to suggest that the release is good for the “current environment” while “approval” really indicates that the release is good enough for a “future environment.”
  • Acceptance or Approval both are gatekeepers to prevent the releasing of a build to a new environment. When teams use both of these, it can be confusing which one is going to be used for tracking “ready for next.” I’d suggest “Approval” to be used particularly between Test and Prod as the “this is ready” as opposed to acceptance is “the environment is ready” for the new release.

I’d be curious if you have any other patterns of approvals/disapprovals or if you have used these states in other ways that defined above. Please comment and share.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *