If I am at a company doing a build architecture review, and that company does not have a build lab, my first recommendation is to build one. If your company already has a fully dedicated build lab, you are quite a bit ahead of the companies or groups that do not have one. One of the questions that I frequently get asked by companies or groups without build labs is, "Why do we need a build lab when our corporate IT (Information Technology) group can maintain the build machines?" My answer refers back to their question, "You do not want your IT department maintaining and owning the family jewels." I do not mean any disrespect to IT groups by this. These are my reasons for the build team owning the machines:
The main purpose of a build lab is to provide the build team with more control over the hardware and software on the build machines. In addition to the build machines, it is a good idea to store the source code and release servers in the build lab. For example, if a hard drive crashes on a build server, you need physical access to the machine, and you need to change out the drive as soon as possible because you potentially have a large number of developers and testers waiting for the build to be released. Sometimes IT departments can be backed up with other priority requests or are not available to service the build machine immediately. This delay can be prevented if the build team has easy access to the machine that has crashed.
Another example is that a lot of IT departments have strict guidelines on what software is allowed on a company machine. For example, you might need to download a patch to build certain .NET classes, but your IT department might block the download for policy reasons. You might have to go through a lot of approval processes to get this patch. While you are jumping through all of the proper hoops, the development clock is ticking, and the development work is being blocked until you can get the build out. Once again, this can be avoided if the build team is allowed to keep control of its build machines.
Another important reason for a build lab is security. This is such an important point that I dedicate Chapter 9, "Build Security" to this subject. But, for now, I am just talking about physical security. Many IT departments offer security to prevent unauthorized users, but not to the extent that a custom build lab can. For example, if you want to allow only builders access to the build machines, you can restrict this using cardkey access. If the IT department owns the machines, all the IT administrators also have access to the build machines. You might have a malicious employee in the IT department do some damage without the build or product team ever having the slightest clue of this vulnerability. It might not even be a malicious person, but a new employee's mistake or another unforeseen, accidental situation that takes the machine offline.