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.
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.
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
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