Monthly Archives: August 2009

Story: I call it “The Wheel”

This anonymous user gets top points for offending the most people in this Atlassian Giveaway entry.

I was tasked to evaluate continuous integration systems for my workplace so I tried CruiseControl, Hudson and Bamboo. CruiseControl was a pain in the ass to configure, and I couldn’t get it to work – so stuff that. Hudson was really cool, and good looking, but it failed the Maven sample projects I was using – so stuff that.

Bamboo trial worked flawlessly, and was really the only one I could recommend.
However, our “architect” had CruiseControl on his brain (and used it at home on his .Net projects) and insisted that was good enough, but not good enough for him to lend a hand in configuring it!

He then got another developer to have a look at CruiseControl, who also failed to set it up. Said developer then, without telling anyone else, goes and writes his own continuous integration system with a PHP web interface, making system calls to Ant and Maven, using shell scripts to fetch from Subversion. We used that for months, but eventually sanity prevailed and we got Hudson, because it was free and had matured enough.

(Image thanks to Fimb)


6 Big Visible Continuous Integration Tools

I love Information Radiators. You can have all the Twitter plugins you like, but unless you have the updates on the wall, you’re missing something. Here’s a few examples:

  • Green Screen: Martin Andrews just released this. It’s a Sinatra app, and looks like it works for Hudson – perhaps with some tweaking it’ll work elsewhere.[Ruby]
  • CruiseControl Monitor: Sudhindra Rao wrote this for any CruiseControl. I covered it here. [Ruby]
  • Big Visible Cruise: This works for CruiseControl.NET, and runs on Windows. I haven’t had the pleasure.[.NET]
  • Hudson has a plugin to do it, of course.[Java]
  • Radiators: Marco Jansen wrote this in 2005. It’s the earliest example that I’ve seen. I daresay it needs some love by now.[Java]
  • Update: Sam Newman has been flexing his Scala muscles and wrote Big Visible Wall recently. Don’t tell him this, but his code’s generally worth checking out.
  • Update: Atlassian also have wallboards. I’m in the middle of re-skinning XFD. David Ron made Big Visible Cruise Web.
  • Update: Stuart Grimshaw wrote cc-radiator for CruiseControl.
  • Update: Steve Fenton wrote Cruiser for

I find that I always want to provide other project metrics as well. There’ll be a point at which I’ll start hacking to add more information. This is how I ended up with the radiator at Guardian Unlimited.

Know of others? What works with your CI server? Comment here and I’ll update this post.

Image thanks to ninnet.

Deployment is the goal

We get things so ass-backwards. How do we get code from development team to the end user? I’ve written an article on this subject at InfoQ. I hope you like it.

News and Stuff, August 14

The Build Doctor has been needing a proper doctor this week, so this post is going to be brief:

  • Atlassian released Bamboo 2.3 this week, with better EC2 support. There’s also a new Grails plugin.
  • Urbancode are doing a Webcast on ‘Build and Deployment automation for the lean economy’ – which should be interesting.
  • I’m ashamed to be in the same industry as the software development team as these guys.
  • Extreme Integration – not sure I like the term, but it possible has more pizazz (as a term) than continuous deployment.

Have a nice weekend.

Story: Rolling your own

Thanks to Daniel Spiewak for this great story from the Atlassian Giveaway.

It was a dark and stormy night. No, actually it was a pleasant summer day, but daylight lacks a certain dramatic flare which is so necessary for a good story, especially a story about build systems.

I was working as the semi-lead developer for a mid-sized project run out of London, UK. My job was primarily to work on the Java clone of the Cocoa client application. Through a very clever and dangerous bit of hackery, the Cocoa and Java clients shared a single, Java-based backend which communicated with the server via xml-rpc. Because of the project’s architecture, there were a number of inter-dependent sub-projects. As I was working on a clone of the Cocoa client, it was often necessary for me to build a new copy of the client after each new change. However, this was, in and of itself, a non-trivial undertaking. Once you added the building of the other sub-projects both individually and as dependencies, and my days started to look more and more like the “dark and stormy” variety.

Now, each project (with the exception of the Cocoa frontend) had an Ant build script which I had carefully crafted. These build scripts would invoke each other as need be, meaning that I could build a copy of my Java clone by simply invoking its build and allowing Ant to handle the rest. This solved a lot of my dependency headaches, but building every single project was still a tedious undertaking. Thus, I build another layer of abstraction above Ant, consisting primarily of Ruby scripts hacked together on top of Ant. The idea was that I could invoke my master build script, passing a list of project descriptors, and this build script would determine the optimal way to build each project and its dependencies. I was even able to rig this script with cron so that it automatically built a new version of each sub-project as necessary.

