0

Currently in our business we use Team Services in the cloud with a single self hosted build agent which runs locally on a server in our office.

As we are expanding and taking on more work there is an increase in the number of queued builds. As a result we are considering adding additional build agents to cope with the load.

Unfortunately adding additional agents costs money and its often difficult to for us to justify the cost. Essentially I'm interested in whether or not there are any free alternatives to the TFS build agent. I'm still looking to keep Team Services but somehow integrate the builds locally for free.

A colleague of mine has mention Jenkins as a build server but I have little experience with this application and I'm not sure if an agent is still required from Team Service's point of view.

I'd be grateful if you could let me know if you're in or were in a similar situation and what your views or solution was.

1

Well I have been using Jenkins for a long time, but our shop is a Java shop. If you are currently using TFS then you are probably using the Microsoft stack. So long as there is a command-line compiler available you can use Jenkins.

Jenkins home turf is building Java code (retrieved from Git, SVN or CVS) and saving the compiled results into a Nexus repository. However it is easy to create jobs that have no Java component. A job is simply a command line script. If you are familiar with Linux, it is like having cron jobs with a capable management interface on top. You can easily set up a Jenkins job that collects a bunch of parameters on screen, then runs your script with the collected parameters. Some of the tasks we use Jenkins for are:

  • Compiling and releasing Java code
  • Assembling and releasing batch process code (.zip files) that often have no Java component at all.
  • Deploying code to various execution environments (the job retrieves the code from Nexus, SSH's to the server, copies the code to the right place and bounces the server)
  • Running nightly batch jobs. This has nothing to do with code building but works very well.

Jenkins will provide a nice interface for monitoring build progress, and keeps all the console output in easy to access files. It also supports jobs running in parallel ("flows").

One quirk is that everything is a "build" in Jenkins terminology. It looks a bit strange to see "build failed" messages when a deployment job fails.

I suspect there are some third-party plugins available that may make using the Microsoft stack less painful.

So in short, it will do the job nicely, but you will need to do some work to write your jobs. Why not download and install it, and give it a try?

|improve this answer|||||
0

It's now becoming a distant memory...A few years back I worked with TFS, C# and C++ for commercial products. The main take away from that was that MSBUILD was our friend. It was the execution engine that TFS Build used to do the build steps. Once we figured out how to get our builds to run from MSBUILD command line, with a bit of script around them, we never depended on TFS build agents or Visual Studio for builds again.

At that time licensing was no problem. Our MSDN licenses covered everything needed Any of this may have changed in recent years. The C# compiler was included in .Net Framework and didn't even require visual studio. Some Microsoft technologies beyond straight C# had more dependencies and complexity.

There is an MSBUILD plugin for Jenkins. https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin

I have never used that. But it seems worth a look.

Having used Jenkins with Java (Maven and Gradle instead of MSBUILD) and iOS XCode projects, I find it simpler to deal with than TFS. It's worth a look. With luck maybe the plug-in works well and no scripting needed. If I were working with C# again, I would give it a try.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.