Checklist Release Policy: Difference between revisions
No edit summary |
|||
Line 19: | Line 19: | ||
<p> </p> | <p> </p> | ||
__TOC__ | |||
===<span id="Release Policy Template">Overview</span>=== | ===<span id="Release Policy Template">Overview</span>=== | ||
[[image:Release-policy-template.png|thumb|388px|right|alt=Checklist Release Policy]] | |||
The ''Release Policy'' represents a set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact. | The ''Release Policy'' represents a set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact. | ||
<p> </p> | <p> </p> | ||
<br style="clear:both;"/> | |||
==Release Policy - Contents== | ==Release Policy - Contents== |
Revision as of 13:48, 13 August 2014
ITIL Process: ITIL 2011 Service Transition - Release and Deployment Management
Checklist Category: Templates ITIL 2011 - Service Transition
Source: Checklist "Release Policy" from the ITIL Process Map
Overview
The Release Policy represents a set of rules for deploying releases into the live operational environment, defining different approaches for releases depending on their urgency and impact.
Release Policy - Contents
The Release Policy typically contains the following information:
Release identification
(Release identification, numbering and naming conventions)
Requirements
(Requirement that only software from the DML may be included in Releases)
Release levels
For each release level, e.g. major, minor, emergency releases:
- Definition of release level
- Expected frequency
- Roles and responsibilities as well as entry and exit criteria for the different stages of the Release and Deployment Management process (these may be modified for specific transitions as the necessity arises)
- Approach and guidelines for grouping Changes into Releases
- Planning and documentation requirements, e.g.
- Minor Release deployment uses the simpler Minor Change Deployment process and is documented in Release Records and Change Records
- Major Release deployment requires setting up a formal project with full documentation
- Emergency Release deployment requires authorization by ECAB and is planned, coordinated and documented by a Major Incident Team
Guidelines for different approaches to Release deployment
What are the specific conditions which make a certain approach the preferred option, e.g.
- "Big-bang" vs. phased deployment
- "Push" vs. "pull" deployment
- Automated vs. manual deployment
Constraints for Release deployment
Service Level and Operational Level Agreements typically specify availability targets, including allowed windows for maintenance during which the service might be unavailable. Unless Emergency Releases are required, Releases are routinely deployed during these maintenance windows. Release Management therefore needs to translate the service-specific constraints into Release deployment constraints for the systems, applications and other components which are required for the service to be available.
- Service-specific Release deployment constraints as defined in the Service Level and Operational Level Agreements
- Service A
- Allowed frequency of new releases according to Release type
- Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
- Service B
- …
- Service A
- Release deployment constraints for systems, applications and other components supporting the above services
- System A
- Allowed frequency of new releases according to Release type
- Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
- System B
- …
- System A
Preferred mechanisms
(Preferred mechanisms to automate the deployment of Releases)