We’ve been doing a lot of recruiting at “Wotif”:http://www.wotif.com/AboutCareersPositionDetails.jsp?jobId=7 recently, so I’ve been doing a lot of resume skimming and interviews of late. And I’ve noticed, amongst many other things, statements like this: “Oh, yes, we did continuous integration; we used CruiseControl!”
Folks, using “CruiseControl”:http://cruisecontrol.sourceforge.net is not continuous integration. And that’s coming from a former committer on the CruiseControl project.
This is a point I’ve tried to hammer in to various people a lot: All CruiseControl really does for you, at its core, is:
* monitor your version control repository for changes;
* run your build script;
* let you know how the build attempt worked.
This doesn’t add up to continuous integration, by itself. After all, your build script may only do a “Hello World” message.
To be fair, most people wouldn’t have build scripts _quite_ that stupid. But how many people have build scripts sophisticated enough that they are “continuously integrated”?
Furthermore, continuous integration isn’t just about tool support, though I am firmly convinced tool support helps. Continuous integration, at its heart, is a cultural commitment, and requires the buy-in of the people in the team. No tool can do that for you.
Martin Fowler wrote the “original paper”:http://www.martinfowler.com/articles/continuousIntegration.html that spawned the CruiseControl project (though Continuous Integration, as a concept, had been documented before that). He lists ten items things that make up Continuous Integration – CruiseControl only provides three, maybe four. A good build script, with a damn good set of tests, can give you three more items, and can help a lot, particularly with giving confidence and creating a “turn-key” deployment. However, for the rest (and even just to get those!), you still need the buy in from the team.