Running additional VSTS agents in Azure

When working in a smaller team or on a small project, you usually aim to reduce costs of your development pipeline. This is also true for huge projects, but there we're talking about bigger budget and money. When working with a free VSTS subscription, you're limited to only 1 hosted pipeline(and 4 hours / month) to run your builds and release. To be honest - it's nothing when you have real CI/CD set up and working. However, if you consider a fact, that you also have 1 private pipeline, it's possible to mitigate this problem.

Hosting your own agent

VSTS allows you to host and connect your own agents running on your machines. It's a great way to take advantage of a private pipeline when hitting a limit of 4 hours and allows you to have a backup when you need more builds and releases in a short period. To use an agent you need two things:

  • a machine which will host it
  • an installer

A good idea to get a machine is to use your existing Azure subscription(especially when you have MSDN/BizSpark) and create a VM, which can be started and stopped easily. Another thing are capabilities of your machine, which have to match requirements for your build(e.g. MSBuild, Grunt, gulp and so on). 

Get agent screen will help to both determine what is needed to install it and how to do it

Because of capabilities, using different(you can choose from Windows/OSX/Linux) agents can be easier or more difficult. In the future I will show you how to set up e.g. Linux agent, for now we'll focus on the Windows one.

The easiest way is to create a Visual Studio VM from the marketplace in Azure Portal. That way you will have most components needed for a build already installed and configured. 

Usinga Visual Studio virtual machine will ease whole process a lot

To get an installer you have to go to Agent queues screen in VSTS and click the Download button. As present in a one from the screens above, information needed to install and configure it are already there so I won't reinvent a wheel and just ask you to go through it by yourself.


Configuration of your agent is pretty straightforward. When you enter following command:

C:\your_agent_directory> .\config.cmd

You'll be asked a couple of questions regarding your VSTS account, a name for an agent, agent pool and a method of authentication. The easiest way to authenticate is to use PAT(Personal Access Token) which can be generated here: https://{your_account}

Once you've configured your agent, you can run it with a .\run.cmd command. If everything's all rights, when you go once more to the Agent queues screen, you'll see your build agent available in the selected agent pool:

Building and releasing on your agent

So far so good - we have additional build agent, which can be used in our private pipeline. But what we have to do to schedule a build and a release? 


Go to the Builds screen. When you click on the Queue new build... button, you will be asked to select a couple options related to a build. The one we're interested in is Queue. Just selected the one which have your build agent configured and click Ok. Your build should start though you've used all available minutes from the hosted pipeline.

Selecting a different queue will allow you to use a different pipeline


Releases are a bit tricky. When triggering a release you have no option to specify a queue. To do so you have to go to a specific release definition and find Run on agent link above release steps. When you click on it, it will show you another screen, when you can find Deployment queue list, from which your private pipeline can be selected.

Somehow hidden Run on agent screen allow you to run your releases on your own agent


In above solution you have to consider costs generated by using a VM to perform builds and releases. Currently you can buy another hosted pipeline for 40$ so it's two times less than a minimum VM needed for a Visual Studio. On the other hand, you can automate it so it works only in your work hours = saving some money. If you have an available subscription like BizSpark, you can save even more money. Both solutions are viable but as you can see, starting another build agent is a very easy task, and can help you when you either want to control usage of your pipelines or to build something, what couldn't be built by a hosted agent.



Triggering a release using a build tag in VSTS

For most cases triggering a release based on finished builds on a specific branch from your repo is sufficient. But what if you'd like to have a little more control over what is released depending on some specific conditions? Well you could create different build definitions, specify different triggers on so on. In this post I'll present you a little feature, which you could find helpful in some specific scenarios.

Build tags

Each finished build in VSTS can be marked with a custom tag, which will help to categorize it. You can even think about building a "tag pipe" like this:

  • #compilation_finished
  • #packages_downloaded
  • #artifacts1_copied
  • #...

which would help you to decided what to do depending on at which step your build failed.


Finished build with a "Tag_ToBuild" tag attached. 

There's one issue with tags however - you have to add them manually. What if you'd like to automate things?

Adding a build tag

Some time ago the team responsible for VSTS introduced a new command, which can be used to add a build tag directly from a build. To use it you can do following:

  • add a new Powershell build step to your build definition
  • paste following command:  Write-Host "##vso[build.addbuildtag]your_tag"

With this simple script each finished build will have your_tag attached to it. At first glance it doesn't look very impressively, but when you consider passing a variable or using output from the previous steps, it becomes much more powerful.

Triggering a release

So far so good - we now how to automate tags so it's possible to incorporate them in our releases. To do so go to your release definition and then click on the "Triggers" tab.

"Triggers" tab with a tag added to constrain CD a little 

Along with artifact source and branch triggers triggers you have an option to add tags, which will be used to check whether a release should be triggered. Now each time a build finishes, a release won't triggered unless specific tag was provided.