Developers, Technology Evangelists, Bros.

Good Practices in Build Management

I’ve recently been working with several customers to discuss good practices of Application Lifecycle Management. One area of ALM is build management. In this post, I’ve described (at a high-level) good practices in build management.

What is Build Management?

Build Management is the practice of developing and maintaining a process for creating builds of software. Under this context, a software “build” is an orchestrated process originating with software source code under a developer’s control and resulting in a reusable and “consumable” form outside of a developer’s control (see Wikipedia). A build process can take many forms such as source code compilation, output formatting, packaging, and build artifact structuring. It is not necessary that application source code be compiled from one language to a binary form, it is intended that a build process move the original source code (which is under developer control) to a non-developer controlled environment. The artifacts of the build process should also be in a form that is both reusable and consumable by a deployment process such that the executable content of the software application not be modified in order to be run.

Builds should not be confused with other practices such as continuous integration, which describe a development team behavior of regularly integrating source code changes into a centralized “trunk” line within source control.

Good Practices in Build Management

Teams regarded as having a high level of competency in build management participate in many of the following practices:

  • Formal, well-defined, and documented build processes are understood by all development team members
  • The build process is built upon an easily-configurable platform, providing the flexibility to incorporate new technologies trends as they become available (i.e., virtualized environments, cloud platforms, alternate data store technologies, etc.)
  • The build platform provides…
  • traceability between the build output, code changes, and originating
  • build quality, test results, and completion metrics, as needed
  • the capability for scheduled, triggered, and on-demand builds
  • the capability to integrate and automate the testing of systems during the
    build process
  • integration with a tool or platform to enable automated deployment of
    software, as needed

  • The build output adheres to a meaningful binary versioning scheme, such as semantic versioning (see
  • Builds are automated, requiring no manual intervention
  • Builds are conducted on a dedicated “build” machine, not actively managed by the development team



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.