Continuous Integration for small teams

Continuous Integration is a great idea, one that ThoughtWorks is completely sold on to. We usually practise CI with the help of CruiseControl running on a dedicated CI server. ThoughtWorks Studios (ThoughtWorks' product division) has even launched a CI product targeted at enterprisey applications called Cruise.

So the idea definitely makes sense for a huge complicated project with a considerable team size. But does it make sense for small projects and small teams? How about if the team is disciplined enough about unit testing, checking into a source repository, integrating frequently, and so on, basically, following the continuous integration practice but without relying on tools? Martin Fowler in his article says, "Although Continuous Integration is a practice that requires no particular tooling to deploy, we've found that it is useful to use a Continuous Integration server."

Over time I've come to believe that having a CI tool is important nonetheless, even perhaps for a 1 dev pair, for the following reasons:

- Rake discipline: why take the risk? why not just automate checking against the chance that people may check-in without running tests on updated code? "To err is human" after all.

- Forgetting to commit some files that remain available on the dev box and hence are not caught by the unit tests run on the dev box before committing. If this is not guarded against (by running the tests on an independent CI server), we'll end up with incomplete code in the source code repository.

- Environment differences: developers usually like having the latest gems or library versions on their dev box whereas the project at hand might depend on some earlier version. In such a case, if a dev codes against the latest api available on his box, his unit tests will be green but they'll break against the library in the source code repository. If we have a CI server with libraries matching those specified for the project, such mismatches can be easily caught.

- Running lengthy selenium tests: I've yet to meet a developer who runs all selenium tests before committing (it's hardly practical after all). Having a CI tool run these tests and different subsets of them at different times (smoke tests every 3 hours, full suite in nightly builds, etc) helps keep developers on track with regard to acceptance tests.

- Having a build always ready to test and deploy: every successful build that comes out of a CI tool is working software that is usable to some extent, and the CI tool makes these so readily available to whoever is interested. The tool makes it really easy to pick and choose between releases too. Plus, it keeps the whole team on the same page as to which version of the software they're on. (Thanks to fellow-ThoughtWorker Mike Mason for this point.)

Tags: technology:agile, technology:tools, technology:thoughtworks Last modified 10:37 Tue, 7 Oct 2008 by AmanKing. Accessed 890 times Children What Links Here Share Except where expressly noted, this work is licensed under a Creative Commons License.