Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

Azure DevOps Pipelines: Understanding Pre-Deploy and Post-Deploy Approvals

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.

A simple test/prod release pipeline
A simple test/prod release pipeline

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:

How I thought approvals worked
How I thought approvals worked

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.

The Deployment Log Jam
The Deployment Log Jam

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.

Clearing the Deployment Log Jam
Clearing the Deployment Log Jam

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.

Pre-deploy Approval for Production
Pre-deploy Approval for Production

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.

Post-deploy Approval for Test
Post-deploy Approval for Test

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.

Pending Approval on Test
Pending Approval on Test

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.


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.

The completed Azure DevOps release pipeline
The completed Azure DevOps release pipeline

I hope this helps.


– 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


4 responses to “Azure DevOps Pipelines: Understanding Pre-Deploy and Post-Deploy Approvals”

  1. PeeTee Avatar

    That is really interesting insight, thanks 🙂

  2. Aaron Shumaker Avatar
    Aaron Shumaker

    I agree this achieves an ideal behavior, but I think that the approval notifications referencing the test stage is scary given that the approval is really approving the production push. In an organization where some non-developer project leads/managers may have authority to finalize the approval/release to prod, and already have alot of demands on their time, having something that doesn’t clearly convey what they are really approving seems like a bad idea.

    It’s a little bit like coming to them, asking for their signature on something, and the cover page says it’s approving a day off, but what they are really signing is the annual budget.

  3. A Mer Avatar
    A Mer

    I think the ideal for us would be to have the qa person post-approve in TEST, and also have a pre-deploy to PROD.
    Would that get around what Aaron posted?

  4. […] in Azure DevOps serve as a control mechanism for managing various stages of the development pipeline. They help ensure that the right people review and approve changes before they are deployed to […]

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.