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 below 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 below does not reflect certain environments (e.g. Sandbox and pre-Production) which exist in more mature operations.

Figure 1: Overview of Release Management 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 below 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 below does not reflect certain environments (e.g. Sandbox and pre-Production) which exist in more mature operations.

Figure 1: Overview of Release Management
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 below 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 below does not reflect certain environments (e.g. Sandbox and pre-Production) which exist in more mature operations.

Figure 1: Overview of Release Management
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 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 below shows a standard Patch Management deployment lifecycle, which contains many tasks found in a formal Release Management operation.

Figure 2: Patch Management Cycle

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’s 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 below 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.

Figure 3: SDLC Management Lifecycle

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 at right 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.

Figure 4: Quality Assurance Activities

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 below 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.

Figure 5: Overview of a sample Release Management program

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.

The Tool Gap

Release Management is surprisingly one of the areas with the least amount of process based tool support, however not for lack of wanting. Typically organizations mature into a Release Management process and it is really at the heart of any good development and support organization.

Release Management assists in eliminating the “toss it over the fence” mentality often found in today’s IT organizations. In fact, it focuses on the creation of dependencies and accountability in both these organizations. Part of the strategy used during implementation of Release Management should consider the Software Development life cycle and which phase to become involved.

Also to be considered is what facets of Release Management should be applied to non-production environments. It would take another separate article to discuss the sheer magnitude of the Release Management tool gap, particularly with regard to lack of integration with the CMDB, the lack of inclusion of infrastructure testing concerns, and the lack of interface with Change Management.
Sources for Success

One of the key paths to success in Release Management is being able to identify what “causes” a Release also known as its original source. Know this enables you to make some critical decisions.

Table 1 below depicts the various roles that typically generate the need for a Release. If you find that releases are being “sourced” from many different areas and not through a common process, it is best to start by resolving this issue. In many organizations this is called Demand Management and is commonly referred to as Program/Project management.

Looking at the table there are several places a release can originate from. Each of these areas will have different wants and needs for your Release Management process. Use the table below to speak with each of the functional areas within your company about release management. Ensure that there idea of Release management is congruent with the process design you have formulated.

Often it is helpful to bind release management to an existing project management process. This enables the business to see what is “inside” of each release. Those choosing this path should be cautioned not be to concerned with having a Release for each project. Rather, begin by focusing on the features and functionality to be delivered.

Table 1: Release Sources

Conclusion

As illustrated in the preceding paragraphs Release Management is not a turnkey process; it relies upon and feeds other processes. Though some organizations spend significant efforts building a Release Management process from scratch, others find more success in leveraging what tasks and abilities they already have and merely redirecting and formalizing them.

In getting your arms around Release Management, start with identifying your goals and ranking their priority. An example might be:

1. A High quality Releases
2. Repeatable process for deploying Releases
3. Quick and accurate Release builds
4. Cost-effective Releases

The goals above are not much different than those you may give to a construction contractor for a construction project. Keep the rule of 2 in mind “You have three attributes to choose from for your project Quick, Cheap and Quality.” You can choose any two in regards to Release Management, choosing all three will not yield good results.

Embarking on a Release Management project is not for the faint of heart. Failing to find a dependable project sponsor will be your ticket to defeat. If you find that you do not have any Subject Matter Experts (SME) in the field of Release Management this is not the time to go it alone. Anyone with an ITIL background helping with Release issues should also be able to demonstrate previous experience with the Software Development Life Cycle, QA disciplines, or Software Configuration.

Some final tips:

Mike Drapeau is president of the Drapeau Group, an ITIL consultancy based in Atlanta.