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 build). In many cases, a project team may not call it the Release build until they know that it has tested correctly. This is why it is important to label the build items after a successful build especially as the team approaches the release date. Also, in some cases as the release date is approached, all builds are called Release builds in hopes that one of them will pass appropriate tests and be deemed ready for release.

Build Process
Prior to performing a build process, a build infrastructure must be in place. This typically includes validating the platform in which the build will occur, identifying and installing appropriate compiler/translator/IDE tools, and establishing a clean-room build workspace.

A typical build process includes:

·         Identify the items that need to be built (they should be in a common SCM tool repository)

·         Begin the build (execute the specific build commands)

·         Pipe all build output to a log file

·         Review the build results & address any build issues (as appropriate)

·         Optional: the build is smoke tested to validate that the core functionality runs properly

·         If the build was successful and of significance (e.g., milestone, test, release):

·         Label the versions of the source code that was used in the build

·         Note: since the build process is iterative (occurs very often), consider automating the build process as much as possible

Package

Package is more completely defined by identifying all pieces that make up a package (eventually targeted for release) and validating its readiness via test. This includes the output from the build and includes other items like scripts, database items, documents, etc., that create a package of deliverables that runs in a test or production environment.
Package Process
A typical package process includes:

·         If the build deliverables had some significance (e.g., milestone, test, release), version control the deliverables from the build.

·         Note: this may be a step at the end of the build process

·         Identify any other known items (scripts, database, configuration, documents, etc.) that will create a package of deliverables that can be run in test (then production).

·         Note: this may include version controlling some (or all) of these items preferably in the same code repository as the build deliverables.

·         Collect the items together (e.g., ‘tar’ or similar function) into a identifiable draft package (items from the above 2 steps).

·         Note: this step should be automated – it is iterative and will occur until the package is validated for release.

·         Create a draft release notes to accompany the draft package

·         Migrate the draft package into an appropriate test region for validation (functional, system, regression, performance, user acceptance).

·         Validate the draft package. This is a test step.

·         Incorporate (check-in) changes made to the draft package during testing into code repository so that the new ‘latest’ (a.k.a., release) package includes these changes.

Deploy

Deploy is further defined as preparing for the release of the validated package, having a group of stakeholders review the readiness of the deliverables, and having a process in place to install and validate the release package once it is in production. In many cases, this is known as the release process.

Deployment Process
Prior to performing a deployment process, a production infrastructure to host the release package must be in place. This may be in the form of a production system(s) or mechanism to install the release package onto media. Also, a change control process including a Change Control Board (CCB) should be in place to approve the release package into production. A typical deployment process includes:

·         Finalize the release notes

·         Submit a change request to the CCB to change the production baseline with the release package.

·         Collect supporting documents that indicate the readiness of the release (test reports, release notes, installation plan, backout and recovery plan, etc.)

·         Review and authorize the release package

·         Review the change request and all supporting documents

·         Determine disposition of release package (approve, reject, pending, etc.)

·         Address concerns

·         If approved, communicate pending release package has been tested with release dates to stakeholders and support staff.

·         Install release into production. Production may be media or production server(s) or client(s).

·         Validate release package in production.

·         If media, this should include testing the installation process from media to production server and/or client as well as testing functionality once installed.If production server or client, test functionality.

·         Communicate that release is in production to all customers, stakeholders, and support staff

Summary

When implementing CM processes, build, package, and deploy can be a good place to start. It is usually one of the more visible areas where a CM’er can show value. It is not important to debate the name of the processes involved in this part of the lifecycle. If there are names that the project teams understands which represent the building, packaging, and deploying of deliverables (a.k.a., release package) into production, consider using them. The easier recognition may improve adoption. If there is no set process, consider documenting the current process and sharing it with the team. Once a process is defined, it also becomes a good basis for suggesting improvements. Ultimately, a CM’er must show (added) value and these processes are a good place to start.

References

1. “Software Configuration Management Implementation Roadmap” by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing. Specifically the following sections:

2. Chapter 4, “6.6. Develop an SCM Build Process”

3. Chapter 4, “6.7. Develop an SCM Release Process”