Controlling build quality using Build Tags and VSTS Release Management

On many occasions a release is a composition of many different artifacts, like product MSI’s, Shared Assemblies, Documentation etc..

I like to compare it with a big box that you use when moving. You fill it up with all sort of little boxes and other stuff and you label it. The big box is the release, and the stuff inside the box are the release artifacts.

In the software world the artifacts are most of the time produced by different teams, and, at a certain time everything should be put in the box to ship the release.  In this multi-team and 1 release scenario, I would like to have the teams to be responsible for their own builds and produce an artifact. There is one big release pipeline that gathers all the build that are marked as “Ready” and creates a release from that.

But how do you shape that within VSTS? How can you set the build quality of builds? And how can you choose the right ones in your release pipeline?

In the rest of this post I try to explain!

Setting up the product build

First we need to create a build that represents a product and delivers an artefact. In my setup I build an empty Visual Studio Solution and drop the build artifacts. I call this build [Product1]

Setting the build Quality

The build quality is something which was available in the XAML builds but is not in the vNext build engine. Instead we can use Tags to set some labels on the build. For example “Ready”

But this is a manual action. It would be better if we can do this automatically OR after some approval of product owner or tester. And this is exactly where Release Management fills the gap.

Creating the Release Definition

First I set up a Release Pipeline for this Product build and add a Powershell step to execute a script that will handle this for us.

As Linked artefacts I choose both the Product1 build, and the Git Repository on GitHub (which was introduced in this update).

Then the PowerShell that will handle this task. It can be found here on my GitHub repository. Let’s look at some snippets.

We first create some parameters. As you can see I also have a RestToken as a parameter. When we do not use the Release pipeline, we can just send a Personal Access Token to use this script from the command line as well.

Then, I check if the script uses the Release Management System.AccessToken that you should enable on your environment. For that read my blog post here. Or, if I should use the Personal Access Token that I provided as a parameter, and build up the token to send with the REST Calls.

Then I call the Build REST API to set the tag on the Build provided.

The build provided, is a variable that is provided to you by the release pipeline. Every linked artefact, is provided as a release variable in the format, $(RELEASE.ARTIFACTS.NAMEOFBUILD.VARIABLE). More on this can be found here

Setting Approvals

Calling the script

Then the last step, is to add the SetBuildQualityScript.ps1 to our pipeline and set the parameters to point to the Product1 build and set the Tag. For example

-BuildID $(RELEASE.ARTIFACTS.Product1.BUILDID) -BuildTags “Ready;Completed”

When you then create a new release and approve it, the build quality will be set on the build automatically!