In the far mists of time, I assisted a client with getting a project kicked off and running. Thanks to the developers who were actually running the project (not to me…), the project was eventually quite successful.
One aspect still rankles with me, however…
When the project was started, I brought up the idea of Continuous Integration (CI). “You should be using CruiseControl” I declared, flexing my intellectual muscles. And thus did it happen: the dev. team set up CruiseControl and CVS and also constructed beautiful Ant build.xml scripts to automate all aspects of their project. CruiseControl happily ensured that builds occurred on every check-in. The whole thing ran nicely.
To my way of thinking, however, it turned out that there was no value in the process; the team may as well have not bothered with CI and I eventually came to regret introducing it.
So what was missing?
Simple: testing.
CI is not about automating the build process, it is about automating the testing suite and reporting on the outcome such that code quality is driven upward.
This is what I neglected to make clear: CI is about driving code/system quality, not simply automation.
I should have said “You should be using CruiseControl to automate the suite of tests that will be developed as an integral activity of the project.” To be fair to the team, they did make a few unit tests available in the early days, but workload and pressure of time curtailed that (and therein lies a lesson in its own right: budget more [in all your myriad metrics] for testing than you think is needed at first glance. …but I digress…).
Without the driver of an actively-maintained suite of tests and associated reports, CI became a distraction at best (100% test success rate all the time…whoopee). At worst, it became a cause for angst and fear: in the angst-ridden minds of management, a ‘medium’-sized project instantly grew to be a large, scary one due to its “infrastructure needs” and everybody knows that large projects always fail!
Enough history.
In A Festive Testing Article, I showed easyb used in conjunction with Cobertura and Gant. Here I will briefly show how all that can be placed under the control of a CI system.
My current CI tool of choice is Hudson.
Hudson is a pure Java application, so installation is trivial: download a single war file and run. Actually, through the Magic of Java Web Start Installing Hudson just got even easier.
All configuration is done via the web GUI (as we shall see), so no messing around with scary and obscure XML files.
Hudson has plugins for Cobertura and Gant and Subversion, so it’s all a bit of a doddle…as this screenshot shows:
Configuration for a project is trivial, as shown in this screenshot montage:
Husdon provides a number of useful “information radiators” to show the status of a project. The overview page gives an “at a glance” feel for the project. I like the ‘weather’ analogy here:
More detailed reports are possible, as this montage shows:
A close look will show that RSS feeds are available as well.
The cobertura integration is as painless and easy as it is vital:
(It’s interesting to see the effect of the compiler’s code-inlining optimisation here.)
All in all, a good tool: simple, extensible and solid. What more could one want? Just remember: “It’s the Tests, Stupid!”
