Probably no other ITIL process has experienced as large a metamorphosis in ITIL V3 as Release Management. Like a caterpillar that goes through a chrysalis stage to appear later as a butterfly, Release has gone through a similar transformation.
However, when you study a butterfly closely, you often see reminders of its original life as a caterpillar. So, too, are the original underpinnings of Release Management still visible.
Many IT Service Management (ITSM) practitioners will recall that V2’s Release Management process is somewhat of a newcomer to ITSM. In ITIL V1, it was known as Software Control and Distribution, and the process focused exclusively on releasing new software into the live environment.
Many of the principles of software distribution, such as a controlled process for acquiring, distributing, and implementing a new release applied equally well to hardware. ITIL V2 brought hardware into the mix, and changed the name of the process to Release Management.
However, in my opinion, Release Management never really lived up to its promise as an all-encompassing process that could manage and control both software and hardware releases. In essence, its only real nod to hardware was the creation of the Definitive Hardware Store (DHS) and the mention that hardware release procedures follow a similar track as software release procedures.
In the years since ITIL V2 was published, an interesting thing happened in the real world – having a good Release Management process became very important. Release was no longer the stepchild within the Service Support processes of Incident Management, Problem Management, Configuration Management, Change Management and the Service Desk Function.
Organizations began scrutinizing their own Release Management processes as they sought to tighten them up and formalize them. Why, then, would Release Management disappear from ITIL V3?
The answer is that Release Management has not disappeared. In fact, it has become greater than the sum of its parts!
Essentially ITIL V3 parcels out V2’s Release Management activities into two major standalone processes and into components of several other processes.
Probably ITIL V3’s most significant change is the establishment of two separate processes, Transition Planning and Support and Release and Deployment within the Service Transition book.
This step clearly separates Release’s policy-planning activities from its execution activities.
ITIL V2 embodied Release policies within its general “Concepts” section, but gave little guidance on how to actually develop and plan these policies within an organization. V3’s Transition Planning and Support Management goes much farther, and discusses in detail how to establish policies that will guide the organization in planning and coordinating the resources to move a new or changed service into production within the predicted cost, quality and time estimates.
In this section, you will find the familiar identification and numbering and naming conventions for different releases, including Major, Minor and Emergency Releases. It also addresses setting policies for release frequency, release packaging, re-usable build and installation procedures, and release acceptance criteria.
Release and Deployment Management describes the process for building and installing individual releases. This repairs a serious deficiency in ITIL V2, which never clearly differentiated between the one-time planning of Release policies and the on-going Planning for releases into the live environment. It also recognizes the improvements that have been made in release tools since V2’s publication date.
This section assumes the major Release policies have been set and that a release will work within them to determine how best to configure a particular release. In this section, you will find guidance on “big bang” versus phased releases, “push” versus “pull” releases, automation versus manual, and designing release packages.
Two other Service Transition processes include components of Release Management – Service Validation and Testing Management and Knowledge Management.
Service Validation and Testing Management addresses a structured validation and testing process to provide objective evidence that the new or changed service will support the customer’s business and stakeholder requirements. It describes test models that may be employed for each test cycle within Service Transition, including Deployment Release, Deployment Installation, and Deployment Verification. It also notes that the type and frequency of releases drive the requirements for test modeling and tools.
Knowledge Management is the organization’s ability to deliver the right information to the appropriate place or competent person at the right time to enable informed decisions. Although the release activity is not responsible for Knowledge Management, it is responsible for ensuring: 1) the customer or user understands how to use the new service; 2) the Service Desk and support staff understand the business and technical aspects of the new service; and 3) the transition staff understands the components of transitioning to the new service.
Release Management has not gone away. In its new guise as Transition Planning and Support Management and Release and Deployment Management, it is now more comprehensive and offers more guidance than ever before. Its structure is greatly improved by separating the planning portion of the process from its execution, and the other Service Transition processes now contain better and more frequent interfaces and relationship to the release processes.