Unfortunately, this build script worked a little too well. My boss got wind of it and decided that it should be put onto the main development servers as a sort of continuous integration solution. This sounded like a good idea at the time, but it ultimately led to far more trouble than it was worth. I got sucked into the position of permanent build system maintainer; and, given the hacky nature of the system’s architecture, it ended up being quite the position. As more sub-projects were added and more flexibility was needed, I actually had to rewrite the entire system from scratch more than once. Looking back, I’m actually astonished by the sheer number of hours I spent cursing those scripts into behaving.

I was probably on my third or fourth rewrite before I realized the idiocy of what I was doing. I had literally created a full continuous integration build tool from scratch (complete with web admin system and XML-RPC API) without ever considering the alternatives. It only took me a few minutes of research to realize that Hudson, Cruise Control, Bamboo, and really any CI system would solve exactly the same problems without any need for hacky scripts or unnecessary effort. It took my boss a little while longer to come around, but eventually he too saw the wisdom of relying on a pre-existing solution rather than rolling our own convoluted hack job.

The really amazing part of this story is how I didn’t even see what I was doing until very late in the process. It started out as just an innocent collection of scripts to aid my own development process. Each step I took toward hacky maintenance hell was so gradual, so subtle in form that I completely failed to see where I was headed until I was already there. An while my build system didn’t actually require a defunct Pentium series processor to run, it does certainly certainly qualify as a bizarre polyglot, home-grown build system which should never have been allowed to fester.

Image by Mark Cummins


Getting a wedgie on the last mile – at

The last mile is where software becomes a production code, hairs turn grey, and a lot of pizza gets eaten. It’s the last place you want a wedge.

Read more of my guest post at – thanks to Jurgen Appello for the opportunity to spread the message.

(image from dullhunk)

Continuous Integration: GitHub announce CI Joe

Thought the world had enough Continuous Integration servers? Guess again. The guys at GitHub just released their open source effort, called CI Joe.

It follows the Unix model and will run any command that you give it. As you’d expect, it integrates well with GitHub, using Git hooks to trigger builds. They use Campfire obsessively at GitHub, so CI Joe uses Campfire for notification.

I’m thinking that this one might have legs, as long as the GitHub guys are eating their own dogfood. A Continuous Integration service that fits hand and glove with GitHub will be good value.

GitHub continues to impress us here at Build Doctor HQ. I’m even hosting my private Puppet manifests on the $7 a month plan. I hope they spend it wisely.

Github Logo image via qrush

Update: This page is now referenced on my ruby-git Continuous Integration page.

Continuous Integration 1920’s style

Totally missed this in 2007. Thanks to Oscar Centeno for finding this in the archives.

Hosted Continuous Integration: Run Code Run

Hosted Continuous Integration is here. Run Code Run have announced support for private projects. What does this mean?

They already build open source projects from GitHub for free – for an example see my own Build Rosetta Stone. Now, you can build a closed source project – which isn’t visible to the world via GitHub.

There’s a strong Ruby flavour to Run Code Run. They appear to support a lot of RubyGems natively so that you don’t have to. Being so Ruby-centric can’t hurt as the Ruby community seem to have a strong preference for Continuous Integration.

They might want to do something about all the broken builds on the open source projects however. About a third of the projects are broken and many of those have ben broken for months. Perhaps I’m obsessive [okay, I am obsessive] , but those broken builds imply that people are wanting Continuous Integration in name but not deed.

Anyhow, those aren’t the paying customers. I’d give my eyeteeth to see some stats on build success and failure once they have a few hundred projects to mine. Well done, guys.

(Image taken by Flrnt)

Sun enters the Continuous Integration business

Sun sell a Continuous Integration server. We should have seen that one coming. See Kohsuke Kawaguchi’s announcement. Looks like you buy it as an add-on to the GlassFish stack. Pricing is here. Looks like they’ll support a branch of Hudson, and not the open source releases. That’s not unexpected.

Strategically, it seems like a good idea. They’ve been building their own stack for years, from operating system to web server. Sun just pimped it with a very popular Continuous Integration server. I think It’ll be a good proposition for Java shops. There’s a huge market for Hudson for other platforms, but I’m not sure that Sun will be chasing it.

(image by Silveira Neto)