In the beginning there was CruiseControl, the original Continous Integration tool. Most people, including myself, cut there teeth on CruiseControl. Then, over time, a couple of opensource projects started spawning commercial tools, like AntHill and AntHillPro, and I thought all the new innovation in CI tooling was going to be by commercial companies.
Well, I am glad to see that isn’t the case. At the heavy/powerful, and light and simple end of the spectrum there are two new tools to add to the evaluation lists: Hudson and CruiseControl.rb. Neither of them is currently listed on the Continuous Integration Server Feature Matrix page, but they both offer new approaches and features to CI.
Hudson is Java based, and provides similar functionality to CruiseControl and Continuum. It is better then CruiseControl in that it allows you to configure new jobs via the web interface, and has a reasonable well thought out plugin architecture. It looks like it has a leg up on Continuum because it seems more polished, and designed to manage larger numbers of projects.
The key things that I like about Hudson is that it supports distributed builds, and scheduling builds outside of Hudson, and just reporting results.
The distributed builds are based on deploying a “slave agent” to each slave builder. You can specify for your projects if they need to be built on one specific server, or if they can be built on any server. It also tries to move long running builds to the slaves versus the master project. You will have the usual challenges of deploying all the tools to each slave builder however. But if you are building many heterogenous projects, like C code, PHP, Java, Ruby, then you can simplify the setup task by having seperate server for each type of environment. For one client, we have seperate Continuum instance building a single .NET project on Windows, and this would have been a great place to have a slave builder instead.
The external builds stuff is really exciting, and an original idea. If you already have a build setup, like maybe doing builds on Linux and Solaris for example, and don’t want to throw it away, then you can just tweak Hudson to read in the result of your external build, so you can get the reporting and notification abilities of Hudson! This is a great way to slowly introduce CI into an organization that has preexisting processes without causing a lot of disruption.
CruiseControl.rb, while sharing it’s name with CruiseControl and CruiseControl.NET looks like a completely redone implementation in Ruby. Instead of just being a rewrite of CruiseControl, like CC.NET is, it has been written in a thoroughly “Thinking in Ruby” fashion. Out goes the complex XML config file, in comes a very simple Ruby script for configuration. Still there are two seperate processes, a build agent and a dashboard gui (a simple Rails app), but both are started up together. It definitly passes the 15 Minute rule, as I was able to deploy it and have it running in no time. You can see it online at http://labs.opensourceconnections.com:3333, where I have dropped two projects, Horseshow, a Rails project, and Boozer, a user auth plugin for Rails…
This looks like a great choice for projects who are already using Ruby, and don’t need/want the complexity/power of a full blown CI tools like Continuum or Hudson. Where is looks like it falls down is if you have tens of projects that you want to manage. Or lots of different SCM systems. You also have to log on to the server and use a command line
cruise tool to add projects. And edit a project config ruby file to specify who the recipients are. But, for a small team where sharing out access is fine, or for just a couple projects, it looks like just the ticket. For Ruby projects at least, its the new King of the Hill.