A software build management server is an integral part of the Application Lifecycle Management (ALM) infrastructure. A typical ALM infrastructure consists of a version control system, a bug or an issue tracking system, and a build server. Software build processes such as Continuous Integration and daily builds are highly IO, memory and computationally intensive. Dedicating adequate resources to the build management server ensures efficient software development.
CPU speed
Build processes are usually dependent on the CPU. CPU speed for the build server should be at least equal to the speed of the fastest developmental machine. A better approach here would be to obtain the fastest CPU your budget could afford. Faster builds produce quicker feedback, thus providing greater timing and financial conservation.
Quantity of CPUs
It is essential that a build server is dedicated a multiprocessor system. Multiprocessor systems are better suited to perform multiple computationally intensive tasks that build processes are. The quantity of CPUs depends on the number of the build configurations and percentage of time each build runs. It can be estimated as the sum of the total build time percentage divided by one hundred and rounded to the next two, four, eight, 16, or 32. For example, if the build server runs eight builds and each build runs 20% of the time, the quantity of CPUs needed for the server is two.
Partitioning Build Server Load
Sometimes it is not possible to follow the recommendations in the previous section due to possible financial concerns - CMP systems with a high number of processors can be expensive. In this case the load of the build server can be distributed out evenly by moving some or all of the builds to rather inexpensive build machines running in a remote builder mode while being controlled by a central build manager. This approach allows scaling build infrastructure as the load grows while staying on budget.
Size of RAM
Selecting the adequate size of the build server's RAM is important. In case of low physical memory builds can be slow because of swapping. The minimum amount of RAM can be estimated as the sum of RAM need to run each build plus RAM needed by a version control client running full checkout plus RAM needed by the operating system and system processes. We recommend multiplying the result by 1.2 coefficients to offset unaccounted factors. Example: let OS RAM is 120Mb, each build run needs 100Mb, and each client needs 1Mb. The minimal size of RAM is going to be
(120Mb + 8*100Mb + 8*1Mb) * 1.2 = 1,113.6Mb -- or roughly 1Gb.
Disk Space
Free disk space needed on the build server depends on the number of build configurations, the number of build runs per day, and the size of build artifacts to be placed in the build archive after each build run. The estimated size of the needed free disk space in megabytes may be calculated by using this formula
Sz = (Nbuilds * 2 * Bsize) + (Nbuilds * NRuns *Asize * 3 *365)
Where Sz is minimum required disk space, Nbuilds is a quantity of build configurations, Bsize is disk space occupied by the code base, Nruns is a number of times build runs a day, Asize is disk space occupied by results placed in build archive. Example: consider a build server running 4 build configurations, each code base taking 200Mb when checked out; each build runs 10 times a day and stores 5Mb of logs and build artifacts each time; an archived items should be stored for a year. The estimated minimum disk space needed for this configuration would be
220,600Mb = 4*2*200Mb + 4*10*5Mb*3*365
Network Communications
It is important that a build server is connected to the rest of the ALM infrastructure through a high-speed local area network (LAN). The build server accesses a version control system to create local copies of the projects' code base to build and query for the latest changes. It can also access the issue tracking system to obtain release notes. Slow or congested LAN may significantly increase build roundtrip time if the size of the code base is significant (hundreds of megabytes). Ideally, the build server should be connected to the same network switch as the version control server is.
Avoiding Common Mistakes
Selecting Underpowered Hardware
Selecting a poorly performing build box causes slow builds and delays the delivery of the information about the latest state of the code base. Such delays negatively impact productivity of a software team because broken builds are not fixed quickly. To avoid this, the build server should run on adequate hardware.
Collocating Build Server with Other ALM Servers
Builds run by the build server consume a considerable amount of CPU power and disk IO. Memory consumption is also very high, especially when a build server is running many automatic builds. Collocation of the build server with a version control or an issue tracking system unavoidably causes degradation of the response times of the collocated servers as they compete for limited hardware resource. While a collocating server may provide certain financial savings (one computer is needed instead of two), these savings cannot justify losses caused by the slowness of the collocated servers. Do not mix a build server with other servers on the same hardware.
Overspending
Selecting hardware that is not going to be used is a waste of money. There is no point to have 12 CPU 36Gb RAM server to run 8 builds that combined need just 2Gb of RAM. Don't overspend. Build server's hardware should be adequate but not oversized.
Conclusion
To support efficient software development process, a software build management server requires well-performing hardware. Build server capacity planning allows selecting the hardware adequate to server's tasks while staying on budget.
Slava Imeshev is president of Viewtier Systems, Inc. http://www.viewtier.com , makers of software build management server Parabuild. Slava has been developing software for 16 years.
You can reach Slava at [email protected]
