Thursday, February 5, 2009

Continuous Integration: Should we always use it?

I had a conversation with a friend last week that got me thinking a lot about Continuous Integration.  I was explaining, with pride, that I had configured Hudson to build, run unit tests, and deploy SharePoint web parts for my current project.  His response went something like this... "Yeah, Continuous Integration is ok, but it's not really for everything."  His tone showed that he thought its place was in the minority of projects.

That really surprised me.  In 2009, should we be skeptical over the use of Continuous Integration?  Has the case for it not already been made?  This statement was from someone with a similar background to mine, so I was left wondering if I was missing something.

Certainly, there must be a case where we don't need Continuous Integration.  Maybe if you are the only developer on a project and you can build everything yourself.  Wait a minute!  That basically describes my current project!  I am the only person building web parts.  I really value the security of having my code built, tested, and deployed in a an automated fashion on a machine other than my own.  This at least gets me out of the "well, it worked on my machine" excuse.  I also like the fact that Hudson provides a complete history of past builds.

Were there other possible reasons to not use Continuous Integration.  Maybe there is a Return on Investment argument that could be made.  If the amount of effort exceeds the benefits produced, maybe it's not worth the work.  I can immediately see a few holes in this argument.  A tool like Hudson makes the effort invested negligible.  As long as you can script whatever you want to run in CI, Hudson lets you just plug it right in.  If scripting your build and deployment is so expensive that CI isn't worth it, you're probably looking at a symptom of other problems on your project.

In all my reading on Continuous Integration, I don't think I've come across arguments that were just simply against it.  I have seen some arguments that it is part of an evolution, and it does not quite solve all of our problems in its current form.  However, that is more of an argument that we haven't taken it far enough yet.  That's not an argument against using it at all.

So, basically, my conclusion is that Continuous Integration has a place on any professional software development project.  The tools available make the price of entry fairly low.  The benefits by far outweigh the cost of implementing CI.  I didn't really intend for this entry to detail all of the benefits.  This topic has been well articulated in several books, papers, and and many other blog entries.  If you want further reading on the topic, start with Martin Fowler's article.  Books available include Pragmatic Project Automation and Continuous Integration: Improving Software Quality and Reducing Risk.  In the end, I believe its the job of any responsible software developer to ensure their projects take advantage of the benefits of CI.


  1. Looking forward to hear how you set up testing webparts in hudson.

  2. I totally agree. I am responsible for tools and methodology for an IT organization, trying to achieve better quality and throughput.

    Quality is assured by CI as you don't do it manually, if it worked yesterday - it should work today, otherwise it's the code.

    Throughput is achieved by having CI set up with Hudson and other simple tools integrated. Subversion, Maven, Hudson, Nexus and Jira.
    It's set up once and all projects simply use it with as little local settings as possible.