In this post I’m going to show you how to use Visual Studio Team Services private build agents. Visual Studio Team Services (VSTS) supports two types of build agents, hosted and private. Hosted agents run on Microsoft servers in the cloud and private agents are hosted by you. When you create your VSTS account you will see two agent pools, Hosted containing your default hosted agent and Default which will be empty. I’ll be adding my private build agent to the Default pool for this demo.
Hosted agents make it easy to get started and work great for building most applications but there are limitations since you have no control over the build server environment, hosted agents can also be used to deploy to Azure. If the VSTS build environment doesn’t meet the requirements for your application build you can host your own build agents in your own environment. These locally hosted agents can also be used to deploy your application locally.
To get started click on the Download agent link in your agent pools control panel, unzip the file and run ConfigureAgent.cmd. Fill in the prompts, they are pretty self explanatory but keep in mind depending on your application your build can get very big and I/O intensive, it could be worth it to put your working directory on a separate drive. If you get stuck the documentation is over here.
If the installation was successful you will see the newly installed agent in your pool.
Note: Initially I installed the agent to run as a service using the default local service account and it worked for most of my applications but I had one build that required running as a specific user account. As per the documentation I used the “C:\Agent\Agent\VsoAgent.exe /ChangeWindowsServiceAccount” command from an elevated command prompt to change the service account but that didn’t work. The service didn’t update with the new credential and the agent showed as off line in VSTS.
To fix the problem I had to run “C:\Agent\ConfigureAgent.cmd” again specifying the new account name and then it worked.
Next step is to configure certain builds to use my on-premise agent by default since the build won’t work using the hosted agent. The simplest but least dynamic way is the set the build to only use agents from a specific pool. In this example I set the build to use the Default pool.
You can for instance limit builds that take very long to a certain pool so they won’t prevent other applications from building. Depending on the complexity of your environment and projects it would be better to use demands and capabilities as well. On your agent there is a list of capabilities and you can add custom ones, in this case I called the capability OnPrem.
In my build definition I can now specify the agent to be used for building must meet this demand.
Now it will choose an agent from the pool that satisfies the demand. If you create a rule that cannot be satisfied, you’ll get this error message to warn you or else your build would just be stuck.
Free VSTS accounts include one free private agent and charge $15 per agent there after. Even if the hosted agent is able to build your application look into the private agents, depending on the machine hosting the agent, your build can be a lot faster.
