RazorSPoint
RazorSPoint

Do ARM Test Deployments on Build!

Improve Pipelines with ARM-Templates

Sebastian SchützeSebastian Schütze

In the past, I wrote about an article on how to improve development as well as CI / CD pipelines with ARM-Templates. Those seem to be quite successful. Even though, I am sure everybody has it’s own opinion about some of the details I take the opportunity to lay out my current opinion to provide some solutions to problems I had or ideas where I thought that they could improve the quality of your pipeline in regards to deliver value. I will write a serious of articles that give you some tips. So let’s get right into it.

Once I had one idea. Generally, if you want to improve the quality of your code usually you write unit tests. With ARM-Templates and Pester this is possible. You can read an article from Amine Charot about it. He suggests using Pester to test not only syntax but also to check if you have the right structure in your ARM-Template (e.q. right schema or if the expected resources are included).

He mentions that you can test your template without deploying it. But I am asking: “Why not deploying it as well?”. We could just deploy our written ARM templates as part of ensuring quality.

There are just some things we need to make sure:

How could it basically look like? See the screenshot below to get an idea.

Let’s go through the main parts. It is actually simple if you at least know how to generally deploy ARM-Templates with Azure Pipelines:


First, generate a unique prefix for each resource name. This could be a GUID. Because of name restrictions you probably have to cut the GUID. It would not be 100% unique but for most cases enough. I in my case used a short PowerShell script to generate it and saved it into a pipeline variable, which I create on the spot. Below you can see the script I used.

$guid = New-Guid 
$v = [string]$guid 
$v = $v.Replace("-", "") 
$v = $v.substring(0, 6) 
echo "##vso[task.setvariable variable=randomGuid]$v"

You could also use this to randomize your resource group name. Since this is only a very short lived deployment you maybe want to have a unique resource group name. Also I delete this group by default at the end anyways.

Second, you just deploy all the resources that you need, but in every place where you need the unique prefix, you can use the created variable “randomGuid”. For example, when we look at the parameters I use for creating an Azure Function, the template parameter I override in the deploy task, could look like this.

Third, destroy the resource group (see screenshot below) after you are finished. But this task should always run, no matter if it succeeds or fails. Because often you deploy templates partially and you don’t want to leave anything behind. For this, you need to use the “Custom condition” option that you can use which each task. Below you see the custom condition which in my case should only run if my variable “KeepDeployment” is set to zero. This variable is by default zero. Which means I can choose on manual build to leave the resource if I wanted to check some things.

eq(variables['KeepDeployment'], '0')
Use the ‘Azure Resource Group Deployment’ task to delete your resource group.

So just to make it more complete for you. I will add the full YAML code of the stage where I make the test deployment in my build pipeline.

Summary

Overall you would have the possibility to improve also the quality of your infrastrastructure by deploying it in your build pipeline. But there are several things every body needs to take into account and check for them selves like

Nevertheless, there is quite some potential within this to improve your IaC quality before releasing it to any environment.


Also published on Medium.

Sebastian is an Azure Nerd with focus on DevOps and Azure DevOps (formerly VSTS) that converted from the big world of SharePoint and O365. He was working with O365 since 2013 and loved it ever since. As his focus shifted in 2017 to more DevOps related topics in the Microsoft Stack. He learned to love the possibilities of automation. Besides writing articles in his blog and German magazines, he is still contributing to the SharePoint Developer Community (and PnP SharePoint) to help to make the ALM part a smoother place to live in.

Comments 0
There are currently no comments.

This site uses Akismet to reduce spam. Learn how your comment data is processed.