This week we are going to demonstrate how to setup manual approvals to our multi-stage YAML pipelines. This is achieved through the use of “environments” in Azure Pipelines.
Setting up Azure DevOps
We can add/create environments in two ways. The first is from the environments menu item in the Azure “Pipelines” menu. The second is from the YAML itself – the YAML will create an environment when deployed if it doesn’t already exist. (We saw this first hand when a wry, missing “(“, in our YAML caused us to make a $Dev environment on our first deployment.)

After an environment has been created, we can edit its name, description, security, and approvals, and checks. Let’s click on the approvals and add one to Dev.

In the Add check section, we will select “Approvals”. Note that the “evaluate artifact”, often known as “checks”, only work on artifact container images and aren’t relevant for this project.

We specify who is required to approve the environment. Since most of the time it’s just Sam, we let him approve his own runs, and check the “Allow approvers to approve their own runs”. This is critical for smaller teams, who don’t want to be waiting for one particular approver.

Setting up the YAML
Let’s dive into the YAML changes required to setup a manual approval.
- We need to use a “deployment” job (in red), instead of the regular “job”
- We need to specify the “environment” (in green)
- We need to specify a deployment strategy (in blue). In all of our examples here we are going to use “runOnce”, which fits most small-medium deployments perfectly. If you have a really large deployment, check out the other “rolling” and “canary” strategies. The YAML below is a very simple example, our full deployment YAML can be viewed in our public repo.

We run a pipeline, and when it reaches the dev stage, it stops for approval.

When we click on the “Review” button, we can add comments, and approve or reject the deployment.

Wrapup
Today we’ve shown how to setup manual approvals with a multi-stage YAML pipelines. In general, these manual approvals should be used sparingly, as we don’t want to create too many waiting states in our workflow.
References
- Environments: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-devops
- Approvals and checks: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass
- Artifact policy checks: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/artifact-policy?view=azure-devops
- Deployment Jobs: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/deployment-jobs?view=azure-devops
Love your website by the way. Just wanted to point out a little error. The environment is circled (squared?) in green in the example, not blue. Unless I’m colour blind. Keep up the great work! Really enjoy your posts.
LikeLike
Thanks for the feedback, really appreciate it. Fixed the wrong color comment, thanks!
LikeLiked by 1 person
Is there a way to add post deployment approval
LikeLike
Not directly, as far as I’m aware, there are only pre-deployment approvals in YAML. However, you could add another stage after a deployment with an approval to act as a post-deployment approval, before moving to the next stage. For example, QA stage deploys, and then there is a QAApproval stage, with a predeployment approval.
LikeLike
Well, we had the same setup and someone approved production instead of QA, now we are left to wondering who approved it. We looked at Audit Log but it just says Azure service deployed but no log of who approved it? Is there a way we can find it?
LikeLike
It should be right there in the build, it will say “One check passed”, under the title “Jobs”, and you can see who the approver was.
LikeLike