The increase in software system sizes and complexity has created a need for faster and more cost-efficient build systems to be researched. While the actual software building process is rather complex, most parts of it are usually automated by the build systems. Several modern build systems, such as HP's Domain Software Engineering Environment (DSEE) and openSUSE's Open Build Service (OBS), rely on distributing the computationally heavy build tasks to several build hosts equipped with the functionality to compile individual components and finally deliver the resulting software packages to the developers.

The problem with such build systems is that while a single build system can scale well as a singular instance, hosting multiple build systems usually requires separate sets of hardware resources in order to complete the tasks. This thesis concentrates on a specific system, Open Build Service. OBS server dispatches the build jobs to separate build hosts that compile and package the source code provided by the developer. However, these build hosts cannot be shared between OBS instances which limits the scalability of the system.

The research for this thesis led to a solution that is called the Flexible Worker Pool (FWP). The main concept of this solution was to provide separate OBS instances a service that allowed them to obtain additional build resources for the duration of their build jobs when required. This was achieved by designing and implementing a software system that functions as a dynamic proxy server between the OBS server and the dynamically allocated the build hosts. In order to allocate the resources fairly, a scheduler was also implemented within FWP. The goal was to create a virtual OBS network infrastructure that was controlled by FWP.

The final implementation of the Flexible Worker Pool turned out to be superior to the static dedication of build resources. In cases where there were no parallel build jobs on multiple OBS instances, the computational capacity was equal to the whole pool of build resources being dedicated to each of the instances individually. Even in the cases with all OBS instances being loaded with near to constant need for build resources, the FWP solution functioned more efficiently. Due to the bursty nature of the need for build resources, the advantage of sharing the resources was often significant and the solution cost-effective as the same amount of hardware could now support more OBS instances.