Checklist Release Policy: Difference between revisions

From IT Process Wiki
(Created page with "<seo metakeywords="release policy, itil release policy, release policy itil" metadescription="Release Policy Template. The Release Policy represents a set of rules for deployi...")
 
Line 1: Line 1:
<seo metakeywords="release policy, itil release policy, release policy itil" metadescription="Release Policy Template. The Release Policy represents a set of rules for deploying releases into the live operational environment, ..." />
<itpmch><title>Checklist Release Policy | IT Process Wiki</title>
<meta name="keywords" content="release policy, itil release policy, release policy itil" />
<meta name="description" content="Release Policy Template. The Release Policy represents a set of rules for deploying releases into the live operational environment, ..." />
</itpmch>
<imagemap>
<imagemap>
Image:ITIL-Wiki-deutsch.jpg|right|Checklist Release Policy - Template Release Policy
Image:ITIL-Wiki-deutsch.jpg|right|Checklist Release Policy - Template Release Policy
Line 7: Line 10:
<br style="clear:both;"/>
<br style="clear:both;"/>


== <span id="Release Policy Template">Overview</span> ==
<p>&nbsp;</p>


'''ITIL Process''': [[ITIL V3 Service Transition|ITIL 2011 Service Transition]] - [[Release and Deployment Management]]
'''ITIL Process''': [[ITIL Service Transition|ITIL 2011 Service Transition]] - [[Release and Deployment Management]]


'''Checklist Category:''' [[ITIL-Checklists#Checklists ITIL Service Transition|Checklists ITIL Service Transition]]
'''Checklist Category:''' [[ITIL-Checklists#ITIL 2011 Templates|Templates ITIL 2011]] - Service Transition


'''Source''': Checklist "Release Policy" from the [https://en.it-processmaps.com/products/itil-process-map.html ITIL Process Map]
'''Source''': Checklist "Release Policy" from the [https://en.it-processmaps.com/products/itil-process-map.html ITIL Process Map]


<p>&nbsp;</p>
<p>&nbsp;</p>
===<span id="Release Policy Template">Overview</span>===


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.
Line 22: Line 27:
__TOC__
__TOC__


== Release Policy - Contents ==
==Release Policy - Contents==


''The Release Policy typically contains the following information:''
''The Release Policy typically contains the following information:''
Line 28: Line 33:
<p>&nbsp;</p>
<p>&nbsp;</p>


===== Release identification =====
====Release identification====
(Release identification, numbering and naming conventions)
(Release identification, numbering and naming conventions)


===== Requirements =====
====Requirements====
(Requirement that only software from the DML may be included in Releases)
(Requirement that only software from the DML may be included in Releases)


===== Release levels =====
====Release levels====
For each release level, e.g. major, minor, emergency releases:
For each release level, e.g. major, minor, emergency releases:
# Definition of release level
# Definition of release level
# Expected frequency
# 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)
# 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 [[Change Management#ITIL Change|Changes]] into [[Release and Deployment Management#Release|Releases]]
# Approach and guidelines for grouping [[Change Management#ITIL-Change|Changes]] into [[Release and Deployment Management#Release|Releases]]
# Planning and documentation requirements, e.g.  
# Planning and documentation requirements, e.g.  
## Minor Release deployment uses the simpler [[Change Management#Minor Change Deployment ITIL|Minor Change process]] and is documented in [[Release and Deployment Management#Release Record|Release Records]] and [[Checklist Change Record|Change Records]]
## Minor Release deployment uses the simpler [[Change Management#Minor-Change-Deployment-ITIL|Minor Change Deployment process]] and is documented in [[Release and Deployment Management#Release Record|Release Records]] and [[Checklist Change Record|Change Records]]
## Major Release deployment requires setting up a formal project with full documentation
## Major Release deployment requires setting up a formal project with full documentation
## Emergency Release deployment requires authorization by [[Roles within ITIL V3#Emergency Change Advisory Board (ECAB)|ECAB]] and is planned, coordinated and documented by a [[Roles within ITIL V3#Major Incident Team|Major Incident Team]]
## Emergency Release deployment requires authorization by [[ITIL Roles#Emergency Change Advisory Board (ECAB)|ECAB]] and is planned, coordinated and documented by a [[ITIL Roles#Major Incident Team|Major Incident Team]]


===== Guidelines for different approaches to Release deployment =====
====Guidelines for different approaches to Release deployment====
What are the specific conditions which make a certain approach the preferred option, e.g.
What are the specific conditions which make a certain approach the preferred option, e.g.
# "Big-bang" vs. phased deployment
# "Big-bang" vs. phased deployment
Line 51: Line 56:
# Automated vs. manual deployment
# Automated vs. manual deployment


===== Constraints for Release 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 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 [[Checklist SLA OLA|Service Level and Operational Level Agreements]]
# Service-specific Release deployment constraints as defined in the [[Checklist SLA OLA|Service Level and Operational Level Agreements]]
Line 66: Line 71:
## …
## …


===== Preferred mechanisms =====
====Preferred mechanisms====
(Preferred mechanisms to automate the deployment of Releases)
(Preferred mechanisms to automate the deployment of Releases)


<p>&nbsp;</p>
<p>&nbsp;</p>
<html><a rel="author" href="https://plus.google.com/111925560448291102517"><img style="margin:0px 0px 0px 0px;" src="/skins/Vector/images/itpm/bookmarking/gplus.png" width="16" height="16" title="By: Stefan Kempter | Profile on Google+" alt="Author: Stefan Kempter, IT Process Maps GbR" /></a></html>


<!-- This page is assigned to the following categories: -->
<!-- This page is assigned to the following categories: -->

Revision as of 16:29, 3 August 2013

Checklist Release Policy - Template Release Policy
Checklist Release Policy - Template Release Policy


 

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:

  1. Definition of release level
  2. Expected frequency
  3. 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)
  4. Approach and guidelines for grouping Changes into Releases
  5. Planning and documentation requirements, e.g.
    1. Minor Release deployment uses the simpler Minor Change Deployment process and is documented in Release Records and Change Records
    2. Major Release deployment requires setting up a formal project with full documentation
    3. 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.

  1. "Big-bang" vs. phased deployment
  2. "Push" vs. "pull" deployment
  3. 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.

  1. Service-specific Release deployment constraints as defined in the Service Level and Operational Level Agreements
    1. Service A
      1. Allowed frequency of new releases according to Release type
      2. Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
    2. Service B
  2. Release deployment constraints for systems, applications and other components supporting the above services
    1. System A
      1. Allowed frequency of new releases according to Release type
      2. Release windows and constraints (e.g. Saturday 01:00 – 04:00, not in December)
    2. System B

Preferred mechanisms

(Preferred mechanisms to automate the deployment of Releases)