Functions and Processes in Service Transition P4

Release and Deployment Management
Introduction

• ITIL defines release and deployment management as follows:

• Release and deployment management aims to build, test
  
  and deliver the capability to provide the services specified by
  
  service design and that will accomplish the stakeholders’
  
  requirements and deliver the intended objectives.

• The goal of release and deployment management is the
  
  deployment of releases into production, and the establishment of
  
  effective use of the service in order to deliver value to the
  
  customer and to be able to handover to service operation.

• The objective of release and deployment management is
  
  to ensure that:

• Release and deployment plans are in
  
  place.

• Release packages (compilation) are deployed
  
  successfully.

• Knowledge transfer to the customers takes
  
  place.

• There is minimum disruption to the
  
  services.

• Scope

• The processes, systems and functions for packaging,
  
  building, testing and deployment of a release into production
  
  and

• establishment of the service specified in the service
  
  design package before final handover to service
  
  operations.

• Value for the business

• Effective release and deployment management contributes
  
  to the business because:

• Changes are realized faster, cheaper and with fewer
  
  risks, and the operational objectives are supported
  
  better.

• The implementation approach is more consistent and the
  
  traceability requirements (e.g. audits, legislation etc.) are
  
  compiled with more closely.

• Basic concepts

• A releaseis a set of new or changed CIs that are tested
  
  and will be implemented into production together.

• A release unit is the portion of the service or
  
  infrastructure that is included in the release, in accordance with
  
  the organization’s release guidelines.

• It is important to determine the correct level of
  
  the release.

• In the release design different considerations apply
  
  in respect of the way in which the release is deployed.

• The most frequently occurring options for the rollout of
  
  releases are:

• Big bang versus phased –A big bang deploys the new
  
  or changed service for all the users at the same time. A phased
  
  deployment deploys the release for part of the user base at a
  
  time.

• Push and pull –With a push approach the service
  
  component is deployment from the “center” to the target locations.
  
  With a pull approach the new release is made available to the users
  
  from a central location from which they download to their location
  
  at a time they choose.

• The most frequently occurring options for the rollout of
  
  releases are:

• Automated or manual –Releases can, to a large
  
  extent, be automated; e.g. the use of installation
  
  software.

• The release and deployment teams must have a good
  
  understanding of the relevant IT architecture involved in a release
  
  and deployment process.

• A release package is a single release unit or structured
  
  set of release units.

Activities, methods and techniques

• The basic process activities of release and deployment
  
  management consist of:

• 1.Planning

• 2.Preparation for building, testing and
  
  deployment

• 3.Building and testing

• 4.Service testing and pilots

• 5.Planning and preparing the deployment

• 6.Transfer, deployment, and retirement

• 7.Verify deployment

• 8.Early Life Support (ELS)

• 9.Review and close

• 1.Planning

• Release and deployment plans form part of the overall
  
  Service Transition plan.

• Change management will approve or reject the
  
  plans.

• The plans will include the following:

• Scope, content, risks, responsibilities and stakeholders
  
  in the release.

• Team responsible for the release

• Approach for collaboration with all
  
  stakeholders

• The V model is a convenient tool for mapping out the
  
  different configuration levels at which building and testing must
  
  take place.

• The left side of the V starts with service
  
  specifications and ends with the detailed Service
  
  Design.

• The right side of the V reflects the test activities, by
  
  means of which the specifications on the left-hand side must be
  
  validated.

• Planning of pilots

• To test the new or changed service with part of the
  
  users first, a pilot can be planned.

• Do not forget to include in the plans how the feedback
  
  from the users is to be collected and processed, and advise a
  
  rollout scenario.

• Planning of release package (compilation) and
  
  build

• Formulate plans and procedures for:

• pass/fail criteria

• The management of changes and the communication with
  
  stakeholders

• Training of staff, knowledge transfer and readiness
  
  assessment of end users

• Planning of release package (compilation) and build
  
  • Formulate plans and procedures for:


• The use of (service management)
  
  resources.


• The transfer of systems and users to the new
  
  service


• Deployment planning


• With regard to deployment include the following
  
  considerations in the plan:


• What is being deployed?


• Who are the users?


• What is the local situation?


• Where are the users?


• Deployment planning


• With regard to deployment include the following
considerations in the plan:

• Who else needs to be notified?

• Why is there a deployment?

• What are the Critical Success Factors?
  
  • Logistical planning and delivery planning


• Once the deployment approach has been decided,
  
  logistical and delivery plans will be formulated with attention for
  
  the following points:


