Release Management is the relatively new but rapidly growing discipline within software engineering of managing software releases.
As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex. Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release. Add to this an evolution and growing complexity of the platforms on which these systems run, and it becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and long-term value of a product or project.
The need therefore exists for dedicated resources to oversee the integration and flow of development, testing, deployment, and support of these systems. Although project managers have done this in the past, they generally are more concerned with high-level, "grand design" aspects of a project or application, and so often do not have time to oversee some of the more technical or day-to-day aspects. Release Managers (aka "RMs") address this need. They must have a general knowledge of every aspect of the Software Development Lifecycle (SDLC), various applicable operating systems and software application or platforms, as well as various business functions and perspectives.
A Release Manager is:
Facilitator – serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates.
Gatekeeper – “holds the keys” to production systems/applications and takes responsibility for their implementations.
Server Application Support Engineer – help troubleshoot problems with an application (although not typically at a code level).
Coordinator – utilized to coordinate disparate source trees, projects, teams and components.
Some of the challenges facing a Software Release Manager include the management of:
c. Software Change Requests
d. New Development Requests (additional features and functions)
e. Deployment and Packaging
f. New Development Tasks
g. Organizational Politics
Where should you start with Release Management?
In its full expression, Release Management can be a complex topic, so any attempt to cover it in a single entry would be a mistake. This outline 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 outline 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 outline 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.
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.
2. Software Development Lifecyle (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.
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.
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. Often, 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.