One of the sessions for Citcon Europe 2008 was Tom Sulston’s Continuous Integration Cage Fight. Seven geeks lined up to show off their CI prowess, and the first one in the cage was Ivan Moore with his CI server, build-o-matic.
Build-o-matic is an open source CI server written in Python. It’s classic open source in the sense that it’s there to scratch an itch: none of the other commercial or open source CI tools will really get to the bottom of who broke the build.
When several developers check in at once and cause a train wreck of a build, it can be hard to see which individual checkin made the build fail. Build-o-matic will do a binary search over the revisions that make up the build, then build them individually until it can find the offending checkin.
Another nice feature is that you can rewrite history to a certain extent and re-run a build. Someone kicked out the Ethernet cable to the build server? No problem. Re-run the build.
My favourite feature though, is the faces. Build-o-matic can display mugshots of the offending developers. I’m not aware of any other CI server (comments please if you do know) that does this. Ivan says it does have a positive effect on team discipline, and broken builds got taken more seriously. It puts me in mind of this paper.
Related posts:
- Continuous Integration Cage Fight – the entire first series CITCON Europe 2008. Tom Sulston proposes a session for CI...
- Continuous Integration Cage Fight: Buildforge This is the final (and very late) installment in the...
- Build Pattern: The Captive Build Tool Check your build tool into your version control system. Ideally...
Related posts brought to you by Yet Another Related Posts Plugin.
{ 1 trackback }
{ 3 comments… read them below or add one }
We display the offending developers on runcoderun via gravatars (we don’t curently do any sort of binary search to pick out offenders during commit pile ups, though).
For example: Failing build for rspec
Another option is to simply build on every single commit. Computer time is cheap; human time is expensive. Plus, there are other benefits to having a build for every single commit. For example, you never have to “cut a build” for QA — once the changes are committed, it *will* get built, and QA can simply grab the build when it completes.
Rob, nice touch. I’d like every CI server to have Gravatar support
Matt: I’m with you on cutting a build. We should never, ever, do that by hand.