Release and Deployment Management

Often forgotten or ignored in many IT Service Management implementations or initiatives, Release and Deployment can be mistakenly seen as the poor cousin of Change Management, being of less importance and priority to both the business and IT organizations.

Much of the confusion and misunderstanding is perpetuated by the idea that Release and Deployment only focuses on the actual distribution of changes to the live environment.

While timely and accurate distribution is indeed a goal of the process, the actual scope includes all of the activities, systems and functions required to build, test and deploy a release into product and enable effective handover to service operations.

In conjunction with the use of Change Management, Release and Deployment will enhance an organization‟s capabilities to develop, compile, reuse, distribute and rollback releases in accordance with defined policies that improve efficiency and reduce business disruption.

8.6.1 Goals and Objectives

To deploy new releases into production, transition support to service operation, and enable its effective use in order to deliver value to the customer.

Other objectives of Release and Deployment are:

 To define and agree upon Release policies, and Release and Deployment plans with customers and stakeholders;

 Ensure the integrity of constructed release packages and that they are recorded accurately in the Configuration Management System (CMS);

 Ensure that all release packages can be tracked, installed, verified, uninstalled or backed out if necessary;

 Ensure the required skills and knowledge is transferred to support staff, customers, end-users, suppliers and any other relevant stakeholders; and

 There is minimal unpredicted impact on the production services, customers and service operations.

8.6.2 Scope

Release and Deployment works closely in conjunction with the other Service Transition processes to enable the quality transition of services. The role played specifically by Release and Deployment is to build, package, validate and distribute authorized service changes to the target systems or users. A release is a collection of authorized changes to an IT service.

8.6.3 Benefits

When identifying the benefits that Release and Deployment provides for, it is important to remember that it should be utilized in conjunction with the other Service Transition

processes. As a result, improvements in the metrics defined for Release and Deployment may be at the expense of the other transition processes. Typical benefits seen as a result of improved Release and Deployment are:

 Delivering change, faster, at optimum cost and minimized risk;

 Assuring customers and users can use the new or changed service in a way that supports the business goals;

 Improving consistency in implementation approach across the business change, service teams, suppliers and customers; and

 Contributing to meeting auditable requirements for traceability through Service Transition.

Well planned and implemented release and deployment will make a significant difference to an organization's service costs. A poorly designed release and deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environment and degrade the live services.

8.6.4 Terminology

Release Unit:

A „release unit‟ describes the portion of a service or IT infrastructure that is normally released together according to the organization‟s release policy. When defining the most appropriate release unit structure, the following factors should be taken into account:

 The ease and amount of change necessary to release and deploy the release unit;

 The amount of resources needed to build, test and distribute a release unit;

 The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure; and

 The storage and resources available in the build, test, distribution and live environments.

Based on these factors, it may mean that for critical applications the release unit is the complete set of application components and for optional features or add-ons only the single component itself.

Figure 8.8: Simplified example of release units for an IT service

© Crown Copyright 2007 Reproduced under license from OGC

Release Package:

A release package may be a single release unit or a structured set of release units,

including the associated user or support documentation that is required. Like the definition of release units, factors such as the modularity of components, the amount of change occurring and resources required will be considered when formulating a complete Release Package.

Release Identification:

The unique release identification scheme which is normally defined in the Release Policy and conforms to any standards defined by Service Asset and Configuration Management.

Typical identification schemes include the following examples:

 Major Release: Banking_System v1, v2, v3 etc.

o Major roll-out of new hardware and/or software.

 Minor Release: Banking_System v1.1, v1.2, v1.3 etc.

o A few minor improvements and fixes to Known Errors.

 Emergency Fix: Banking_System v1.1.1, v1.1.2 etc.

o A temporary or permanent Quick Fix for a Problem or Known Error.

Definitive Media Library (DML):

The secure library where the definitive authorized versions of all media CIs (typically

software) are stored and protected. The DML should include definitive copies of purchased software (along with license documents and any controlled information) as well as

software developed on site.

The DML includes both electronic and physical copies of definitive software releases, with Release and Deployment being responsible for any additions, modifications, removals or maintenance that needs to be performed.

Figure 8.9: The use of the DML by Release and Deployment

© Crown Copyright 2007 Reproduced under license from OGC

Definitive Spares:

Physical storage of all spare IT components and assemblies maintained at the same level as within the live environment. New IT assemblies are stored here until ready for use, and additional components can be used when needed for additional systems or in the recovery from Incidents. Like the DML, details of these assemblies are recorded in the CMDB, and