Using release pipelines is a pretty common thing for agile developers, but not necessarily for IT Pros. However, they can still very much benefit from that process when working with their IT pro artefacts such as scripts, ARM templates, runbooks, Dockerfiles etc. to get more agile and keep environments stable and clean. In this post I will demonstrate how to build a (very) simple release pipeline from A-Z for ARM templates. Have fun!

Step 1 – Create a VSTS account

I will use VSTS or ‘Visual Studio Team Services’ for my projects and for the release pipeline. If you don’t have an account yet, you can create a new one. VSTS can be used for free for small teams, check out the details here.

Step 2 – Create a new VSTS project

Once logged into my VSTS environment, I create a new project.

Now I open the new project in Visual Studio. Depending on your settings and environment you might need to authenticate from Visual Studio into VSTS again.

Now select a path where the project files will be stored locally on your box.

Ready! I can now start adding content to the VSTS project. In this example I will create a new Visual Studio project of type “Azure Resource Group” and select a blank template.

After opening the appropriate JSON file (the effective template) I will add a single Azure resource of type “Azure Storage Account”.

This will add some code to your JSON file. I will not go into any details about the ARM template here, we just use the Storage Account as a simple example of a resource we will deploy. As this project is under source control, we now need to commit the changes (happens locally) and then push it back (to VSTS).

Using the VSTS portal, you should now see that the repository was pushed back.

To keep things simple in this example  I only use the master branch. I a real environment you should use dev branches to change existing code that are later merged back into the master branch.

Step 3 – Build the release pipeline

After the repository has been pushed back, nothing really happened other than updating files, file history etc., but now I’d like to configure a process that will be followed when the ARM template is updated in the repository. To make this happen, I create a new release definition in VSTS.

There are predefined processes available, but to keep things simple I select an empty process.

A release needs artefacts – in this example that’s an ARM JSON template and a parameter file (check your Visual Studio project). As they live in a VSTS Git repository we will take then directly from there.

Now we want to deploy the template directly into our production environment.

The first (and only) step is to deploy the template to an Azure resource group. Configure the step as needed and select the needed artefacts.

Remember that some ARM templates require an input when they are deployed (defined in the parameter section). My template also has a parameter to define the storage account type. Now as we cannot give any input in an automated release, we need to configure the values we are interested in.

By clicking on “…” the parameter file will be opened and all parameters are displayed. You can now configure the values as needed.

Save your work and close the editor.

Step 4 – Create a release manually

Now we are ready to create a first release that uses our (simple) pipeline. Create a new release and select the Git commit id you want to release.

You should now see a new release and can easily follow the pipeline process.

Once the box gets green the release has completed all the steps in the pipeline and we have a first successful release. Check if a resource group has been created in your Azure subscription and if you have a storage account.

Delete the resource group as we will create another release in the last step of this post.

Step 5 – Continuous deployment

We now come to the final step. To follow the continuous deployment concept I’d like to automatically create a new release every time the git repository is pushed back to VSTS – because this means that something has been updated in the ARM template. Edit your release definition and enable the continuous deployment trigger. Then select the git branch you are interested in.

Go back to Visual Studio and make a change on the ARM template, then commit and push. A release should now be automatically be created.

Congratulations, you successfully created your first release pipeline based on a (hopefully) simple-to-follow example! There are many more options available when configuring the release definition, and for a production environment the process might contain many more steps, include a deployment to a test subscription first. Then after testing, it can be automatically released into production. You can add approval steps and many other options, so make sure you try those as well.

I will create more blog posts for this topic soon, so stay tuned! Meanwhile, happy releasing!

Cheers
Marcel