CruiseControl != Continuous Integration

Advertisements

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.

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

4 thoughts on “CruiseControl != Continuous Integration”

  1. I completely agree and am still amazed at the misunderstanding around the term ‘Continuous Integration’; it has now become a buzzword which is being used by managers to implement ‘good software development’. If there are no tests, no extra conditions on the build are being checked (e.g. reports, etc.), and no one is actually fixing a broken build – then this is not continuous integration; rather it is just ant being run irregularly!

  2. I have to disagree with you on this, Slava… I don’t believe that the build script that developers use, day in day out, should know how to do a production deployment. For one thing, production deployments may not be a simple turn-key operation.

    A build script should know how to deploy for the developer – otherwise it can’t run automated tests. The continuous build server should be able to deploy a build for manual testing, either via the build script or some other mechanism (at Wotif, we use CruiseControl to publish builds to a staging server, where our testers have scripts to deploy a named build).

    Production deploys, however, can be more complex. In our environment at Wotif, for example, we upgrade one node at a time. While the upgrade step is largely scripted, we don’t want to have this completely automatic at this time.

    What I would say is that the build server should publish, as an artifact of the build process, the packaged software ready for the “turn-key” deployment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s