Release and Deployment Management

The role of release and deployment management in this lifecycle stage is to ensure the successful introduction of changes into the live environment, minimizing the unpredicted impact to the business.

To deliver releases into the live environment successfully, you need to have control over the release management activities, and in this process we cover the purpose, objectives, and scope of the process, as well as the concepts of the release policy and the four phases of release and deployment.

The Purpose of the Release and Deployment Management Process

Release and deployment management is an important part of managing your live environment. The process ensures that the build, test, and deployment of the release is delivered with minimal adverse impact to the business.

One of the key purposes of the process is to ensure that this activity is planned, scheduled, and controlled in accordance with the needs of the organization.

This is one of the most visible processes of transition, because it is where the interaction of the IT department and the business community meets to engage with the new or changed services. During release and deployment, you will carry out pilots and testing of new services in order to understand whether the service design can be realized effectively in operation.

Release and deployment management needs to deliver the new functionality required by the business, and it is important to ensure that the new or changed services do not negatively impact the existing services.

The Objectives of the Release and Deployment Management Process

The objectives of release and deployment management are to do the following:

  • Define and agree on deployment plans with the stakeholders of the release. This is an important aspect of the process, because the agreement of a schedule and management of the activity with the customers and stakeholders who will receive the release is important in setting expectations for the desired outcome.
  • Create and test release packages. Release packages may consist of a number of related configuration items, and it is the responsibility of release and deployment to verify the components are compatible and can be released together.
  • Maintain the integrity of a software release package throughout the release. All release packages should be stored as part of a definitive media library, and the records should be kept in the configuration management system relating to the release. This includes managing the constituent components of the release package and keeping accurate records about each CI. Hardware releases will be managed in the same way but without the requirement to check them into the DML.
  • Follow the agreed release plans according to the schedule, including deploying the software release from the DML. Keeping to the plans and schedule will ensure that the engagement agreed with the stakeholders can take place efficiently, in the timeframes allocated.
  • Manage the release package effectively, ensuring it can be tracked, installed, tested, and verified. This includes the potential for uninstalling or backing out the release. Delivering the release in a controlled manner is crucial to its success.
  • Ensure that the new or changed service meets the utility and warranty requirements. It is important to ensure that the supporting systems and technology for the release are contributing appropriately to achieve the requirements.
  • Manage and record any unplanned outcomes, risks, and issues from the release. Capture of any deviations from the expected performance is an important part of the lessons learned for the release, and suitable changes should be made to ensure the final outcome meets the requirements specified in the original plans.
  • Ensure there is suitable knowledge transfer to the stakeholders of the release to enable proper use of the new or changed service. This should be completed according to the plans and schedule, including the timely delivery of any training requirements for the recipients of the release, both users and the IT operations staff.
  • Ensure that sufficient training is provided for the support teams in operations to enable full capability for maintenance and support according to the utility and warranty requirements. This element of a release may be easy to overlook, particularly because some of the operations teams may be engaged in the deployment of the release, but it is crucial to the success of the deployment that operations are able to support the release effectively and efficiently from the start.

The Scope of the Release and Deployment Management Process

The scope of release and deployment management covers the processes, systems, and functions required to deliver a release into the live environment. This includes the packaging, build, test, and deployment of the release, enabling the release to be executed according to the design package, and the specified utility and warranty requirements. The scope includes the handover to the service operation teams.

All aspects and CIs associated with the release should be managed, including, for example, physical and virtual assets such as servers and networks, applications and software, training for IT staff and users, and services including the supporting agreements and contracts with suppliers.

There are exclusions to the scope of release and deployment, because some aspects are managed as part of other processes. For example, although ensuring that testing takes place is part of the responsibility of release and deployment, the activity of testing and managing the test environment and plans will be carried out by the process of service validation and testing.

Release and deployment is not responsible for authorizing activity toward the release deployment. This will be referred to the change management process and the change authority. Interacting with project management and project authorization may also take place, but any IT change activity should be coordinated through change management.

