Azure DevOps Release Pipelines has a nifty feature called Approvals. Let’s say that you have a couple different stages (aka. “environments”) in your release pipeline – Test and Production.

Without approvals turned on, when your release pipeline is triggered, the Test and Production stages run automatically. If you enable Approvals, you put a break point in between the stages that requires a human interaction – an approval – to happen before the pipeline resumes execution and performs the next stage.

Approvals come in two flavors: pre-deployment and post-deployment. Pre-deployment approvals happen before a release stage executes and post-deployment approvals happen after a stage executes.

For years I’ve been recommending pre-deployment approvals in Azure DevOps Pipelines. I’m here today to suggest that I’ve been wrong for forever.

Post-deployment approvals are where it’s at.

What’s Wrong With Pre-Deployment Approvals?

So what’s wrong with pre-deployment approvals? If you want to a human to approve the deploy to the production environment, wouldn’t you want to have a pre-deployment approval? I mean, “pre-” means “before” and “post-” means after, right?

Well, yeah. Sort of. But it turns out that that isn’t quite how Azure DevOps Pipelines thinks of it.

In my head, I thought it went like this:

In that flow (as I envisioned it), 1) the Test environment stage ran and completed, 2) then the approval fires off and waits for a human to approve or reject the stage, and 3) if the approval is accepted, the Production environment stage runs.

That’s subtly wrong.

Production Release Log Jam

So how can I tell that my understanding of pre-deployment approvals vs. post-deployment approvals is wrong? If I do a pre-deploy approval, what I end up getting is something like this next picture. It’s a pre-deployment log jam for the production environment stage of the Azure DevOps release pipeline. Everything is stuck behind that production approval for Release–24.

A very common scenario on development teams is that a lot of builds make it to the test environment that never go to the production environment. Let’s say that over the last 48 hours that the team has decided that we simply don’t care about the pending production release for Release–25…or Release–26…or Release–27. We do care about Release–28 though and we’d like to push that to production.

So what do we do now?

We’ve got to clear the log jam. You have to go through each of those releases individually and reject them. When you get to the release you WANT to deploy, then you click Approve and it gets deployed.

[caption id="" align="alignnone" width="1846"] Clearing the Deployment Log Jam[/caption]That’s annoying and it’s all because I’m using a pre-deployment approval instead of a post-deploy approval.

What’s Really Happening with a Pre-Deployment Approval?

The fundamental problem here is that I’m thinking that the approval is a separate thing – a psuedo-stage that is separate from the stage. In reality the approval is attached to the stage.

Why does that matter?

The picture below labeled “Production Stage (Pre-Deploy Approval)” puts a box around the approval and the deploy for production. This is what is actually happening. In order for the approval to fire, the production stage has to be created.

If I’m trying to validate the application version that’s been deployed to the Test environment, then I really don’t want to create that instance of the production deploy because I’m not sure that I’m EVER going to deploy that build to production.

Changing Over to Use a Post-Deploy Approval

If I switch that Azure DevOps release pipeline approval to be a post-deploy approval on the Test stage, I won’t get those extra production deploy instances that I don’t want. Notice how the picture below labeled “Test Stage (Post-Deploy Approval)” puts a box around the deploy for test and the approval. This is what we actually want. If the approval request is rejected, then the production deployment doesn’t get created – it only gets created if we approve the test stage deployment. That means no more having to clear out the release pipeline log jam.

Additionally, Azure DevOps will block any additional releases to an environment in subsequent releases if there’s a pending approval. In the screenshot below, Release–30 has a pending post-deployment approval on the test environment stage.

Since that approval is still unanswered, Azure DevOps Pipelines is smart enough to not attempt to deploy Release–31 to test because that would potentially trample whatever we were trying to do with Release–30.

Summary

So hopefully that clears up some of the confusion about pre-deployment versus post-deployment approvals in Azure DevOps release pipelines. In short, if you’re trying to validate something that has already been deployed use a post-deployment approval. If you’re trying to control when you’re going to deploy something to an environment, use a pre-deployment approval.

I hope this helps.

-Ben

– Looking for training on Azure DevOps and Azure DevOps Pipelines? Check out our Getting Started with Azure DevOps online course. Need some help doing Scrum with Azure DevOps? Want some assistance migrating your Team Foundation Server or Azure DevOps Server installation to the cloud? Automated builds and releases got you down? We can help. Drop us a line at info@benday.com.