This session was a demo of several CI servers.
CruiseControl, build-o-matic, Hudson, JetBrains TeamCity, Rational BuildForge, Zutubi Pulse2, Cruise.
I presented first - build-o-matic. I think my talk was a bit rubbish because I didn’t get across the USP of build-o-matic. What is the basics of a CI server? I think one of the basics is to tell you which commit broke the build.
If there are multiple commits between builds, then build-o-matic is the only CI server that finds out which commit broke the build (farm and binary search). None of the others do, or even have the infrastructure to do it (apart from the EAP version of TeamCity sounds like it now has the infrastructure). Note that Pulse and TeamCity have a valid alternative approach to the problem with “personal builds” - which (I have used the TeamCity version of this feature) is quite cool.
I was asked after the talk why I had bothered to write my own CI server. Well, when I wrote the first version of build-o-matic, most of the other CI servers either didn't exist (eg Hudson) or were so new I hadn't heard of them (eg TeamCity). The ones that did exist didn't do what I wanted.
I was also asked why I didn't write a plugin for Hudson or TeamCity to achieve the same goals as build-o-matic. I don’t believe it would be possible to write a plugin for Hudson or the current version of TeamCity to do it, because they have no concept of running the build on a previous revision of the code (although the next version of TeamCity, the EAP version, will - so it may be possible with that).
I have used TeamCity and think it's very good. Cruise looked very interesting. I heard good things about Pulse from people who had tried it. I can't see what the fuss is about Hudson (maybe I'm just not trendy enough). The others looked very complicated.
I'm not sure whether it has a future. The other CI servers have teams of people working on them full time (even though they still can't tell you which commit broke the build) and have lots of enterprise friendly features. I might keep working on build-o-matic - but many of the features that I'd like it to have are already in TeamCity. Talking to Yegor Yarko of JetBrains - the makers of TeamCity - it sounds very much like TeamCity is going to catch up with build-o-matic on it's currently unique features in the next version, which makes me wonder whether it's worth continuing with build-o-matic.
Jason Sankey wanted to add a comment - but unfortunately comments are switched off - so he sent me an email, which I've included here:
It was cool to see the binary search for the breaking build revision in build-o-matic. This is a feature that has been on our wish list for Pulse for a while, and in particular our customers with long builds would like it. I've yet to see anyone else who has actually done this.
Since the earliest versions of Pulse we have included a feature called "changelist isolation", which will trigger builds for each individual revision -- so if you have the resources to run a build on every revision you will be able to easily see when the build was broken. Obviously we don't advertise this feature enough!
It is also possible to trigger builds at a specified revision using the Pulse web UI or remote (XML-RPC) API, so in theory you could script the binary search externally and drive Pulse to build the desired revisions.
Posted by ivan at October 6, 2008 7:26 AM