The build lab should include some high-end hardware for building the applications. Because the entire team depends on the results of a build, the high-end computers ensure that the build is completed as quickly as possible. Furthermore, you can use high-speed network equipment to push bits around from source control to build machines to release servers.
At a minimum, the build lab should have four machines:
Server that contains the Source Code Control program This is your product. Do you really want this server residing someplace where you have little control over this box?
Debug build machine for the mainline builds If you don't separate your debug and release machines, you will accidentally ship debug binaries, which is not a good thing.
Release build machine for the mainline builds This is a "golden goose" that turns out the "gold eggs" of your company or group. Treasure this machine like a princess, and guard it like all the king's fortunes.
Internal release share server This is one more piece of hardware that stores the "bread and butter" of the group or company. Don't give up control of this hardware to anyone unless your IT department reports through your development group.
Each machine in the preceding list should meet the following requirements:
Number of processors This depends on the build tool you use. One is usually sufficient, because few build tools really take advantage of multiple processors.
Processor speed The lab budget dictates this, but the faster the processor, the better it is.
Amount of installed RAM Max out the machine. RAM is relatively cheap these days, especially when you consider the performance increase you get. Increasing the RAM is usually the first upgrade done when trying to improve the performance of any computer.
Number of hard drives A minimum of two drives (or partitions) is preferred:
Drive 1 (C:) is for the operating system and installed applications.
Drive 2 (D:) is for building binaries, release shares, or the source database; the minimum space required is roughly ten times the space needed to build your application.
The split partitions are good because if you ever need to format or blow away a drive due to corruption, only part of the project will be affected. The recovery is much faster and easier.
Hard drive type This is most likely SCSI, but it could be IDE.
Number of power supplies If you purchase server class hardware (pizza boxes) that belong in racks, you need to consider how many power supplies to order.
Motherboard BIOS version This does make a difference. Make sure you note what is being used and standardize on it.
Backup and Uninterruptible Power Supply (UPS)
Remember to get a good tape backup and uninterruptible power supply (UPS). Also, don't forget to back up the build machines at least once a week, but preferably every night.
Set Up the Software
After you have installed the proper hardware, you must install the proper operating system and the appropriate service packs and hotfixes. Then you can start installing the necessary applications.
Set Up the Operating System
Determine a location to install the approved operating system. For build machines, you do not need to install Windows Server. In fact, I highly recommend that you don't do this because Windows Server has a lot of networking overhead built into it that a build machine doesn't care about. Install Windows XP Professional instead. For the release and source servers, you do need Windows Server because of the amount of network traffic they get.
Install the appropriate service packs and hotfixes. You need to document what is installed on each machine.
Move pagefile.sys off of the boot partition to another partition or drive to optimize caching and O/S performance.
Set Up the Applications
Install proper Visual Studio, .NET releases, and other build tools on the build machines. The release and source servers do not need the build tools to be installed. They should be optimized to be file servers.
Install other applications such as virus scanners or firewalls. However, turn them on only on the release and source servers. As mentioned previously, if virus scanners or firewalls are turned on in the build machines, it will hamper the build time performance.
After the final setup, you can run PSINFO.EXE (available from www.sysinternals.com) on all the machines and confirm that the list it creates matches the specs of the machine.
Set Up the Build Environment for the Build Machines
Having a consistent/controlled build environment is critical for the success of a daily build. The following procedure is one way that some product groups at Microsoft keep the environment consistent. Because builders tend to live in the command shell, here are step-by-step instructions on how to set up a good environment:
Create the following directory structure on a drive that the operating system is not installed on:
On your desktop, set up a shortcut to your source control tool. You only need to do this the first time you set up the machine.
On your desktop, create a shortcut pointing to the build scripts. As with the previous step, you only need to do this the first time.
Get the build scripts from a central location owned by the build lab:
For example, if you are using VSS, navigate to $/Build/build, and copy the latest scripts to the D:\<project>\BUILD working directory.
Navigate to $/Build/scripts, and copy the latest scripts to the D:\<project>\BUILD\SCRIPTS working directory.
Set up the build environment shortcut:
For example, create a shortcut using the %windir%\System32\ cmd.exe /k D:\<project>\build\devenv.cmd command line. Name this shortcut "BUILD." (A sample of devenv.cmd is included in Chapter 7, "The Build Environment.")
In Properties, Shortcut, set Start In to D:\<project>\build.
In Properties, Options, set Buffer Size to 999, and select both QuickEdit Mode and Insert mode.
In Properties, Layout, set Screen Buffer Size Height to 9999.
In Properties, Layout, set Window Position Left to 118.
In Properties, Layout, set Window Position Top to 43.
You have now set up a project build machine. You can also use these instructions for individual workstations. Finally, when all the hardware is set up and the software is installed, put physical labels on each machine with the system name, IP address, and switch/port setting.