After the lab is set up, you should post these rules on the build intranet page and in the lab:
The lab must be secured and locked 24x7, 365 days a year.
Developers are not allowed to fix build breaks on the build machines. For example, if a developer breaks the build, he must fix it on his development machine and check it in. Then the build team picks it up and rebuilds.
Members of the build team are the only ones allowed to make hardware or software changes to the machines in the build lab.
No hardware is allowed to enter or leave the build lab without a build team member's okay.
Whiners will be removed from the premises immediately.
Microsoft Sidenote: Hardware Layout
In the old NT days, we had all the build, source, and release servers in the build lab. There was an extra administrative cost for these machines to the build team, which we ultimately passed on to a dedicated lab hardware team. In Figure 4.2, you can see how we had the machines configured in the lab. In one section of the lab, separated by a wall, we kept all the hardware we used, including the backup power generator for the lab in case of a power failure. There was an extra layer of security to get into this room. Few people needed physical access to our mission critical machines.
Figure 4.2. Lab setup.
In the main area of the lab, we kept the console boxes that connected through the remote desktop to the machines in the secured hardware area. This area tended to look like NASA's control center in Houston with all the monitors and people at the consoles.
The last section was also walled off and secure because it contained the CD burn machines and all the build machines used to generate hotfixes and service packs. Today, a whole department is dedicated to service packs and hotfixes. The main build lab does not get as involved as it did when NT first shipped.
