It's amazing how many articles and books I have read that recommend nightly builds. Unfortunately, they mean this literally. Whenever I talk to different software companies or Microsoft product groups that do nightly builds, I always ask, "What is the success rate of your nightly build?" Most of the time, I hear "10 to 20 percent success with zero errors." I figure the people who tell me that they have 80 to 100 percent success rates are either lying or compiling very little code every night.
I understand that the beautiful vision of a nightly build is that the build will be ready to go in the morning, all the first and second stage tests will be run, and if you have a really efficient process, the build will be deployed to the developer and tester's boxes. As a result, everyone can crank away on finding and fixing new bugs and getting the new code checked in as fast they can get out of bed and connect to the network.
Well, this is not reality when it comes to software builds. We tried the nightly builds at Microsoft in various groups. We found that you end up having some build hero up late at night or early in the morning fixing a build break or two. This is usually the only way that everyone can have their doughnut in the morning as they download the newly released nightly build. But for some reason, people keep trying it again.
Nightly builds actually promote bad behavior and carelessness for developers who check in code. What usually happens is that people get used to the fact that the build breaks almost every night. The developers count on the Central Build Team to fix the breaks in the morning, which buys them some buffer time to try and get last-minute changes in. I recommend running a build at a consistent time during the day when developers are around so that they can fix their build breaks before going home. When the product gets close to the shipping date, you should be building on the weekends, too.
As part of the daily build process, you should publish a regular build schedule. This should include the last check-in time, the time that the build will be completed, and the time that initial build verification tests (BVTs) will be completed. Here is roughly how this would look:
When any part of this process is broken, the person who checked in the defective module that broke the build should be published via build intranet page or e-mail. The build intranet page should be a collection point for all the relevant documents, policies, schedules, links, and other general information, such as new hire information. Everyone on the product team should be able to reference this site, and most will make it their default start page when they bring up IE. Years ago, we used a page similar to the one in Figure 3.1 in the Windows NT group.
Figure 3.1. Sample build intranet page.
Figure 3.2. Moses.
The warning here is that if you break the build you will have hell to pay.