CI check-in policies


CI check-in policies

A coworker mentioned TeamCity as an alternative to CruiseControl.NET due to its ability to run pre-commit builds, among other features. The book Continuous Integration (Duvall) mentions this under “The Future of CI"; the author is positive towards the concept of automated queued integration.

Borland has a similar product (Gauntlet); pricing is “contact vendor,” so it’s probably steep. TFS Team Build 2008 may support this as well.

In thinking about it, I am not convinced that this feature is a good idea in many companies. Scenarios where it might cause issues include:

In short, I think there are exceptions to the rule “the build must always be green.” My preferred rule is “the build must not be red for very long.” I’d add to that “check in working code as soon as possible.”

I realize that there are ways to work around most of these issues (with Shelvesets in TFS, for example). I’d rather not have to. (I’m not recommending writing tests that depend on shared data, either, but it happens.)

One way to avoid breaking the build is for developers to run private builds; before checking in changes, the developer checks out the latest code, builds the solution, and runs the tests (optionally using a build script). The book mentions that the (pricey) Pulse CI server can automate this. If people write good tests, this should take only a few minutes. The difference here is that private or personal builds are optional; if a developer feels that the situation warrants bypassing them, he can explain that to the team.

TeamCity is still worth evaluating; I simply wouldn’t enable this policy.

(Note that TeamCity is free until you hit 20 users or 20 build configurations; after that, it’s $1,999. CruiseControl.NET is open source.)

Your Host:
Copyright © 2000-2013 by William Sorensen. All rights reserved.