What Continuous Build Systems Got Wrong
By kto on Feb 28, 2009
Pearls Before Swine had a great comic recently, not that I have any issue with people that don't agree with me:
I have always been a big fan of regular automated build and testing during development. With every project I have ever been on, if there wasn't some kind of nightly build and test of the team sources, or my own sources, I set one up. Anyone working in software development knows or should know the importance of having this constant monitoring of the product status. So don't get me wrong, I think that all the continuous build systems out there are great to have.
BUT... They all seem to have grown up around the single central source repository model, and I think they have developed some bad habits. The ideal to me is that a changeset or change to the source repository is built and tested BEFORE it ever sees a shared team area, and the continuous build of the team area should be only a final verification. The build should never be broken, we should be able to have golden (or more golden?) changesets all the time. With a Distributed SCM like Mercurial, this is actually quite possible. With a Distributed SCM a changeset can be created, then the repository can be merged with the parent repository, and everything can be fully built and tested before the changeset is ever seen by other developers.
So what we need is a continuous verification build system.
I know that the ElectricCloud ElectricCommander product supposedly has a 'trial run' type of feature I was told about, which is a step in the right direction. And I have heard that the Hudson system may have some 'test build' plugin someday.