Adding Approvals to Azure DevOps YAML Pipeline
Introduction
Just over a month ago I started using Azure DevOps, and initially found it to be a really good product. I started setting up new repos and pipelines, and really loved the great balance of verbosity in the YAML pipelines.
The company I work at has, rightfully so, added an approval step to their release pipelines, which have been setup manually in the UI. Of course I want everything to be defined as code, so I set out on a search of how to add this in the YAML file. Sadly I couldn’t find anything resembling an approval task.
Well, thanks to @sesispla on GitHub, we now have a solution to this problem. All credit for finding the solution goes to him.
Creating an Environment
What to Do
Go to your project in Azure DevOps, and select Pipelines from the side-menu. From here choose Environments. Now click in the top-right corner on New environment. Enter the name of your desired environment (e.g. production), and leave the Resource option on None.
NOTE: This only needs to be done once for the entire project. Multiple pipelines can target the same environment.
Why it Works
For this specific use-case, Environments are what allows us to add the approval, which will be shown in the next section. That being said, Environments bring with it some great advantages. The most obvious benefit is a log of all jobs that’s been run, targeting a specific Environment. This allows you to get an overview of exactly when something has been deployed to production, within a given project.
One of the less obvious features, and so far not so widely developed, is the ability to specify resources as deployment targets. As of writing this, you can only specify Virtual Machines or Kubernetes namespaces. I can see how this can be a great feature once it adds support for App Services.
Adding Manual Intervention
What to Do
Once your Environment has been created, select it from the list within the Environments menu by clicking it. Most likely it will be empty right now, but this’ll change once you start doing deployments. Up in the right corner, click on the three-dotted menu button. In the dropdown-menu that appears, select Approvals and checks.
A new screen will now appear saying “Add your first check”. Either click on the Approvals option in the middle of your screen, or on the ‘+’ sign in the top-right corner, and then Approvals.
Now you can add the approvers you want to add, just like you would in the regular Approval step. If you add more than one reviewer, remember to open the Advanced settings where you can set the amount of people required to review, in case you don’t need everyone to approve.
Why it works
This part will make more sense when you see how the environment is specified in the YAML file, but essentially you tell Azure DevOps that you want to deploy to a given environment, after which Azure triggers all the checks you’ve set in a given Environment.
Specifying the Environment in YAML
What to Do
In your YAML pipeline, either add a deployment task, or modify your existing one, to include the environment property. Here you should specify the name of the environment you created the approval checks in.
Why it Works
This step is largely self-explanatory. The deployment task is something provided by Azure by default (Read more here). Once your pipeline is triggered, and it reaches the deployment task, Azure will run all the checks in the specified environment.
Running the pipeline
Now all that’s left is to run the pipeline. Once you trigger it, you can click into the specific run of a pipeline. When it reaches the deployment stage of your build, you will see a box pop up, telling you that a review is needed, before the build can continue.
Conclusion
Following the above steps, you should now be able to have a mostly complete continuous pipeline from integration to deployment, defined in a single file rather than relying on a click-and-point interface.
One of the drawbacks about this approach, is how it’s more about the approval step of a Release pipeline, than the normal Manual Intervention, where otherwise everyone would be able to resume the Release. But at least this brings us one step closer to Infrastructure as Code.
Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬.
To join our community Slack team chat 🗣️ read our weekly Faun topics 🗞️, and connect with the community 📣 click here⬇
