In my last post, I showed you how to build a simple delivery pipeline that automated the deployment of an Azure Web Application as code changes were made and committed. In this week’s post we will look at how we can add a testing stage and an approval phase to build resiliency into the delivery pipeline. By the end of this post we’ll have built a delivery pipeline that will automatically deliver code to a test environment, we can then make checks to confirm we are happy with the changes, before approving the automatic deployment of the same code to a production environment. If you want to follow along then you’ll need to have completed all the steps in my last post.
We’re going to take advantage of Web App deployment slots to add a test environment and configure a multi-stage release pipeline. When you create an Azure Web App using a Standard or Premium service plan you get a number of deployment slots with the service plan. We can use deployment slots to build additional environments such as dev, test and staging, then make changes to our applications without affecting the production copy.
To create a new deployment slot, select ‘deployment slots’ from the sample application created in the last post and select ‘add slot’.
Name the slot ‘Test’ and select the existing Web App from the configuration source dropdown menu. Once the deployment slot is complete you can select it and view details as per a standard WebApp. Note the URL is the same as our previous WebApp but with ‘-test’ appended.
We’ve now got a test environment to deploy into but we need to add it into the delivery pipeline. Back in Visual Team Studio Services (VSTS), select ‘build and release from the top menu (1), select the ‘releases’ tab (2), select the ‘build definition for your Web App’ (3), and then select ‘edit’ (4).
In the ‘pipeline’ tab of your release definition, open the ‘+ Add’ drop-down list and choose ‘clone environment’.
Select the new environment that has been created and rename it ‘Test’. Next we need to reorganise the environments in the pipeline. Choose the ‘pre-deployment conditions’ icon for the Test environment and set the trigger to ‘after release’. The pipeline diagram changes to show that the deployment to the two environments will now execute in parallel.
Place the production environment after the test environment by selecting the ‘pre-deployment conditions’ icon for the production environment, set the trigger to ‘after environment’, then select Test from the Environments dropdown list. The pipeline diagram changes so that the pipeline is now deploying the application in the correct order.
Open the Tasks dropdown menu and select the ‘test environment’ (1). Select ‘deploy Azure app Service’ (2). Check the box to ‘deploy to slot’ and in the slot dropdown (3) then select the ‘Test deployment’ slot you created earlier (4).
The pipeline as defined at the moment will deliver an application to environment and then to production. We want to add in an approval stage where we can check we are happy with the code deployed to the Test environment before deploying it to the production environment.
Select the ‘pipeline tab’ in the release definition (1), select the ‘pre-deployment conditions’ icon on the production environment (2), enable ‘pre-deployment approvals’ (3), specify an approver (4), and finally save the release definition.
Our work on the pipeline is complete so let’s test a release. I’m going to make a change to the carousel.css file to change the colour of the text from grey to green.
The deployment pipeline automatically detects the change made once we have committed it, and deploys the code to the test environment. We also receive an email notification for the approval required to deploy to production.
At this point we can visit the URL for the Test deployment slot and confirm we are happy with the changes made.
If we are happy with the changes and that the application is still working we can approve the deployment back in VSTS and the same changes are then deployed to the production slot (note that you can also defer deployment to a scheduled time if you prefer).
And with that, we have configured a delivery pipeline to automatically deliver code changes to a test environment as they are made and committed. We can then review the changes made in the test environment before approving deployment to a production environment. In the next post of this series we will look how we can build in to automated testing into the delivery pipeline.