Michael Swanson has posted an article
about continuous integration, which covers much of the same material as Mike Clark's new book
on project automation. The idea is a simple one: every 15 minutes (or hour, or whatever), an automated process checks out a clean copy of the project source, builds it, runs the unit tests, and generates a report, so that project stakeholders always know where the project is.
What adds spice to Swanson's and Clark's descriptions is the various devices people use for communicating with developers. Red and green LavaLamps are one way: red means that something's broken, while green is the all-clear. I (briefly) thought about wiring up a hula dancer doll to let the Helium
team know where they were. ("The job's not done 'til the hula dancer shimmies" has a kind of ring to it, don't you think?) However, I find the white-noise hiss of headphones three cubicles away annoying enough; trying to design complex software to the sound of a six-inch figurine's grass skirt doesn't really appeal...
There is an open source tool for managing continuous integration, called CruiseControl
. It uses Ant
to build code, then generates an HTML report, sends email, or whatever, all at regular intervals.
Or at least, it's supposed to. Michelle Levesque spent several hours trying to get it set up on the Debian Linux box that hosts our projects, without luck. Like too many open source projects (including Subversion
requires a lot of configuration, including re-configuration of previously-installed packages. As a result, many fewer people will use it than should.
Contrast this with JUnit
. If someone had told me five years ago that thousands of programmers would routintely write unit tests within my lifetime, I wouldn't have believed it. JUnit
has changed that, not only because it's easy to use, but also because it's easy to set up.
Which is why I'm worried that we're probably going to incorporate ViewCVS
, at least initially. I have nothing against ViewCVS
per se---it's written in my favorite language
, and I'm in favor of recycling software. My concern is that it's yet another external dependency, which means yet another thing that administrators might have to upgrade, downgrade, sidegrade, wrestle with, curse, or whack. If Helium
is going to be used by other institutions (which I'd like it to be), ease of installation is crucial.