Software Release Management

Who Says It's Finished?

It is the consumer who will decide whether a software product is satisfactory. Obviously, a responsible software production effort must do everything possible to deliver a good product to the customer. Furthermore, a stream of future deliveries to the customer must be accomodated, so the product that's being delivered today must be reproducible tomorrow. The phrase "Software Release Management" refers to the delivery of of a product that is reproducible and that has a known and acceptable quality level.

Hand-off to an Isolated "Build" Environment

The preparation of product for testing and eventual delivery is called a "build." The build must be reproducible. Developers are not allowed to take part in the build; instead, they are expected to provide instructions and parts, which someone else then assembles. This is the "hand-off," it occurs between two otherwise isolated systems. The instructions and parts are immutably and permanently saved.

On the other side of the hand-off there is a "build-meister." The build-meister should demand that the instructions be simple and that the build be smooth and easy. If special conditions are required for the build, for example if third party software is required, these conditions must be clearly stated in the instructions. A product that gets built on an isolated system from immutably stored parts using simple and complete instructions meets the criterion of being "reproducible."

Use Software to Manage Software

When the "instructions" are complex, as is the case for programs written in the "C++" language, the build process is automated through a "make" facility. The developers maintain a "make" facility for themselves, anyway, so the "makefile" just is part of the hand-off that is put into immutable storage.

The "parts" from which a build is made are "source code" files. In a large and dynamic develoment environment, the source code is constantly changing, and often it is accessed by multiple people. Furthermore, the code that is initially handed-off might not be the code that actually goes into the delivery, since "quality assurance" might find a defect that needs to be fixed. The cascade of updates rapidly gets too complex for humans to manage reliably, so a facility for "source code control" is a necessity.

Jumping Through Hoops

The "build-meister' does a hand-off to the "quality assurance" people. The quality assurance process looks for defects, which might be: a functionality that was promissed but not delivered, problems with the way a new feature was implemented, or a new error where there didn't used to be one. A newly delivered feature is tested to see that: it meets specifications, it is user friendly (if applicable,) and that it has no bugs. The observations by the "QA" team are usually recorded in a "defect-tracking" system.

The observations by "QA" come under review. Usually some defects will be found, but they might be minor. A decision is made whether to deliver as is, or to require a cycle of fixing. The reviewers making this decision will include management, and might also include: developers, "QA" people, and perhaps even sales people. If the decision calls for fixes, then the developers make the update and then the whole process starts again: there is a hand-off to the build-meister, etc.

Stamp It and Ship It

When the decision from reviewers is that the product should be delivered, it is the product that was tested that gets delivered. In other words, the build-meister does his job before QA, and does no further builds afterwords. All that remains is for the "version" identifier to be associated with the delivery and with the matching immutably archived parts. (In many cases, the anticipated version number of the build is known to the developers before they submit the code to the archive, and the software is adjusted so that the software can report its own version number. This can be a life-saver later on, when doing technical suppport.)

(Optionally) A Bigger Picture

In some formal systems, release management is considered to be more integrated with the entire software development cycle. Since "QA" is checking for the implementation of new features, it might make sense to start writing the QA test plan in cooperation with those who are designing the features, very early in the software development cycle. Release management might also be interesting to client facing persons, since share accountablity for the product. The sales people are interested in features, the install people would be interested in configuration, and the help-desk would be interested in usability, documentation, and robustness.

Configuration Management

After the Release comes the Install

Following the release, the product must be distributed. Some companies develop software for their own "in-house" use; others develop actual software products that are sold to outside customers. (Web apps fall into the former category, since they are installed onto servers controlled by the company.) In either case, there is a need for the product to be distributed; which usually means "installed." Once installed, it must be "verified" to assure that it is working properly in the new environment.

The "Flow" of Release Management

Release management flows through the following steps:

• Hand-off from developers to build-meister.
• Build, in an isolated environment.
• "QA" testing.
• Review, and acceptance decision.
• Version stamping.
• Consumer facing "install" and "verify."