Motivation
I've been working on migrating our code repositories from CVS into git hosted on Visual Studio Team Services (VSTS)... formerly Visual Studio Online. While I've reduced the CVS migrations to running a single script, I also wanted to start exploring some of the other CI functionality VSTS offers. Many of our projects are Maven projects, and while Maven builds are supported, I ran into a snag trying to connect to our on-prem Nexus repository. Using the VSTS "hosted" build agents would involve one of a couple of bad work arounds:
- expose an endpoint in IIS to talk to the Nexus repo outside our firewall. While a one-off point to point fix might solve this issue... the scenario is likely to recur, especially when I start looking at deployments
- open a vpn connection from the hosted build agent to the network. Eww. This would feel like a clunky solution, assuming I could get it working at all. I could see authentication being a real obstacle for this route
The obvious solution was a private (i.e. on-prem) build agent running within our network. I shied away from this approach at first because I didn't want to deal with the server configuration (rightly so, yuck!), but it rapidly became clear that this actually was the simpler solution. The final straw was after I tried to create a Hudson job and ended up fighting with git the whole time (couldn't find the installed binary, installed it again, long file names choked, couldn't get authentication working... quelle nightmare!)