home | products | solutions | services | resources | company | blogs

home > techcorner > What is a Build Management Server

What is a Build Management Server?

Before we dive into defining what a Build Management Server is and is not, we need to cover some background material.

What is a Build Process?

The amount of variability in implementation makes it difficult to come up with a tight definition of a Build Process. But, we would say that a Build Process takes source code and other configuration data as input and produces artifacts (sometimes called derived objects) as output. The exact number and definition of steps depends greatly on the types of inputs (Java vs C/C++ vs Perl/Python/Ruby source code) and the type of desired output (CD image, downloadable zip file or self-extracting binary, etc.). When the source code includes a compiled language then the Build process would certainly include a compilation and perhaps a linking step. As you can see, the specific steps that are part of the Build process greatly depend on the input to the Build process.

It is important to note that the identification of the inputs to the Build Process is itself part of the process. Often this part happens automatically and is implicit and is therefore hidden from view, which makes it easy to overlook. For example, when a developer runs a development build, the selection of inputs (source code and configuration) is implicit but still exists. The sources that are present on that developer's development environment are the ones that are selected as inputs to the Build Process.

What is a Controlled Build Process?

Given the above understanding of a Build Process, a Controlled Build Process is one that makes the definition of the inputs very explicit and is comprises explicitly defined steps used to produce the output (the artifacts or derived objects). A Controlled Build Process is repeatable, given the same inputs; it should produce the exact same outputs. A Controlled Build Process provides traceability from the sources to artifacts and from the artifacts back to the sources. This requires that each invocation of the Controlled Build Process be uniquely identifiable -- typically using a version number. A Controlled Build Process need not be automated, although automation certainly helps and provides some guarantees.

Two Types of Builds: Developer Builds and Authoritative Builds

There are basically two types of builds that take place on any project: developer builds and authoritative builds. Developer builds are performed by the developers in the course of development in their development environments. By their very nature these are non-controlled builds. There is no explicit definition of the inputs to the build process here. The inputs are the sources and configurations that happen to exist in the developer's environment at the time of the build. We don't actually have any way to track these inputs, we don't know the revision (in SCM) of any of the source files; in fact, some of the source files may include changes that have not been committed to the SCM.

Authoritative builds, on the other hand, are the embodiments of the Controlled Build Process. Authoritative builds take place in a clean environment where all inputs are explicitly defined. Typically an authoritative build would take the source code directly from the SCM and would use only explicitly defined environmental dependencies (which can also exist in the SCM). Explicitly defined steps are executed in a deterministic order. Typically some mechanism to provide traceability such as a version number and a SCM label are used. The version number uniquely identifies each particular authoritative build and it's artifacts (derived objects) and the SCM label provides traceability back to the inputs.

A Build Management Server Performs the Authoritative Builds

A Build Management Server (BMS) is software that is used to implement authoritative builds. It is responsible for providing a clean environment for the authoritative build, and for determining what inputs are to be used for a build and then obtaining those inputs (typically from an SCM). The BMS is also responsible for executing the steps that make up the build.

Typically, Build Management Servers provide a web based interface for configuring each project along with the inputs for each build, the steps that make up the build, and how the build results are published and communicated to all interested parties. Builds can take place either on a schedule or in response to events such as SCM commit events. More sophisticated Build Management Servers provide a dependency management service allowing the user to define and manage dependency relationships between projects.

A Build Management Server is only the start of implementing a controlled process for taking your project from source code to production. Read more about how an Application Lifecycle Server fits into this picture.