I have used Visual Studio Team Services build system a few times in the past so I have a basic understanding of how to configure it. Recently I have been trying to get an AngularJS / .NET solution building on this system. Whilst doing this I discovered some new things I didn’t know before.
The Hosted Build Agent can’t do everything
on a web site and run a few gulp tasks, some of which leverage JSPM.
It didn’t take long to discover that whilst Node and NPM are available through the hosted agent, JSPM is not. I did spend some time seeing if I could do a global JSPM install at the start of each build, but it proved unreliable and the build time went through the roof.
Ideally I would have discovered this earlier. To avoid you hitting the same problem take a look at this. About half way down the page the software available to the hosted agent is listed.
Setting up your own Build Agent and Integrating in VSTS is easy
So what do you do when you want to use the hosted VSTS offering but can’t use the hosted build agent?
There are a couple of options but they both start with your own Build Server. This can be on or off premise but the natural progression from the Software as a Service (SaaS) implementations such as Visual Studio Online is to use an Azure VM. I won’t go into the details about setting this up. Google will give you plenty of pointers.
Build times are key to a successful Continuous Integration feedback loop, so when you set up the VM you’ll have an interesting cost vs power decision. Go for the most powerful VM you can afford. You might be able to control costs by scheduling the servers up time to suit the needs of your project such as powering it down overnight and at weekends. Remember you are charged for compute and for data transfer so think about how often your builds will run, where your code repository is located and whether that will cause you to incur data transfer costs.
Once you have the VM up and running setting up the build agent is quite straight forwards. This article discusses the details but in essence you:
- Download the agent zip file from the VSTS configuration portal
- Unzip and run it on your Build Server
- When you run the agent you are asked to configure it by pointing it at your Visual Studio Online account giving the agent a name and configuring it to run as a service.
The final step is to configure the VM with all the software necessary to build the solution. Bear in mind none of the software on the hosted build server will be available by default so you will have to install and configure what you need.
Once you move out of the comfortable world of Visual Studio and MSBuild you find that most of your build tools require configuration and any build task that needs them must be able to find them. And that means managing the path environment variable.
When I was looking at this I decided to try to make my build server as similar to the hosted ones as possible. This was based on the assumption that if I did this I would reduce any unexpected problems.
I used the script in this post to determine the environment variables as seen by the build server. By creating a simple one step build task that ran this script I could switch between hosted and my custom build agent to get the path as close as possible.
There is one other gotcha worth mentioning. By default node.js configures NPM to use the currently logged in user’s roaming profile folder for storing downloaded packages. This is not appropriate for a build server so you should customise the build server’s node.js installation to use a different path. You also need to set up the security settings on the folder to enable the correct access. This stack overflow post discusses using
npm config --global set prefix “<new_npm_folder>" npm config --global set cache "<new_npmcache_folder>"
That’s what worked for me.