Previously in another blog post, I laid out a quick summary of Continuous Integration (CI) and Continuous Delivery (CD) in Visual Studio Team Services (VSTS). Today we’re going to expand a bit on those DevOps processes to better suit your (or your clients’!) needs.

With CI and CD, a build agent is required—that is, a place where your code is sent to be compiled and then subsequently deployed. By default, VSTS gives you the option to use a hosted agent. This is an entirely a cloud solution; you can just choose one of the hosted agents to build and deploy your code and you’re all set. But there are a couple of drawbacks with this…

First of all, the hosted build agent might not have all of the required software to handle all of your CI and CD needs installed on it by default. For example, we recently worked on a project where an updated version of Microsoft’s Data-Tier Application Framework was needed to properly deploy a DACPAC with temporal tables to an Azure SQL instance. This is a showstopper if you just want to use a hosted agent, but is easily remedied by creating your own custom build agent.

Secondly, VSTS has a limited number of build minutes available to your hosted agent at 240 minutes per month by default. Let’s say that during your Continuous Integration process, it takes four to five minutes for your code to be sent to the agent, built, and then upload to a drop folder. Your remaining balance of build-minutes would decrease by that much. This limited hosted agent can be suitable for many needs, but if you have a handful of developers all working on a project, checking in code changes multiple times per day, you could run out of build minutes in a hurry. Fortunately, Microsoft does let you purchase additional build minutes if you want to stick with the hosted agent.

So, let’s say that you have determined that the hosted agent does not fit your needs and you want to build your own. Good news! It is incredibly easy! I won’t get into too much detail here, but the basic outline is as follows:

Start with creating a VM in Azure to be used for your build agent. It can be any size you want but I would say stick with a lower core count as building applications isn’t too process-intensive. Also I would recommend using one of the Visual Studio Community 2017 (or whatever the latest version is at the time) pre-build images for your VM, as Visual Studio is almost always a build dependency. Technically the agent software is cross-platform-compatible with Windows, OSX, and some distributions of Linux, but if you goal is to build regular .NET applications, you should stick with Windows. The agent software is available for download in Microsoft’s GitHub repository. There are detailed install instructions here, with all the steps needed to install the agent software and link it to your VSTS instance.

After the agent is installed and connected to VSTS, you should start installing any kind of build and release dependencies that your build might have. Some common ones that I always go for are:

Once you’re done installing any software you need, restart the VSTS Build Agent service on the VM. After the service restarts, you can go the “Capabilities” tab of your Agent Queues in VSTS to make sure that it recognized all the software you installed.

Side note: VSTS will let you know in advance of building your code if any dependent software that is required is not installed on your build agent, which is a very handy feature. In this Capabilities tab, you can also manually specify the path of an executable if for some reason the agent didn’t pick it up.

Now that you are done with the agent, the last thing to do is to wire up your Build and Release Definitions in VSTS to use your custom agent over the hosted one. Now you no longer have to worry about running out of build-minutes or running into a dependent-software roadblock… exactly the sort of worries that DevOps is meant to take away in the first place!