From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…
Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!
Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉
Nevertheless, the first thing to do is to go to the settings of your project. And browse to “Services”…. Here we’ll be adding the connection to our Azure subscription (via a service principal) and also the link to Github. So let’s start with our ARM Service Endpoint ;
Here you have the “typical” setup with a “Service Principal” ;
And the same for Github ;
Here you have two options, via “Grant Authorization” or via “Personal Access Token” ;
Next up… Setting up our build definition. Let’s browse to “Build & Release” and select “Builds” ;
And then press the “+ New”-button on that one ;
Here you can choose a template if you wish, we’ll be starting on an “Empty process”-template ;
First up, we’ll be linking our Github repository (or any other repo platform you would like) ;
As we want “CI”, let’s go to “Triggers” to enable it ;
In “Options”, you can see what agent queue you are leveraging. The “hosted” one is the managed one by VSTS, but you can also roll your own if you would like ;
This phase is optional, but recommended. We’ll kick off by running tests. For the templates, I used pester tests ;
As I want nice build graphs on my dashboard, I’ll be publishing those results… 😉
Now let’s package the code, by creating a zip file of it ;
Next up… our release flow. It kinda works the same. Let’s go to “Build & Release”, and then “Releases ;
Click on the “+”button and select “Create release definition” ;
You can verify this afterwards in “Triggers” ;
And in “Artifacts” you can verify the link to our build artifacts (read : the zip files) ;
Now let’s create a flow… where I’m stating the same remark towards to agent.
As a small pro tip in between to safe you on budget. You can leverage Azure virtual machines as build agents. The first build agent is free in VSTS. And you have a given amount of free hosted build minutes. So you could create a flow where your hosted build agents spins up a custom build agent. The custom build agent does the dirty work (releasing/deploying). Where the hosted agent will finish up the job by shutting down the custom build agent again. Cloud as your budget friendly enabler!
As we referenced several variables… you can configure those with “Configure variables” per environment.
This way you can use the same build steps, but have can mutate it a bit accordingly. Like setting the resource groups and selecting parameters. Or even do token replacements!
Enjoying the results
Now let’s do a change in our code… And we’ll see the build kicking in, testing the code, creating our artifact (zip file) ;
From dev to test to acceptance to production… We can even create an approval flow if needed. And… last but certainly not least… we can setup our dashboard! 😀
Hands on lab!
Want to try this out yourself? Check out this repository ; kvaes/TasmanianTraders-IaC-Network
It includes all the code needed to get this up & running. It’s even got the json files you can use to import the build/release definitions.
I hope this post did not fry any brains… I truly hope this post inspired you to set the next step in regards to ARM (Azure Resource Manager) templates! Once you get familiar with this way of working, you’ll cannot imagine going without anymore. 🙂 Though in the end, it’s all about ensuring that your organisations gets the best quality on deployment time. In addition, you’ll also won’t worry too much about “yet another deployment”. You know the system has got your back and will filter out any errors. And if any (errors) got through, then you can revert back to the previous various.