# Monday, December 03, 2007
If you are following a continuous integration strategy, breaking the build should be a big deal.  Most of the time, if the build is broken it's because someone forgot to check in a new file, or because they didn't update before committing their stuff.  Those are both pretty easily avoided.  One strategy that helps with missing files is to do your work in a task-specific branch, get everything checked in the way you think it should be, and then check out that branch to a separate location on your local system.  If it builds there too, then you probably aren't missing any file.  If you are, you'll know about it before you break the integration branch. 

As far as not updating before committing, there are a couple reasons why that might happen more than you would like.  If the build is constantly breaking, then people will be less likely to want to update before committing, since if the build is broken they won't be able to validate their changes, and will have to put off committing.  If your build process takes too long (more than 10 minutes including unit tests) then updating and building before committing will be painful, and people won't do it.  Of couse, sometimes it's simple laziness, but that just needs to be beaten out of people. :)  The other things are fixable with technology, which is easier than getting people to do the right thing most of the time.

To make the process easier for everyone, don't commit any changes after the build breaks unless those changes are directly related to fixing the build.  If they aren't, then those additional commits will also cause failing builds, but now the waters have been muddied and it is harder to track down which changes are causing failures.  If the build breaks, then work on fixing it rather than committing unrelated changes that make it harder to fix the real problem. 

Monday, December 03, 2007 9:52:43 PM (Pacific Standard Time, UTC-08:00)
To make the process easier for everyone, don't commit any changes after the build breaks unless those changes are directly related to fixing the build. If they aren't, then those additional commits will also cause failing builds, but now the waters have been muddied and it is harder to track down which changes are causing failures. If the build breaks, then work on fixing it rather than committing unrelated changes that make it harder to fix the real problem.


Man, you ain't kidding there. I had a situation once where a guy had broken the build by committing a bunch of files he'd been "experimenting" with (on the trunk instead of in a separate branch) but he also committed some real actual valid work at that same time, too. Rather then roll the whole thing back, he wanted to preserve the valid work he'd committed, so he spent the better part of a day making changes to individual files, while the build stood broken the whole time (against advice that this was the wrong way to do it).

I finally put my foot down and pulled out the "I'm the lead and you're not" card and made him rollback to the last known good revision. That wasn't very pleasant for anybody.
Comments are closed.