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 likley to stick around and see how things turn out. The ideal is one integration build per atomic checkin since then it is easy to dtermine which checkin caused the problem and who is responsible. This is challenging since determing just what constitutes an atomic checkin can be difficult to do in an automated way. Several distinct commits may be interelated. 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, everytime 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 ned to be resolved if checkins conflict.