• When and how will the service components be
  
  delivered


• What should be done if there are delays


• Managing customs and other implications of international
  
  distributions


• Financial and commercial planning


• Financial and commercial aspects must be checked before
  
  the deployment takes place.


• 2.Preparation for building (compilation), testing and
  
  deployment


• Before approval can be given for the building and test
  
  phase, the service and release design is compared against
  
  specifications of the new or changed service
  
  (validation).

Activities, methods and techniques

• 2.Preparation for building (compilation), testing and
  
  deployment


• These issues or risks are then prioritized and actions
  
  are undertaken to resolve them in good time.


• The service evaluation report documents the results of
  
  the validation.


• 3.Building and testing


• The build and test phase of the release consists of the
  
  following activities:


• Management of general (common) infrastructure and
  
  services–Carefully manage the common services and infrastructure, as
  
  they may be significant importance to the building and
  
  testing.


• Use of release and building documentation –the available
  
  documentation (procedures, templates, manuals) must be used
  
  throughout; this documentation supports the release team in
  
  acquiring and purchasing assets, CIs, services and products for the
  
  construction of an integrated release package.


• 3.Building and testing


• The build and test phase of the release consists of the
  
  following activities:


• Use of release and building documentation -in this
  
  context also consider proof of licenses (it must be possible to
  
  produce the required licenses) of the various
  
  components.


• Acquisition, purchasing and testing of CIs and
  
  components for the release –CIs and components are acquired from
  
  projects, suppliers and partners; the purchasing activities
  
  include:


• The recording or updating of the CIs in the
  
  CMS


• Ensuring that the licenses can be produced when
  
  necessary


• Check the CIs and components for quality, legality and
  
  the requirements with respect to labeling and naming


• 3.Building and testing


• The build and test phase of the release consists of the
  
  following activities:


• Compilation of the release (release packaging)–The key
  
  activities for building and compiling a release package
  
  are:


• Assembling and integrating the components


• Preparing the compilation and release
  
  documentation


• Installing and checking the release
  
  package


• Creating a baseline of the composition of the
  
  package


• Formulating a service message (that the release package
  
  is ready for use)


• Structuring and controlling the test environments –The
  
  test environments must be stable and able to be
  
  controlled.


• 4.Service testing and pilots


• Test management is responsible for the coordination of
  
  the test activities and the planning and control of the
  
  implementation.


• Tests that are conducted during the release and
  
  deployment process:


• Service release test –the service release test checks
  
  whether the service components work well together (integration), and
  
  that the release can be compiled, installed and tested in the target
  
  environment.


• 4.Service testing and pilots


• Tests that are conducted during the release and
  
  deployment process:


• Service Operation “readiness testing” –This test ensures
  
  that the service and the underlying applications and technical
  
  infrastructure can be transferred to the live environment in a
  
  controlled manner.


• Pilots–A pilot is intended to test whether there are
  
  elements of the service that do not meet specifications, or may pose
  
  a risk to the business.


• 5.Planning and preparing for deployment


• These activities prepare the deployment group for
  
  deployment. The following need to be addressed:


• Are they ready for the implementation of the release
  
  package?


• Have they prepared the activity plan?


• Have the potential risks been mapped out?


• Is everyone sufficiently trained?


• Have there been any last-minute changes in the
  
  specifications?


• 5.Planning and preparing for deployment


• When planning a specific deployment, plans
  
  include:


• Risk limitation


• Transfers


• Upgrades


• Logistical matters


• Knowledge transfer and communication


• Finally, these plans have to be evaluated and an RFC
  
  must be created that is submitted to change management for approval.
  
  After this the service is ready for deployment.


• 6.Transfer, deployment, and retirement


• The following activities are important during the
  
  deployment:


• The transfer of financial assets –This may be, for
  
  instance, the transfer of support and maintenance costs, license
  
  fees and contingency reserves (disaster recovery) to a third
  
  party.


• Transfer and transition of business and organization –
  
  When a service or service unit is transferred the organization
  
  itself will also have to be adapted; consider, for instance, new
  
  tasks, authorities and responsibilities.


• 6.Transfer, deployment, and retirement


• The following activities are important during the
  
  deployment:


• Publication of documentation –Distribute all
  
  documentation (guidelines, processes, procedures, manuals) that the
  
  users will need to take the new service into use.


• Transfer of “service management capability” –Transfer
  
  new or changed process information, systems and tools to the team
  
  that is responsible for the service management
  
  activities.