Creating the Release Policy

To ensure effective management of releases, there should be a defined release policy for each service or group of services. The policy is important for the overall control of release and deployment within service management. Specifying the requirements that should be managed for any release for the service or services, this document should be under change control and managed as a service asset. Not all changes will require release and deployment management for their implementation; for example, minor operational changes will be managed through change management and operational activity. Release and deployment is used for significant or complex changes, and the policy should set out the requirements that need to be considered for successful implementation.

As part of the policy, there should be a definition of the types of release, which will be under the control of release and deployment management. This should be included to set expectations for customers and stakeholders regarding the nature of the release and how it will be managed. A suggestion for release types is a major release; these are releases that will have a significant impact on the business environment, because of either complexity or size, and will often include new functionality. Other suggested types are the minor release, providing minimal impact or only minor upgrades or enhancements, and the emergency release, carried out in response to a business-critical requirement or for a small enhancement. The release policy will define when an emergency release may be carried out and in what circumstances.

The policy should cover some or all of the following elements:

  • A unique identification structure or naming convention to ensure releases can be easily identified and tracked. This should include a description for the associated release.
  • Definitions of the roles and responsibilities required for the management of the release throughout all its stages.
  • Use of the definitive media library for all software asset releases.
  • The expected frequency for specific types of release.
  • The approach for grouping changes into a release and how any additional updates are to be included if enhancements are required.
  • Any automation that can be applied to the build, installation, and deployment to deliver a repeatable mechanism to improve efficiency.
  • How the configuration baseline will be taken prior to the release and what means will be used to verify its accuracy in terms of components before agreement and recording.
  • The entry and exit criteria for each stage of the release, including the authority required, as well as definitions of the acceptance criteria for entry into controlled test and development environments and other supported environments such as disaster recovery or training.
  • The criteria for the final handover into operations, including the criteria for the completion and exit of the early life support stage.

Managing the Four Phases of Release and Deployment

There are four phases to release and deployment:

Release and Deployment Planning This phase starts with the authorization from change management to plan a release and ends with change authorization to create the release. It is here that the plans for creating and deploying the release are produced. This is an important aspect of the process, because a properly planned release will improve the efficiency of the deployment.
Release Build and Test During this phase, the release package is built, tested, and checked into the DML if it is software and documentation only or contains these elements. The trigger for this phase is the authorization from change management for the release build to take place and ends with the authorization to include the baselined package in the DML. This phase will take place only once during any release. Service asset and configuration management has control over the DML, so the processes of change, SACM, and release and deployment will work closely together.
Deployment This phase starts with change management authorization for deploying the release package from the DML and/or hardware store if applicable. The package is deployed to the live environment, and this phase ends with handover to the service operation teams and/or early life support. Depending on the selected deployment mechanisms, there may be a number of stages in the deployment activity. In early life support, the development and deployment teams are still working alongside the operational teams as the release goes live. This provides support for the release in the initial stages, when the majority of the issues will be identified. This step in release and deployment management is crucial for the support of the release as it goes live and provides speedy resolution of issues and faults. This will improve customer and user satisfaction with the new service and will also assist in the transfer of knowledge to the support teams and the users.
Review and Close This is where experience and feedback are captured, performance targets are reviewed, achievements are assessed, and lessons are learned. Improvements identified, either to the process or to the release, should be formally captured, and actions should be taken to address any issues.

In Figure 9.6, you can see the various points where the change process provides authorization and triggers for the phases of the release. This would be managed as part of the original change record and would not require separate requests for change. Some organizations may take a different view, particularly in the case of major releases, and require further documented authorization through raising individual requests for change. But either approach is acceptable, because it is important to ensure that your change and release and deployment processes are flexible enough to meet your organization’s requirements. The important factor is that authorization is provided through change management to trigger each phase of the release.

FIGURE 9.6 The phases of release and deployment

Based on Cabinet Office ITIL material. Reproduced under license from the Cabinet Office.

image
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset