It’s 11pm, you’re tired, the pizza’s run out, the milestone is due tomorrow, but you’ve finally fixed that crash bug. Now all we have to do is test it works, build a release version, package the assets and ship it off to the publishers.
Hang on, where’s my release build check list:
- Sync to Perforce for code and data
- Run assets through conditioning pipeline to make sure they’re up to date
- Build test build
- Run automated test suite
- Build release build
- Upload via ftp
When the milestone has passed you take a look at your release check list and realise that you could run through this every evening, or every 4 hours, or even after every check-in. But who would you find to do all that grunt work, sitting there at 6pm waiting for builds to finish. Fortunately, you’ve got head screwed on right and you’re a programmer, you can automate it!
Welcome to the exciting world of Continuous Integration. You may have heard about CI from such famed software as Hudson )
The basic function of a Continuous Integration server is take a list of tasks, run them after specific triggers have fired, and then report the results to you. Sound like something you could knock up a batch script for doesn’t it? On the face of it, it doesn’t seem that complicated, but as usual once you start getting into the nitty gritty you’ll see where Jenkins really shines.
Here are some of the little things that I’ve found my CI server needs to do. Again nothing complicated, but if I had written the build system myself it would have started becoming far less simple. In other products I’ve often found these features are flaky or simply don’t exist.
- Integration with my SCM of choice that isn’t Subversion (Perforce, Mercurial, etc)
- Getting changelist numbers out of my SCM of choice that isn’t Subversion
- Emailing specific groups of people depending on the build
- Running builds after SCM checkins.
- Running builds only after a previous build has succeeded.
Jenkins (and it’s compatible brother Hudson) have a wide array of community supported plugins, far more complete than say, CruiseControl.net which is perhaps its most similar competitor. So far I’ve been able to accomplish every thing I’ve required with either an out-of-the-box install or a well-supported plugin. Not only that but I haven’t done a single line of XML wrangling and very little documentation searching, both of which were a daily burden in CruiseControl and BuildBot. Jenkins has a straightforward configuration UI built into the application and I managed to get my first project building in minutes.
For my current usage, I’ve employed the Mercurial plugin, so I can get source updates from our Mercurial server; the Warnings plugin, which extracts compiler errors for common programs, but also allows a generic regex so I can monitor warnings generated by our documentation builder; the python plugin, so that I can write build steps in python; and the xUnit plugin so that I can pull out unit test results and graph them. Everyone likes a pretty graph don’t they?
There you have it a slightly gushing but well meaning introduction to Jenkins. If you want to recommend a rival electronic build butler, let me know in the comments.