Service Transition Release and Deployment Management in ITIL – ITIL Course

Service Transition

Release  and Deployment Management
Release Management processcontrols 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  servic 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 deploymentof 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  agre
ed service requirements
•   Ensure that there is knowledge transfer to customersand users
•              Ensure  thatskills 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

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 servicespecified in the service design package, and formally hand the serviceover to the service operation functions.
The scope also includes:
•   Physical assetssuch 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.
The Release and Deployment Management manages release and deployment plans, packages and knowledgetransfer 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 factorsshould 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 neededto build, test, distribute and implement a Release Unit
o      The complexity of interfaces between the proposedunit and the rest of the services
•              Release  Package  / Release  Design:  Used to upgrade  an IT Service  froma 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 deployedfrom 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 locationwhen they choose to do
o. This approach is used for software releases.
•              Automatio vs Manual:   Automatio 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 servicesand 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 rel< /span>ease  anddeployment 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 capturedand 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
The types of release shouldbe 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
There are several key roles in Release and DeploymentManagement that are vital to the success of this process.
•              Release  andDeployment  Manager:  Responsible  for planning,  design,  build, configuration  andtesting 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, producereports and input for the sign-off process.
•              Deployment Staff: Responsibilities include final physicaldelivery of the service implementation,  coordinate release documentation  and communications;  plan deployment  with Change, SKMS and SACM; and provide technicalguidance and record metrics.
•              Early Life Support Staff: Helps throughout the release and deploymentphase 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  andDeployment Management

There are four phasesto release and deployment management:
•   Release and deployment planning
Plans for creating and deploying the release are created.This phase starts withchange management authorization to plan a release and ends with change managementauthorization to create the release.
•   Release build and test
The release packageis built, tested and checked into the DML. This phase starts with change management authorization to build the release and ends withchange 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 packagein 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 feedbackare captured, performance targetsand achievements are reviewed and lessons are learned.
Service V Model
Service V Model is a model that can be used to < /span>representthe 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