Too bad! You still need a private build agent when using VSTS
As a true cloud born developer on the Microsoft stack, my ALM | DevOps solution of choice is VSTS. Next to this being the defacto standard in my environment (bubble), I believe it also is the best solution out there for building and releasing applications at this point in time. However when it comes to build & release agents, I still go for self-hosting my agents every single time. Although this might sound like more work, or more expensive, I believe it to still be the superior option when it comes to the cost/performance ratio. In this blog I will try to explain why this is so.
Why you don’t want to use the 240 free minutes
In VSTS you get up to 240 free build minutes every month. Great! This might sound like enough for your purposes. However, you can spent these minutes only when an agent becomes available to service your build and release. And this is not so great. Often it takes a minute or two before this happens, so longer then anyone cares to wait for a build. Let alone for one to start.
Also… do you really want to take the risk that you are out of free minutes, just when you need to quickly deliver a bug fix? Of course not. So relying on these free minutes is not a good idea. Neither from a performance perspective as from a risk/cost perspective.
Why you don’t want to use a managed agent
The alternative, Microsoft-CI/CD seems like the best way forward then. Just a couple of clicks and you have bought yourself a fully managed hosted agent for roughly $ 40 a month. These hosted agents are constructed before every single build (or release) and destructed right after. This way, a high level of isolation between builds is guaranteed, and you don’t have to wait for a shared agent to become available. A wonderful thing when working in the cloud.
But there is also a dark side to this construction and destruction of agents. It means that executing a build or release will always be slow. Everything (task steps, sources and even NuGet packages) needs to be downloaded every single time. Especially when you are building small solutions that you want to build and release very quickly and in short iterations, these delays and the (lack of) performance in general of hosted agents becomes frustrating. A build that takes only two seconds on your development machine, might easily take up to five minutes on a private hosted agent.
Running a private agent
With this in mind, you want to consider running a self-hosted agent, what Microsoft calls self-hosted CI/CD. This means that you download the VSTS build agent from VSTS and install and run it on a machine of your own: an Azure VM for instance. Every VSTS account comes with support for one self-hosted agent and you can buy more pipelines for $ 15 a month.
What this will get you is a dedicated agent that is constantly standing by to run a build or release for you. So no maximum number of build minutes you can use, nor any more waiting for builds to start. However, that’s not all. Experiments in three different contexts have also shown, that these builds are much, much faster. For example, see the graph with build times on a small project I recently did here:
What this shows is that the build times of this particular build went from anywhere between four and six minutes, down to less than one minute!
At this point you might be concerned about the costs of running a self-hosted agent, because next to a pipeline in VSTS, you also need a VM to run your agent on. This will come to roughly $ 65 a month, if choosing the cheapest standard VM that can run an agent (A0). Almost double of an Microsoft-hosted CI/CD. And that’s not a really powerful VM. However, this does not have to be the true cost of your VM. There are two ways to safe on costs:
- If you use your build machines only for a limited number of hours per day and not in the weekends, you can use Azure automation scripts to turn them on and off on demand. If done well, this can save you roughly 60% when adhering to working hours and weekends. This would make buying a VM from the D-series feasible.
- Another approach is not using a standard VM, but a B-series burstable VM. The results I talked about before, were achieved on an B2s VM, available for $ 47 a month. These type of VM’s do not always have the full capacity of the CPU, but are allowed to burst up to double of there CPU capacity when needed after underusing the CPU for a while. This unused/burst usage pattern fits really well with build agents. Next to this, they also support SSD disks. So in practice this will give you a VM with 4 cores and SSD storage for less than $ 50 a month. A very good price, looking at the performance benefits.
Final thoughts: other improvements
In practice, the Microsoft-hosted CI/CD is often not fast enough. Not only due to the provisioning of agents, but also due to the lack of caching for package managers and general lack of performance on the VM. For this reason we are still stuck with self-hosting our CI/CD agents. However, this is possible without incurring (almost) any extra cost, while gaining five times the performance.
Of course, this will leave you with the responsibility of patching the VM you are running your agents on. However, just patching Visual studio on one computer that allows for no incoming internet traffic is doable. Also, there is a great tutorial out there from Wouter de Kort, where he shares how you can create your own build agent image and keep it up to date automatically.