In the previous post I discussed Azure DevOps build pipelines and provided an example build of a simple JSON template deployment that resulted in the creation of a new resource group and virtual network (VNET) within Azure.  If you didn’t read the previous post, I suggest you do so to ensure you’re familiar with the build process, the link can be found here http://bit.ly/2WID0XK

In this post I’ll cover Release Pipelines and provide an example of how the same template can be released into different stages (Environments in this case).  The artifact from the build pipeline will be used to create the first environment “DEVELOPMENT”. I’ll then clone the development environment to create “UAT” and “SIT” using the same artifacts from the build pipeline. As you can see from the screenshot, both UAT and SIT have been configured to trigger after “DEVELOPMENT” and “PRODUCTION” after “UAT”

One question that comes up often is: What’s the difference between Build and Release Pipelines considering they can do the same thing? Generally speaking for Infrastructure as code projects, a build pipeline should be used for validation and artifact publication, release pipelines should then be used to deploy your resources into your environments through multiple stages. 

Prerequisites 

The first task will be to ensure continuous integration of the build is switch enabled. This will allow us to enable continuous delivery for our release pipelines going forward. Go back into your build and select “Triggers” and check the “Enable continuous integration”  box as per the following screenshot. The outcome will be anytime the build gets updated, the workflow then automatically releases into each stage. You may not want this, however I feel like it is best to show you giving you the option to choose what works best for you.

Creating the multi-stage Pipeline

The next step is to create the Pipeline.  We’ll create 4 x empty stages, each named appropriately.  Follow the steps show below to create the empty stages. 

Next we’ll change the release trigger workflow. You can change the workflow to suit your needs, but for the sake of the demo, i’ll set SIT and UAT to trigger after DEVELOPMENT and PRODUCTION to trigger after UAT only.  You can set approvals at each stage, I’ll aim to cover those in a further post. 

Next we’ll check that the correct artifact is in place. The artifact is shown to the far left of the pipeline as shown in the following screenshot. If it isn’t you’ll need to add it in and make sure you select the correct version. By default the latest build process is selected, however you could select a specific version or branch if required. 

The next task is to setup DEVELOPMENT, which is our first stage in the release pipeline. As the parameters file defaults to DEVELOPMENT configuration we won’t need to make any changes. Proceed to set this up and move onto creating the SIT stage 

For SIT, UAT and PRODUCTION we’ll follow the same process with a slight variation on the resource group name, location and parameters. We’ll still use the same parameters file but will override the default settings and key in the parameters into the pipeline. In the below example, we’re overwriting the default values of envirnomentCode, locationCode, vnetIPPrefix. This technique allows to use  one parameters file but different parameters for each environment to ensure naming and resource allocation don’t overlap. (You could also have a parameters file per environment)

Test the Release Pipeline

Here’s the fun part, we get to see the release in action. Go ahead and create the release as shown in the following screen capture. Ensure the correct artifact version is selected and then add comments as required. Depending on the size of your deployment, this could take some time. However, for the sake of timing I’ve condensed the capture to only show the highlights

Check the Output 

Go back into the Azure portal and refresh the resource groups. As you can see, we now have 4 x new resource groups with the correct naming convention and location.

 

Final Thoughts

As you can see, Azure DevOps can be a very powerful tool and when used correctly, can be used to ensure Azure deployments are consistent, secure, controlled and aligned to your business requirements. In the next post i’ll focus on more advanced Pipeline configurations as well as using YAML files.

If you would like the templates that were used for this demo, drop me a line at [email protected] and i’ll send them to you.

Thanks,

Sean