Documente Academic
Documente Profesional
Documente Cultură
Management
"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"
Release and Deployment management includes all the processes, systems and
functions necessary to package, build, tests and deploy Release components
into the live production environment. This process is also responsible for
training end users and operating staff as well as circulating documentation on
the newly deployed Release or the Services it supports. By educating the end
users, Release Management aims to protect the live environment.
Going into more details, the aim of Release and Deployment Management is to
build, test and deliver capabilities or skills according to the specifications
provided by Service Design, so that the Service requirements demanded by the
stakeholders are realized.
To minimize the incidence of Changes in Service Assets and IT infrastructure
and to provide users with stable Services, a single Release contains multiple
Changes.
Organizations must closely coordinate the issues of new Releases with
customers, users and IT operating staff. To avoid any possible resistance to the
new Releases, organizations must bring in experts to manage the different
types of expectations from all stakeholders. All stakeholders involved, including
organizational staff must agree on defined acceptance criteria for the Releases.
The CAB should give its authorization for the release of Services into the
production environment only after the Release has been tested and concluded
successfully.
Release Management is not to be confused with Change Management. This is
because Release Management focuses on implementing Changes while Change
Management focuses on Change control and monitoring.
Outline and agree to Release and Deployment plans with customers and
stakeholders
Make sure that each Release Package consists of a set of related and
compatible assets and Service components
Make sure that the integrity of a Release Package and its components is
maintained throughout transition activities and recorded accurately in the
CMS
Make sure that it is possible to track, install, test, verify and/or uninstall
or back out all Release and Deployment packages as appropriate
Manage organizational and stakeholder change during Release and
Deployment activities
Document and manage deviations, Risks and issues related to a new or
changed Service and take the necessary corrective action
Transfer knowledge to enable customers and users to use the Service
Transfer skills and knowledge to operations and support staff to help
them deliver, support and maintain the Service effectively and efficiently,
according to required Warranties and Services levels
Goals
Objectives
Ensure that customers, users and Service Management staff are satisfied
with the practices and outputs of Service Transition, for example, user
documentation and training
Scope of Release and Deployment Management
Release and Deployment Management includes all the processes, systems and
functions necessary to package, build, test and deploy Release components
into the live production environment. This process is also responsible for
training end users and operating staff, as well as circulating documentation on
the newly deployed Release or the Services it supports. By educating the end
users, Release Management aims to protect the live environment.
In addition, Release and Deployment Management sets up all Services
specified in the SDP before handing the Services over to Service Operations.
Release and Deployment Management Outputs
An updated Service package or Service bundle that defines the end-toend Service(s) offered to customers
Enable the use of the new or changed Service by customers and users in
a manner that supports business goals
Release definition
Naming/numbering Frequency/occurrenc
e
Windows
Server
image
Minor/Major/Emergency WS2012R2_vx_xx
Monthly/quarterly
The amount of resources and time required to build, test, distribute and
implement a Release Unit
The complexity of interfaces between the proposed unit and the rest of
the Services and IT infrastructure
Release
window
Last
Monday of
the Month
Phased
Push
Pull
Big Bang
This approach aims to deploy a new or changed Service to all users in one go,
that is, to launch the Release all at once. This is often used to introduce an
application Change across the organization to ensure Service consistency.
Phased
A diametrically opposite approach is the phased approach. In this, the device is
initially deployed to part of the user base and the operation is then repeated
for subsequent parts of the user base via a scheduled rollout plan.
Push
As the name "push" suggests, the Service component is deployed from the
center and pushed out to the target locations.
Pull
Pull relies on the user to download the software (pull cannot be used for the big
bang approach) because some users may never download the software, an
organization may choose to eventually push a Release to get all users to the
same level; this reduces support complexity and cost.
Service Deployment
As far as Service Deployment is concerned, delivering updated Service
components to all users, either in big-bang or phased form, constitutes a push.
This is because the new Service is delivered to users at a time not chosen by
them, that is, the Service is pushed into the user's environment.
Planning and Defining Service Release and Deployment
There are two ways to do this:
Mechanisms
Pros
Cons
Automated mechanism
More error-free
Manual
Automation
This helps ensure repeatability and consistency:
Release structure
Controlled environments
Service Design selects the most suitable Release and Deployment model for a
Release. This model includes the approach, mechanisms, processes,
procedures and resources to build and deploy the Release on time and within
budget.
Plan and
prepare
release
Build
Service
Plan and
and test testing and prepare for
pilots
deployment
Early Life
Support
Release and Deployment Management Activities
1 Plan
a Release and Deployment plans
b Pass/fail criteria
c Build and test prior to production
d Planning pilots
e Planning Release packaging and building
f Deployment planning
g Logistics and delivery planning
h Financial and commercial planning
2 Prepare for build, test and deployment
3 Build and test
a Release and build documentation
b Acquiring and testing input Cis and components
c Release packaging
d Building and managing test environments
e Service testing and pilots
f Service rehearsals
g Plan - preparing for the day
h Do - delivering the rehearsal
i Check - documenting the day
j Act - taking action following the rehearsal
k Pilots
2 Plan and prepare for deployment
a Assessing
Transfer,
deploy,
retire
Review and
close Service
Transition
Se
Op
2
3
4
5
Plan pilots
o
Pilots are useful for testing the Service with a small part of the
user base before rolling it out to the entire community
The evaluation report and the RFC for build and test are signed off
Examples of Fail Situations
The build test does not allow the process to move to the next stage
because of insufficient resources
Mandatory documents for going to the next stage are not signed off
Both the SKMS and the CMS are not updated. This could be because of a
manually intensive process
Build environment
Iis used to compile or assemble the Release Package or Service
Assets
Integration environment
o
Is used to build and integrate Service components
Training environments
o
May include an established test database that can be used as a
safe and realistic training environment
Pilot environments
o
May include conference room pilots
Release Check
You need to check financial and commercial aspects before the deployment
and add activities to the deployment plans, where necessary. You need to
check the following:
Record, track and measure any Risks and Issues against the Services,
Service Assets and Cis within the Service Package
Keep a validation report and its associated results ready for evaluation
It is critical to map the Service Design and the Release Design against the
requirement for the new or changed Service. This activity must be done before
authorizing the build and test stage. At the end of this activity, you should have
constructive feedback on Service Design.
Independent Evaluation
An independent evaluation of the Service and Release Design checks if the
Change to the Services or Service offering will deliver the predicted outcomes.
Interim Report
If the evaluation throws up any issues, an interim report is prepared.
The report lists:
Risk profile
Technical training
Service Management and process training, e.g. new build procedure for
new configuration item type
Build and Test
Some key aspects that need to be managed during the Build and Test phase of
Release and Deployment are:
Management of configurations
o
Implementing Configuration Management during build and test
activities
o
Maintaining a record of the complete build
o
Keeping testing evidence and documentation
o
Maintaining access controls to physical and technology
components
o
Verifying whether security arrangements are met
o
Managing environmental issues
o
Readying the Service Release for promotion to the next
environment
o
Handing over the Service Release to the next stage or team
Updating the CMS
The CMS is updated with the Configuration Baselines of the controlled
environment and the Release Package before and after an installation, build or
deployment.
The Service Provider must ensure that only the definitive version of the Release
Package is placed in the Definitive Media Library (DML). The Release Package
must always be taken from the DML to deploy to service Operation.
Release and Build Documentation
Use procedures and templates to build and test a Release.
It is a best practice to use procedures and templates to build and test a Release
because they help the Release team build a Release Package efficiently and
effectively.
The procedures and templates include:
Purchase requests
Request Fulfilment
Leasing agreements
Intellectual Property Rights (IPR)
Support agreements
Procedures
o
Manage Service and infrastructure
o
Distribute and install software
o
Distribute, translate and convert data and information
o
Deliver, install and move equipment
o
Clean data
o
Dispose documents
o
Build and manage test environments
o
Validate and test
o
Manage Change
Managing Service Assets and configurations
Managing acceptance and authorization
Documenting license agreements
Documentation
Document a new Release to ensure all the gathered information is handed over
to the Service Operations and CSI teams.
This documentation includes:
Process descriptions
User manuals
Service information
Marketing information
Service Catalogue
Technical information
Checking that all software is as expected, all definitive items have been
added to the DML, the rejection of components and software is as
expected and so on
Release packaging
Aim of Testing
Testing aims to build confidence in the Service capability prior to final
acceptance during pilots or ELS
The steps to conduct testing and pilot are:
Service Rehearsals
A Service Rehearsal is a type of testing method that aims to stimulate as much
of the Service as possible in an extensive and widely-participated-in practice
session. This is the last stage of internal testing before any public, live run of
the Service.
Successful delivery of a Service Rehearsal involves one or more stages,
including preparation and analysis, following the Deming cycle's steps:
Make sure that the people involved in the pilot are trained
Made sure that the senior management, customers and business and
Service Provider teams:
o
Accept the deployment costs
o
Understand the management, organization and people
implications of the Release
o
Understand all required process Changes
Preparing for Deployment
Current capability of business customers and users to use and get value
from the new or changed Services
The final step is to verify the detailed deployment plans, perform any
deployment readiness tests and raise an RFC for authorization through Change
Management. This ensures that the Service is ready for deployment.
Plan and Prepare for Deployment
Intellectual property
Naming existing people, for example, staff, supplier and users with the
required skills and transferring or reallocation people as needed
Assessing the competence of new and changed staff and other people
Deployment Processes and Materials for Users
Materials may include policies, processes, procedures, manuals, overviews,
training products, organizational Change products and so on.
After sharing the materials, check whether the users are competent and
confident to operate, maintain and manage the Service. At this time, remove or
archive redundant Services and Assets.
Transfer the Service
Transferring a Service includes the following activities:
Build, install and configure the service and Service components with any
new information
Test the system and the Service per the defined test plan and collate the
test results
Identify licenses and other assets that can be reused in the organization
Update DML
You may need to retire a Service after a specific interval of time. This ensures
that the service does not include defunct aspects. Failure to perform retirement
or decommissioning activities may lead to license contravention or the staff
using unsupported software.
You must also remove any redundant assets at this stage. These may include
redundant data, information and records related to the previous Service or
products they may also include support contracts with third-party contractors
and so on.
4.5.6 Release Verification
To verify the deployment:
Ensure that the Service, Service assets and Service capability resources
are in place
ELS gives the right resources to quickly, centrally and locally resolve
operational and support issues so that users can use the Service without
unwarranted disruptions to support their business activities. The deployment
teams should examine where issues and Problems are likely to occur, based on
earlier experience.
Examples of ELS Issues and Problems
Clarification about:
Escalation procedures
Complaints procedure
Ensures that all documentation and the knowledge base are up-to-date,
with current information on other diagnostics, Known Errors, Workarounds
and FAQs
An SLP
Exit and entry criteria for each stage of release and deployment
Outputs
Some key outputs of the Release process are:
Service notification
Updated service catalogue with the relevant information about the new
or changed service
An SLP that defines the service level requirements, e.g. hours of service,
business critical services, data and periods, service level targets
Service Model that describes the structure and dynamics of how the
service is operated and managed
Complete and accurate CI list with an audit trail for the Cis in the release
package and also the new or changed Service and infrastructure
configurations
Service capacity plan that is aligned to the relevant business plans
Deployment ready Release Package (baselined) for future deployments
Service Transition Report
Other data and information will also be captured and recorded within the
broader SKMS. This could include:
o
Deployment, information, history of the deployment itself, who
was involved, timings and so on
o
The HR in many organizations holds the training records of its staff
but the responsibility for the update of the ITSM staff records will
logically rest with ITSM also
o
Access rules and levels
o
Known Errors. Typically, a new or changed Service will be
introduced with identified errors that, while not according to the
original Service Design specification, are nonetheless minor enough
in nature to be acceptable in live operation. These may well be under
active investigation and resolution by the Service builders of may
considered acceptable. In either case, the errors will be deployed into
the live error database as an element of the deployment of the live
Service. This information will be available through the SKMS to the
Service Desk, which will then be able to link Incidents reported
against these Known Errors.
o
As part of clean-up activities, it is important to delete or archive
redundant records related to the previous Service or products
License holding
In the deployment process, you must also capture and record other information
that falls into the scope of a broader SKMS.
This could include:
ii
Test Management
iii
Change Management
iv
Service Asset and Configuration Management (SACM)
v
Capacity Management
vi
Availability Management
vii
Incident Management
viii
Quality Management
The deployment staff:
a Perform the final physical delivery of the Service implementation
b Coordinate Release documentation, including technical Release notes
and manage communications training and customer and Service
Management
c Plan the deployment process interface with Change and Knowledge
Management and SACM
d Provide feedback on the effectiveness of the Release
e Provide technical and application guidance and support throughout
the Release process, including for Known Errors and Workarounds
f Record deployment metrics to ensure that they are within agreed
SLAs
ELS is considered a vital part of the Release and Deployment phase. ELS
should start before a Service is operational. The ELS staff:
a Provide IT Service and business, functional support before Service
Operations finally accepts the Service
b Ensure the delivery of appropriate support documentation
c Provide Release acceptance for ELS
d Provide initial support in response to the Incidents and errors
detected within a new or changed Service
e Adapt initial usage elements, such as:
i
User and support documentation, including service Desk scripts
ii
Data management, including archiving
b Embed activities for a new or changed Service
c Ensure formal transition of the Service to the Service Operations and
CSI phases of the Service Lifecycle
d Monitor Incidents and Problems and undertake Problem Management
during Release and Deployment along with raising RFCs, when
required
e Provide initial performance reporting and undertaking performancebased Service Risk assessment
The Release and Deployment Manager also manages all deliverables, right
from their purchase or development to their configuration and implementation.
Risks
Management Risks
o
Management incompetence