Figure 1 - Software Development Lifecycle

Build Management is responsible for using versioned source code to construct deliverables. If the Development Model in use is one where build artifacts are promoted without change throughout the rest of a development lifecycle, Build Management will stop at the beginning of the Testing phase. If the Development Model is such that different deliverables are generated for testing than for production, then Build Management extends up to the beginning of Operational Readiness Testing.

Release Management picks up where Build Management leaves off. It constructs the actual production-ready deliverable. Even though in small product development efforts, the end result may be the same as that generated by Build Management, the purpose of Release Management is to take build artifacts and combine them with other third-party components, documentation, help files, etc. and produce something that can be installed by an end user.

Just to put things in perspective, Deployment is where a release is actually deployed to one or more end users. This may be done via a download area, an online installation mechanism, the creation and shipment of physical media or any combination of the above. Site Management is responsible for knowing which end users have what release levels of the product, who the primary contact is, any license or Service Level Agreement (SLA) issues, etc.

In order to do the job effectively, each of these phases requires the use of different tools. In the case of Release Management, the tool choice ends up being the creation of something in-house, even though there are commercial tools available that can do the job. Why do a custom coding job instead of purchasing a RM tool? It often comes down to two things:

• Flexibility
• Costs, both initial and ongoing 

Let's take a quick look at some of the requirements for a RM tool by first looking at figure 2:

From the diagram, it seems we can extract several requirements:

• The Package step needs to be able to acquire input from several repositories using a variety of methods. At a minimum, it needs to be able to get Docs and Help files from Version Control, Build Artifacts from whatever mechanism the Build Management process leaves them in, and Third-Party Components (Add-Ons) from some other form of versioning tool.
• The Package step needs to be able to generate a Manifest of some kind that is used as a Release Record. This record should be produced and archived or versioned even if it is deemed to be a "bad release" and never deployed.
• The Package step needs to be able to reorganize and/or clean up intermediate artifacts and place the resulting deliverables in a known and controlled file system hierarchy.
• If a non-ISO deployment method is to be used, then the Package step needs to place the output in a controlled Staging area for subsequent deployment.
• If one or more ISO images are to be produced, then the Generate ISOs step needs to take the output from the Package step, produce one master copy of each ISO and place them in a known and controlled file system hierarchy for online access.
• If one or more ISO images are to be burned to Master Media, then the Burn ISO Masters step should either take the output from Generate ISOs directly or from the Deployment Staging area and burn them. 

There are several products that can do all of this as a part of an overall Application Lifecycle Management (ALM) or Application Lifecycle Automation (ALA) system, even though this blurs the distinction between Build Management and Release Management somewhat. It is not uncommon for the overall tool to execute other tools such as Install Anywhere, InatallJammer, IzPack or instal4j to do the Package step and tools such as Nero or K3b to generate ISOs and burn physical media. The advantages of using an ALM/ALA tool will be discussed in another article at a later date. For now, just be aware that the Release Management functionality or role can be, and often is, combined with others so far as tools go.

If only the Release Management portion is needed, it is not too difficult to create an in-house solution. As an example, what we are currently doing is taking the results of a build and packaging it using ant under the control of an ALA tool. While the ALA tool is a great advantage, it is not necessary to do the actual Release Management function. External to the ALA tool, a perl script is used to release the package internally for testing and, if it passes test, release it to an external online install manager for download by the end users. We consider both of these releases as part of the Release Management phase, not the Deployment phase.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment