This month's topic, Build and Deployment Management, fits in with several of the previous topics (specifically Minimizing the Requirements GIGO Factor, CM Tool Chains & Their Management and Release Management) to cover most of the CM Life Cycle stages. Once again, let's define some terms:

Build - The process of converting some precursor artifacts (source) into some desired output (testable component or product). Classically, this is thought of as "compiling," but it also includes such esoteric things as linking, packaging (think .jar, .cab and .tar files). A "build" is the end result of this process. Think of building as starting from base ingredients and ending up with a pie.

Build Management - The control of the "source of the source," the build environment and the build tool-chain. This includes the access security (i.e. only CM can change anything within the build environment) as well as tool-chain component maintenance. The person who "manages" the build environment and controls execution of builds is called a Build Manager, even though they rarely have any management responsibilities. While in larger organizations there may well be a Manager of the Build Team, this is not what is meant by the term Build Manager. Think of Build Management as being in control of the kitchen, the equipment within it and the available ingredients, as well as cooking pies. In this analogy, a Build Manager is the head chef.

Release - A release is the consolidation of all deliverable elements, whether resulting from a build, generated in-situ or as acquired from third parties, into a controlled staging area. It is generally organized into the same package(s) as will be deployed to customers or end users. One can think of a release as a shrink-wrapped package full of "good stuff." Continuing the analogy, a release is a pie in a box with the appropriate labels affixed.

Release Management - The control of the selection of release components, the release environment and the tool-chain required to produce a release. Note that the description is very similar to that of Build Management. That is because these two activities are closely related. The only difference is what each considers "source." Release Management is analogous to a production line where many pies are produced, boxed, labeled and placed in a storage facility awaiting purchase or shipment.

Deploy - The process of taking a release package and distributing it to one or more environments. These environments may be a download area for customers to pull from, an environment intended to be used for testing or an actual production environment within an organization. This is analogous to getting a boxed pie from "stock" and handing it to a customer.

Deployment Management - The performance of the actual deployment as well as the control of the associated tool-chain and any staging (production download) areas. There are two ways to look at this:

1. As a form of Production Control. This is NOT normally part of the CM scope of control, though I have seen it assigned to CM in small organizations.
2. As a method of getting a release candidate into a test environment (or an actual release into a support environment). Hopefully, the same mechanism is used for this as the production deployment above would use.

The scale and scope of what is involved in this activity varies widely. To use our analogy one last time, in a small scale bakery it may possible to just take the boxed pie from a cooler and hand it to the customer, but in the case of a major pie manufacturer it may involve control of warehouses, the distribution of cases of boxed pies to them, distribution to the actual retail and/or wholesale locations and potentially the actual transfer of individual boxed pies to customers.

The figure below shows the relationship between these three "Management" activities and the rest of the activities involved in the Software Development Life Cycle.

Note that in the figure above, Deployment is used in the Production Control sense. More on that later. For now, let us take a closer look at Build Management. The sample build process shown in the following figure reflects how Build Management is more than simply transforming code into executables. What is not explicitly shown in the figure are examples of specific release/patch levels of the various tools contained in the tool chain and the host/target operating systems.

The idea is that all of the components shown are in CM-controlled space. No external agency (human or otherwise) can change any element up to and including generated reports. This provides for traceability, auditablity and security. The various storage subsystems shown in the figure are explained below.

• Control Data is that data that is maintained within the Build Automation system itself and includes such things as tool options, non-source dependency information and procedural steps.
• The Source Repository is where the classical CIs (Controlled Items) reside, including any external scripts used by Build Automation, any of the Build Tools or the Linkers/Packagers.
• Reports and Logs are generated documentation resulting from the build process that are NOT intended for distribution. They may be thought of as a special subset of the Intermediate Build Artifacts.
• Intermediate Build Artifacts are generated elements that are non-deliverables that are maintained only to reduce iterative build times. No Intermediate Build Artifact is intended to ever be released and, in fact, should not even be visible outside of CM (this is why the reports and logs are separated into a different storage area).
• Deployable Build Artifacts are the components generated or selected by the build process for inclusion in releases.

It is obvious from the figure that someone who assumes the role of Build Manager needs to have a broad knowledge. They may not need to be able to program in a language, but they need to understand the language well enough to be able construct viable build scripts and to be able to tell when things are not right. Developers generally need to know one IDE and one language per project. The builds performed by Development are generally of a "click here to build" nature and do not produce a controlled set of artifacts. The Build Manager needs to know all of the tools, the physical architecture of the source, the physical architecture of the deliverables, etc. just to be able to do the job effectively.

As was discussed in a previous article, Release Management normally takes over from Build Management by using the Deployable Build Artifacts as a source that it does its own transformation on to produce packaged deliverables ready for distribution. This relationship is illustrated in the following figure.

So how does Deployment Management come into the picture? As was mentioned earlier, there are two different "primary" meanings for this term. The first is in the sense of Production Control. It takes the results of Release Management, via the Stage for Deploy controlled storage, and actually generates items that a customer can acquire. It can take the form of anything from ISO CD/DVD images the customer may download to actual shrink-wrapped packages delivered via some physical means. CM is normally not involved in this type of Deployment Management unless they are extremely unlucky.

The second meaning of Deployment Management is normally performed as a part of the build process. It either pushes the deployable artifacts to a test environment or stages them in some way that they are available for download/installation by the test team. In the best of worlds, this would mirror the way the customer would acquire the product, install it, etc. In more simplistic projects, it simply makes the results of a build available to both developers and testers. This is illustrated in the following figure. Keep in mind when looking at the figure that it is entirely possible (and reasonable) for the build process to deploy the build artifacts directly to the test environment without resorting to the use of the Deployable Build Artifacts storage. This is the "push" method many choose to use, especially for automated regression testing. The "pull" method is where testing requests the artifacts from the Deployable Build Artifacts storage from the appropriate Test Environment.

Summary
Over the course of this year, we have explored the majority of the CM activities contained within the majority of the Software Development Life Cycle models. This month, I have concentrated on Build Management and described how Deployment has come to mean many things. Is this the end of the story? No. There will continue to be developments in the way software is developed and delivered to end users. As this evolution continues, so too will the need for CM to adapt. CM has historically been a core concept and has developed technology that mirrors this mindset. With the advent of Automated Life Cycle Management/Automation tools, this is a trend that is here to stay - at least for the foreseeable future.

The good news is that this means there will be a need for more CM'ers. The bad news is that there will be swing of the pendulum in the direction of Management buying tools instead of expertise in the mistaken belief that automation tools make CM'ers obsolete. This trend is visible in the job titles being advertised for: "Wanted - Build Manager with experience in ..." This is fine if there is already someone present who understands the rest of CM theory and practice, but not if this will be the only CM'er on-staff.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment