Service Transition
Release and Deployment Management
Introduction
Release Management process
controls productions of software and hardware within
the IT infrastructure and arranges their distribution within the operational environment.
“Release and Deployment Management aims to build, test and deliver the capability
to provide the services specified by service design
that will accomplish the stakeholders’ requirements and deliver the intended objectives.”
Purpose and Objectives
The purpose of the
release and deployment management process is to plan, schedule and control the build, test and deployment
of releases and to deliver new functionality
required by the business
while
protecting the integrity of existing services
The objectives of Release and Deployment Management are to:
• Ensure that there are clear and comprehensive release and deployment plans
• Ensure that a Release Package
can be built, installed,
tested and deployed
efficiently
• Ensure that
a new or changed
service is capable
of delivering
the
agreed service requirements
• Ensure that there is knowledge transfer to customers
and users
• Ensure that
skills and knowledge
are transferred to operations
and support staff
• Ensure that there is minimal unpredicted impact on the production services, operations and support organization
• Ensure that customers, users and service management staff are satisfied with the Service Transition practices
Scope
The scope of release and deployment management includes the processes, systems and functions to package,
build, test and deploy a release into live use, establish the service
specified in the service design package, and formally hand the service
over to the service operation functions.
The scope also includes:
• Physical assets
such as a server or network
• Virtual assets such as a virtual server or virtual storage
• Applications and software
• Training for users and IT staff
• Services, including all related contracts and agreements.
Concepts
The Release and Deployment Management manages release and deployment plans,
packages and knowledge
transfer internally and externally.
Concepts applied in Release and Deployment Management are:
• Release: Defined as the collection
of
hardware,
software,
documentation, processes or
other components required to implement one or more approved changes to IT services.
• Release unit: Describes
the portion
of a service or IT infrastructure
that is normally released together.
The following factors
should be taken into account when deciding the appropriate level for Release Units:
o The ease and amount of change necessary
to release and deploy a
Release Unit
o The amount of resources and time needed
to build, test, distribute and implement a Release Unit
o The complexity of interfaces between the proposed
unit and the rest of the services
• Release Package
/ Release
Design: Used to upgrade
an IT Service from
a current situation to the desired situation. It contains software, hardware, documentation and training.
Release Approaches
• Big Bang or Phased approach:
Big Bang option: The new or changed service is deployed all at once, in one operation.
Phased approach: The service is deployed in stages via a scheduled rollout plan.
• Push and Pull Approach:
Push approach: The service component is deployed
from the centre and pushed out to the target locations.
Pull approach: The software is made
available
in
a
central location.
Users are free to pull the software to their location
when they choose to do so. This approach is used for software releases.
• Automation vs. Manual: Automation helps to ensure consistency and repeatability. If
using manual, it is
important to measure
and
monitor
the impact of many repeated
manual activities
because
they
are
likely
to be inefficient and error-prone.
Release Policy
The release policy should be defined for one or more services
and include:
• The unique identification, numbering and naming
conventions
for
different types of release together with a description
• The roles and responsibilities at each stage in the release and
deployment process
• The approach for accepting and grouping changes into a release
• The mechanism to automate
the
build, installation
and
release distribution processes to improve re-use, repeatability and efficiency
• How the configuration baseline for the release is captured
and verified against
the actual release contents
• Exit and entry criteria and authority for acceptance
of the release
into each
Service Transition stage
• Criteria
and authorization to exit early life support
and handover to Service
Operations
The types of release should
be defined as this helps to set customer and stakeholder expectations about the planned releases. Types of releases are:
• Major releases: Contains large areas of new functionality, some of which may eliminate temporary fixes to problems.
A major upgrade
or release
usually supersedes all preceding minor upgrades,
releases and emergency fixes.
• Minor releases: Contains small enhancements and fixes, some of which may already have been issued as emergency
fixes. A minor upgrade or release usually supersedes all preceding emergency fixes.
• Emergency releases: Contains
the corrections
to a small number of known errors or sometimes an enhancement to meet a high priority business requirement
Roles
There are several key roles in Release and Deployment
Management that are vital to the success of this process.
• Release and
Deployment Manager: Responsible
for planning,
design, build,
configuration and
testing of all software and hardware
to create the release package for the designated service.
• Release Packaging and Build Manager: Responsibilities include establishing the final release configuration,
delivery, testing, produce
reports and input for the sign-off process.
• Deployment Staff: Responsibilities include final physical
delivery of the service implementation,
coordinate release documentation
and communications;
plan deployment with Change, SKMS and SACM; and provide technical
guidance and record metrics.
• Early Life Support Staff: Helps throughout the release and deployment
phase and the first period of operation.
Release and Deployment Model
Release and deployment of a service
may be carried out in different ways
using suitable
release and deployment
models. These release and
deployment models
include various
approaches, processes,
procedures and
resources. The
models ensure that deployment is released on time and within the budget.
Release and Deployment Models
define the structure,
criteria,
controlled environments,
roles,
releases,
support
and handover
activities
related
to the pre- production stage.
Four Phases
of Release and
Deployment Management
There are four phases
to release and deployment management:
• Release and deployment planning
Plans for creating and deploying the release are created.
This phase starts with
change management authorization to plan a release and ends with change management
authorization to create the release.
• Release build and test
The release package
is built, tested and checked into the DML. This phase starts with change management authorization to build the release and ends with
change management authorization for the baseline release package to be checked into the DML by service asset and configuration management.
This phase only happens once for each release.
• Deployment
The release package
in the DML is deployed to the live environment. This phase starts with change management authorization to deploy the release package to one or more target environments and ends with handover to the service operation functions and early life support.
There may be many separate deployment phases for each release, depending on the planned deployment options.
• Review and close
Experience and feedback
are captured, performance targets
and achievements are reviewed and lessons are learned.
Service V Model
Service V Model is a model that can be used to represent
the different configuration levels to be built and tested to deliver a service capability.
ITIL, ITIL Foundation Course, ITIL V3, ITIL Course, ITIL - Course, online itil, itil certification, online material for itil course