Continuous Integration and the Bad Head Problem

Martin Fowler writes this morning about a problem he sees with the way continuous integration is practiced today:

Once you are happy with your work you commit it to the repository, and then build it on the build machine (either manually for with a CI server like CruiseControl).The problem lies if your commit is bad, anyone who updates will get failing code until you fix it.

I have two thoughts on this…
(1) While the problem is a real one, it’s not really a problem with continuous integration. On the contrary, continuous integration takes a problem that exists on any software development team that uses source control—bad code at the head—and makes it immediately visible. On teams that don’t use continuous integration, bad commits can be buried.It’s much better to fail fast, stop the line, and keep the source repository clean.
(2) Fortunately, continuous integration can provide the solution to the bad head problem. As Fowler notes, the private branch and promotion solution he likes in the Smalltalk source control system, Envy, is cumbersome in most of today’s source control systems. Subversion is reasonably good at handling branches, but still I don’t think I’d want to manage such a setup. Tags (or labels, depending on the system) are a good alternative. Simply have the continuous integration script tag the head LATEST at the end of a successful build. The head may not always be good, but anyone can grab the LATEST tag to get the last known good source code. When this is combined with a stop the line discipline, the LATEST tag should usually lag behind the head by only a version or two, if at all.