ABCs of BPD (Build, Package and Deploy)

While most CM’ers know there is much more to CM than build, package, and deploy, there is significant focus and visibility in this CM area by the project team. In addition, the build, package, and deploy process typically uses other CM processes such as problem management and change control. This is why build, package, and deploy processes are considered so important to a development lifecycle.

Overview

This article hopes to provide you with the building blocks for creating solid build, package, and deploy processes. The next several sections walk through a description of each process area with a step-by-step process flow, which can be customized as appropriate.

The context of this topic is in terms build, package, and deploy. Build is defined as the ability to identify the components to be built and compile/generate runtime deliverables. Package is defined as the ability to identify the pieces to configure into a working system and validate its readiness. Deploy is defined as the ability to take a validated release package, approve it, and deploy it into production.

However, these processes can be combined together and/or exist under different names. Some people call it the release process, the build and release process, the build and migration process, amongst other names. The importance is not the name of the process, but the name with a corresponding description so everyone is clear on what needs to be accomplished

Build

Build is further defined as identifying a set of source items and through some means of compilation or generation (via a compiler, IDE, etc.), produces a set of executables and other files which can be used to perform a runtime function. When considering a build process, start with identifying the build types that exist (in general, there are four types).

Build Types

Private builds – A Private build is described as an individual developer working in isolation (private workspace) who builds their code separate from others. The Private build is typically against a baseline (or configuration) of code that changes regularly. Synchronizing recent changes (if this is appropriate) into the private workspace point in time the developer is testing against.

Integration build – An Integration build is described as individual code changes promoted into an integrated workspace and built together. If the result is a build with no errors that passes some (or all) level(s) of testing and meets the some (or all) level of requirements, the Integration build can be known as a test build or a release build. This is typically an evolutionary process.

Integration builds may be continuous (e.g., nightly, weekly, etc.) since this may reduce the effort of merging individual code changes and uncovering build issues sooner. The project or development manager should track the changes going into a build (particularly as the release date approaches).

Test build (sometimes known as QA builds) – A Test build is described as an Integration build with the goal of handing off the deliverables to the Test team to validate the functionality against stated requirements (which we hope are documented!). Validation may include regression tests, performance tests, and eventually user acceptance tests (which may be done by customers of the product).

Release build – A Release build is described as an Integration build with the goal of being released into ‘production’. It should have met the test criteria so it is now release ready and can be shipped to the customer. Effectively, a Release build always starts as an Integration build and follows the same build process. The Integration build will meet a milestone level of completeness (test build) and then the full requirements (release