Hudson – a lot of things just done “right”

For the past nine months, I’ve been nowhere near thinking about build systems and processes. A week ago, I had the occasion to spin up a continuous integration server for some internal project work. It had been a while, so I did some quick page browsing to hear about the latest and greatest there, and the Hudson system floated to the top of the list.

Installing a basic Hudson instance is about as easy as you could ever imagine. One war file, than you can run from a single command line if you want. Or slap it into a stock servlet container – all your choice. The default configuration is all sensible and obvious, and best of all the working configuration is all through the web interface.

There’s a huge list of really positive things to say about Hudson – it’s plugin set is monstrous, and clearly growing under active development, it supports remote slaves and distributed builds on multiple platforms, it’s developed in a commonly known, platform neutral language (java – not my favorite, but well known). But the real win of Hudson is that it’s functional right out of the box and damned easy to use, with the entire interface *really* through the web browser. In any other “plugin” system, I’d expect to have to be downloading something and dropping it into a directory; with Hudson you can download and then upload the plugin through the web interface. The dev team and contributors have really made this system a stellar example of effective and focused user interface design, functionality, and good defaults.

I’m not even building Java applications – this is all getting used for doing CI with python code actually. And there’s folks who are building all sorts of things including iPhone apps with Hudson.

If you’re thinking “huh, maybe I should…”, check out Hudson. It’s a quick check – one download, one command-line, and you’re rolling.