• Transfer of the service –Activities that are relevant in
  
  this process include:


• Analysis of service performance, issues and
  
  risks


• Configuration audits of service assets


• 6.Transfer, deployment, and retirement


• The following activities are important during the
  
  deployment:


• Transfer of the service –Activities that are relevant in
  
  this process include:


• Updating of service catalogue


• Distribution of service notification


• Deployment of the service –All activities needed to
  
  distribute and install the service.


• Cancellation of services –Cancel redundant
  
  services.


• Removal of redundant assets –Remove assets that are
  
  redundant as a result of the new or changed service.


• 7.Verify deployment


• When all the deployment activities have been completed
  
  it is important to verify that all the users, service operations,
  
  other staff and stakeholders are able to use the service as
  
  intended.


• Also a good time to collect feedback on the
  
  deployment.


• Use this information for the improvement of future
  
  deployment.


• 8.Early life support


• Early Life Support (ELS) is intended to offer extra
  
  support after the deployment of a new or changed
  
  services.


• Provides the means to resolve operational an support
  
  problems as quickly as possible, which means that users do not have
  
  to be confronted with service interruptions.


• May be “teething problems” or improvements that can help
  
  to stabilize the service.


• 8.Early life support


• The deployment team also updated the documentation
  
  during the ELS phase and updates the knowledge bank with additional
  
  diagnostic information, known errors, workarounds and
  
  FAQs.


• Service Transition will monitor the performance of the
  
  new or changed service during the ELS phase until all the exit
  
  criteria have been met, including:


• All users are able to use the services effectively and
  
  efficiently


• Service and process owners are able to manage the
  
  service


• Agreed service and performance levels are acheived


• 9.Review and close


• In the review of a deployment, check
  
  whether:


• The knowledge transfer and training were
  
  adequate


• All user experiences have been documented


• All fixes and changes are complete and all problems,
  
  known errors and workarounds have been documented


• The quality criteria have been compiled
  
  with


• The service is ready for transition from ELS into
  
  production


• Also check whether there are issues that have to be
  
  passed on to CSI.


• The deployment is completed when the support is
  
  transferred to Operations.


• 9.Review and close


• Finally, change management will conduct a Post
  
  Implementation Review (PIR).


• To finalize the Service Transition as a whole a formal
  
  evaluation must be performed that is tailored to wit the scale and
  
  scope of the change.

Information management

• As CIs are deployed successfully the CMS is updated with
  
  information such as:


• New or changed CIs


• Relationships between requirements and test
  
  cases


• Installation and build plans


• Logistics and delivery plans


• Validation and test plans


• New or change locations and users


• Status updates


• Changes of ownership (of assets and CIs)


• Licenses


• Documented information for the service knowledge management
  
  system, such as information about the deployment, training and known
  
  errors, may be necessary.

Interfaces

• The release process is triggered by an approved
  
  RFC.


• Inputsfor the release and deployment process are:


• Approved RFC, service package, SLP, SDP, SAC, continuity
  
  plans


• Release policies, design and model, construction model
  
  and plan


• Technology, purchasing, service management and operation
  
  standards and plans


• Exit and entry criteria for each phase of the release
  
  and deployment


• Outputsfrom the release and deployment process
  
  are:


• Release and deployment plans, completed RFC, service
  
  notifications, an updated service catalogue and service
  
  model


• New or changed service management documentation and
  
  service reports


• New tested service capability and
  
  environment


• SLA, OLAs and contracts


• Service Transition report and service capacity
  
  plan

Implementation

• Challengesin the release and deployment process
  
  include:


• The development of standard performance measurements and
  
  methods across projects and suppliers


• Dependence on projects and suppliers


• Understanding all the risks that may affect the Service
  
  Transition


• Understanding the perspectives and starting points of
  
  the different stakeholders


• Critical success factors in the release deployment process
  
  include:


• New (or changed) service runs in the target environment
  
  and is tested against the Service Design


• New (or changed) service has proven itself in a
  
  pilot


• Test models are re-usable for regression tests in future
  
  release


• Risksin the release and deployment process are:


• Lack of clarity in the expectations and objectives of
  
  different stakeholders, ill-defined roles, tasks and
  
  responsibilities.


• Incompetent management, insufficient financial
  
  resources, lack of control, poor change management


• Poor relationships with partners and service providers,
  
  insufficient support (commitment) from stakeholders


• Risk relating to the technical infrastructure and
  
  applications

Source by : OGC