It's More than Just Application Code Bundling and Testing

The current ITIL implementation landscape is populated with Incident, Change and Configuration process improvement projects. However, mention Release Management (RM) to an IT Manager in the Infrastructure group shop and you will likely receive a few blank stares. In fact, many IT careers have been preserved by defending the idea that RM cannot be mastered by a single IT manager and, in any case, the requirements of software development and infrastructure are so distinct that they merit different treatment. This ‘separatism' is the single greatest factor hampering RM implementations and it is a profoundly mistaken notion.

Articles touching on the many benefits of Release Management occasionally appear, but their focus is almost exclusively on the technique of bundling application modifications together and almost never on the complete scope of the ITIL process, which goes well beyond the confines of software development and the deployment of code from QA to pre-Production environments.

In its full expression, Release Management can be a complex topic, so any attempt to cover it in a single article would be a mistake. This article will provide a "lay of the land" in terms of common day practices and some insight on what makes a good ITIL based Release Management process function effectively. In writing this article the author assumes the reader has a basic understanding of the related IT Service Support process Configuration, Change, Incident, and Problem Management. The remainder of this article will fill in the details about the usage and adoption of Release Management for enterprise organizations.

Basic Flow of Release Management
Figure 1 (click for image) outlines the basic steps that constitute a "Release Management" process. In this diagram the movement of a Release from left to right depicts progress through various environments (Development, QA and Production), each of which is a distinctive operating environment that progressively seeks to replicate Production conditions and functions separately from the other although they leverage common methods for promoting a Release between them. It is important to note that Figure 1 right does not reflect certain environments (e.g. Sandbox and pre-Production) which exist in more mature operations.

Release Management is already in your organization—"Just Look for it"
Many read the full-fledged description of RM in a book on ITIL and become convinced that it is too esoteric and advanced a concept for them. Such is not the case, though, because most IT organizations already boast many RM-related activities; they are simply located in other groups and other names. One of the first tasks, especially when conducting a process Maturity Assessment, is to look at the following six (6) areas, which can overlap with each other but which also contain many aspects of RM, although in varying degrees:

1. Patch Management. Many IT shops, especially those with extensive Microsoft platform deployments have developed elaborate processes for Patch Management to the Production environment. Their scope usually includes operating systems software, database upgrade, and even firmware upgrades to hardware components (e.g. storage arrays and network switches). Figure 2 shows a standard Patch Management deployment lifecycle, which contains many tasks found in a formal Release Management operation.
2. Software Development Lifecycle (SDLC). SDLC describes the complete set of processes that govern development, testing, delivery, maintenance, and sun-setting of application code. Whether an organization is using a formal SDLC methodology, a framework such as Carnegie Mellon's Software Engineering Institute (SEI) Capability Maturity Model (CMM) or ITIL'srm_03_199 Applications Management, or a systematic code deployment scheme like IBM/Rational's Unified Process Framework (RUP), they likely have evolved a set of procedures to govern the movement of code from one operating environment to the next (i.e. Development to Testing to Quality Assurance to Pre-Production to Production). Figure 3 shows a generic Applications deployment lifecycle with the functional testing step capturing the final deployment (from pre-Production to Production) event, which itself contains the majority of Release Management-like activity.
3. Quality Assurance (QA). When organizations lack a formal pre-Production environment (usually due to a lack of funds necessary to maintain a physical and logical duplicate of Production), much Release Management activity can be found in the formal QA discipline. Figure 4 depicts the set of interdependent activities which are required of most QA departments—irrespective of whether hardware or software modifications are undergoing test. In these cases, a significant portion of what is known as QA work would be re-labeled as Release Management and managed accordingly.
4. Change Management. Many, if not most, ITIL implementations start with Change Management (so as to ‘stop the bleeding' in IT Operations). Over time, the process design and policies begin to take on more than just Change Control disciplines. Organizations are tempted to avoid launching ‘ITIL another process' and just amend the existing Change Management guidance to include pre-Production testing requirements prior to authorizing a Change. The results of this approach are predictably poor. Changes fail in Production, testing blurs with deployment, no risk assessment techniques are used, and nothing exists to arbitrate access to pre-Production resources. Fingers begin to point and accountability is blurred because the Change Manager is trying to accommodate the dictates of a Release within the confines of a Change Management system. Organizations with undifferentiated Change Management processes similar to this will see improvements shortly after extracting the Release-related activities.
5. Software Configuration Management (SCM). SCM refers to tools that manage application code and enable modifications to be "released" to Production. Oftentimes, these tools have been in place for long periods of time and elaborate procedures have been built up around them that resemble, quite closely, many Release Management disciplines. Some SCM tools are anticipated in an SDLC approach, but others are legacy products that pre-date adoption of an SDLC methodology. Organizations with active SCM systems and supporting databases should inventory the formal policies and informal practices which have grown up around them to better appreciate how much Release Management-like activity they contain.
6. Advanced Testing Groups. Other organizations that lack formal pre-Production environments may yet boast advanced testing facilities and have staff dedicated to the process of vetting future technology. Such groups are typically found in enterprise IT operations and their mandate can stretch far, especially if technology deployment is considered a strategic differentiator by the business. Although the purpose of these Advanced Testing groups is to look at components, systems, and sometimes applications that are not yet in Production, they usually are not formally linked to the Change Management process. Nevertheless, they tend to develop formal procedures to govern access to facilities, development of rollout and rollback plans, application of testing matrices (regression, unit, performance, exception, etc..), and training of personnel. Much of this can be re-purposed for a Release Management process implementation.

Getting to Execution

Most organizations are pleased to learn that they are already engaging in some form of Release Management activities. The next section outlines where to look for release information and what key success factors to align with for Release Management activities.

Figure 5 (click for image) outlines the sources and critical success factors that, together, lead to a well-executed Release Management program. Follow a start simple methodology by locating the sources and consumers of releases. The idea here is to go as far "up stream" as possible to find out where a Release may begin. Using this approach enables you to find where processes exist.

If you find that your organization is doing well with managing the beginning of a Release then it is best to focus on the design and build areas (often this is the where many organizations struggle). This is particularly true if IT is involved in true software development and operated on tight deadlines. The best remedy for this is the strengthening of one particular project or technology domain. Assuming a success in this one area use it the momentum to push it through the organization.