Regularly Scheduled Builds

Integrate Early. Integrate Often. The closer to a checkin (commit) an integration build is run the more quickly you will get a turn around for any build (or test if the integration build includes tests) problems that occur and the easier it will be to identify the source of the problem.

If the developer knows a build will be run within a reasonable amount of time after the checkin (say up to an hour) they are far more likely to stick around and see how things turn out.

The ideal is one integration build per atomic checkin since then it is easy to determine which checkin caused the problem and who is responsible. This is challenging since determining just what constitutes an atomic checkin can be difficult to do in an automated way, and several distinct commits may be interrelated.

Several solutions are possible:

• Train schedule integration builds, one leaves every hour be on it. The problem with these is if a checkin or series of checkins spans the build launch time you can get false failures.
• Continuous builds, every time one build finishes the next one starts, similar problem to the train schedule
• Developer controlled builds, give them a button to hit when their checkin(s) are complete, or give them a button to hold off the train leaving the station until they are done. Multi-user conflicts need to be resolved if checkins conflict.