One important (yes, yes important) aspect of continuous integration (CI) is the way broken builds are reported. I'll tell you why but before that let's quickly recap on CI in general.
The point is to get an automated build process that run's after every check-in and takes the system for a quick spin to verify all the major parts are still OK. CI helps maintain the quality of the overall code by ensuring that components don't drift too much apart and that the current version is still valid to a reasonable degree.

Martin Fowler's article on CI (referenced above) lists the following practices

• Maintain a Single Source Repository.
• Automate the Build
• Make Your Build Self-Testing
• Everyone Commits Every Day
• Every Commit Should Build the Mainline on an Integration Machine
• Keep the Build Fast
• Test in a Clone of the Production Environment
• Make it Easy for Anyone to Get the Latest Executable
• Everyone can see what's happening
• Automate Deployment

What I am saying that a practice missing from this list is to maintain a clear concise broken build report. You see, whether we like it or not builds break. Not every checking (well hopefully anyway:) and not every day but that isn't a scarce sight either.
In our setup we get an email every time the build breaks. That's a good thing - since it increases the visibility of the problem. The message tells us who broke the build and what's the error (something doesn't compile, unit test broken or smoke test broken) and which file.

The problem is that is (was) that up until recently these details were unreliable for instance

• The error message was so long nobody bothered to read where the problem is
• Once a build was broken every new checkin also got the broken build notice - this time pointing the new person (doing the checking ) as the problem's source (even though the previous person was to blame"
• etc.

The problem here is that unreliable reports quickly turn into white noise nobody pays attention to (someone at the team said it was like the boy who cried wolf -by the time it is really "your" problem you are no longer listening. When nobody pays attention, problems get to age - in the long run this can also invalidate the whole CI approach - somewhat like the broken windows theory. So for no broken builds the team has to pay attention to what's wrong. The way to do that is to invest in the build script to make it more easy to understand  and as reliable as possible  - this is something we did (and still working on). I know I don't want to take the risk of broken build white noise...

Powered by ScribeFire.