In last week’s post, we covered taking our existing build pipeline and making it a multi-stage Pipeline with a build stage and a deploy stage. This week we are going to add another stage to our pipeline for production. Since we don’t want the production stage deployed before it has been through QA we will need to hold the stage until it is verified ready, which is what this post is going to be about. If you haven’t read last week’s post, Azure DevOps Pipelines: Multi-Stage Pipelines, you might want to start there before reading the rest of this post if you are new to multi-stage pipelines.
Add an Environment
In order to require approval on a stage is to associate it with and environment and add the approval requirement to the environment. In Azure DevOps under Pipelines select Environments and then click the Create environment button.
On the New environment dialog fill in a Name. If you had actual resources associated with the environment they can be added to provide traceability, but in this example, we are going to stick with the None option.
Require Approval for an Environment
Now that the resource has been created on its details page we can use the three dots to open the menu and click Approvals and checks.
On the next screen click the +button in the upper right corner and then from the lists of check select Approvals and then click Next. As you can see from the partial list in the screenshot the range of check available for approvals is massive.
The next dialog is used to select the uses or groups who should be able to perform approves for the environment. When your approves are set click Create to finish.
Use an Environment in a Pipeline
If you are following along from a previous post not that the Deploy stage has been renamed to QA to make the Pipeline results clearer.
Before:
- stage: Deploy
jobs:
- job: Deploy
steps:
- script: echo Fake deploying code
After:
- stage: QA
jobs:
- job: DeployQa
steps:
- script: echo Deploying to QA
Now we are going to add a new stage for our production environment. Notice that instead of a normal job we are using a deployment job which enables us to specify our desired environment. Deployment jobs have a ton more features than we are using so make sure and check out the docs to see what other options are available.
- stage: Production
jobs:
- deployment: DeployProduction
environment: 'Production'
strategy:
runOnce:
deploy:
steps:
- script: echo Deploying to Production
Save and run the Pipeline and we will look at how this new state presents differently than the Build and QA stages.
Pipeline Results
As you can see in the following screenshot the results of the Pipeline run have has a section notifying that the Production stage can’t run until it has been reviewed. Also, notice in the Stages section that the Production stage shows a Waiting status.
Clicking the Review button will show a dialog that will allow you to approve or reject the stage that is waiting.
Wrapping Up
The extra layer of options provided environments enables most of the scenarios that I missed when I first started playing with multi-stage Pipelines. Having the build and release steps for an app in source control and the added ability to vary them by branch makes this worth it even if I do have to deal with more YAML.
Also published on Medium.