Today’s blog post is a continuation on from the previous post in this series, focusing specifically on how you can use Azure DevOps Pipelines to deploy a simple JSON ARM template in Microsoft Azure. The idea will be to create a simple build pipeline that will provide you with the baseline techniques to get you up and running. I will follow up this blog with an additional post on multi-stage release pipelines as well as a more advanced post around building YAML pipelines 

If haven’t read my first two posts on this topic, I suggest you go back and read them before continuing on here.

Part 1: GIT & VS Code Integration http://bit.ly/2ZnQqdt

Part 2: Master, Branches, Pull requests and Polices http://bit.ly/2FbG2hf

Prerequisite: Creating a Service Connection

If you haven’t already done so, you’ll need to create a Service Connection for Azure DevOps to use to authenticate to the Azure Resource Manager providers. You can follow the following link to get you up and going http://bit.ly/2wVjHjg

When you create a build or release form Azure, the history (auditing) will be shown as the service connection (Service Principal ), rather than the identity of the person deploying the resource. That said, you will still have a full history of changes in source control and who made those changes.) This approach allows for you to potentially remove Azure rights from the engineering team and provide access to the Service Connection only. Generally speaking, you would still provide the engineer with reader rights to ensure they can view configurations from within the Azure portal. This is a good practice as it ensures that all builds and releases go through source control and pipelines, ensuring no manual resources would be deployed within the portal.

Creating your first Build

Once you have configured your service principal, the first task is to create an empty Pipeline which will be appended as we proceed. For infrastructure as code, I generally like to start with a  blank “Started Pipeline”. The starter Pipeline will produce a YAML file which is essentially the sequence of steps your workflow will run.  YAML has been introduced relatively recently within Azure devops, adding many benefits. However, for the sake of this demo, I’ll be using the classic editor (Visual Designer) to provision the build pipeline.  (I’ll follow up this blog with a post around YAML, particularly for multi-stage deployments.)

Follow the following screen guide to create your build Pipeline. In this case I’ve selected the classic editor, Azure Repos for my source code repository and the master branch for the build to schedule from. Select “Empty Job” and name it appropriately. I have also selected the build agent pool to run as Hosted Windows 2019 with VS2019. You can find out more about Pipeline agents and how they work here: http://bit.ly/2IKG7cC

Save the build but don’t queue for now as we need to assemble the pipeline. The following screenshot shows the JSON template we’ll be using, it’s a simple VNET deployment, parameterised for multiple environments. The build will use the azuredeploy.json and associated parameters file.  

Next we’ll need to add a task, i’ll add an Azure Resource Group Deployment task which will allow us to deploy our JSON template and parameters.  Select your subscription, resource group and location. I have selected UK South as the location and the resource Group as UKS-DEV-VNET. Next link your JSON template and parameters file from your GIT repository

Next I’ll add a further task to create an artifact for our release , which will be used for any additional stages stage in the release pipeline. 

Once the Artifact task is added, queue the build and check that it was successful. As you can see, the build completed successfully and the VNET was deployed to the resource group as we would expect. The artifact was also published, which i’ll pick up in the next blog post. 

NOTE: In the above example, I chose “Incremental” mode for the Deployment mode. The default mode is “Incremental” which means it deploy this template but leave the other resources that are in the resource group in tact.  If the resource already exists then it will update any changes identified with the template. The “Complete” deployment mode creates new resources, updates existing resources and deletes resources that currently exist within the resource group but are not defined in the template. If you choose “Validate” mode it will check that the template is valid but will not provision any resources. 

Artifacts 

Once the build has completed, you can check that the artifact has been publish by following the below screen shot. As you can see, both the template and parameters file are present and bundled together in a zip file which will be used for the release pipeline process.

 

Release Pipelines

I was planning on covering Release Pipelines in the this post but unfortunately it will need its own post.  Stay tuned for the next post where i’ll show you how to use the same template within a release pipeline to deploy multiple environments resulting in the below deployment pipeline. 

In the next blog I’ll cover release pipelines and how you can start looking at advanced YAML deployments. 

Thanks

Sean