Code Leader: Using People, Tools, and Processes to Build Successful Software

3.2. Build Servers

The first step toward Continuous Integration is getting a build server set up. There must be an automated way to build and test your code, and a machine dedicated to making that happen. Furthermore, that build server needs to be set up as closely as possible to resemble your production system, to lend the maximum validity to your automated tests.

There are a lot of compelling reasons for using a dedicated build server. Builds need to happen on a predictable schedule, and they need to run as fast as possible to provide the best level of feedback. Unit tests need to run in the same environment every time for the most reliable results. Executable code delivered to testers needs to be built in the same environment every time to provide the best test results. All of these issues argue for not only a dedicated build server, but also a good one. Many organizations will trivialize the role of their build servers and use virtualized servers, or low-quality, older hardware, to host their build servers. This is a mistake. The faster and more reliably the build happens, the less time people will spend waiting for it or fixing it, and developer time is always more expensive than hardware. A build that takes 10 minutes on a local developer's machine may take 20–30 minutes if run on a virtual server or downlevel hardware. In his seminal paper on Continuous Integration, Martin Fowler suggests that a build that can be kept to less than 10 minutes will yield the best results ...