Checklist Release Policy: Difference between revisions

From IT Process Wiki
No edit summary
No edit summary
Line 13: Line 13:
<meta property="og:image:width" content="519" />
<meta property="og:image:width" content="519" />
<meta property="og:image:height" content="778" />
<meta property="og:image:height" content="778" />
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@itprocessmaps">
<meta name="twitter:creator" content="@itprocessmaps">
<meta name="twitter:title" content="Checklist Release Policy | IT Process Wiki">
<meta name="twitter:description" content="The 'Release Policy' represents a set of rules for deploying releases into the live operational environment, ...">
<meta name="twitter:image" content="https://wiki.en.it-processmaps.com/images/4/49/Release-policy.jpg">
<meta name="twitter:image:alt" content="Free ITIL Release Policy template. Definition and data flow.">
<link href="https://plus.google.com/108613479011811316823/posts" rel="publisher" />
<link href="https://plus.google.com/108613479011811316823/posts" rel="publisher" />
</itpmch>
</itpmch>

Revision as of 10:38, 8 September 2017

share this pageshare this page on LinkedInshare this page on Twitter
share this page
Checklist Release Policy - Template Release Policy
Checklist Release Policy - Template Release Policy


Definition: 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.

ITIL Process: ITIL Service Transition - Release and Deployment Management

Checklist Category: Templates ITIL 2011

 

Release Policy - Contents

Checklist Release Policy
Fig. 1: ITIL Release Policy: Definition and information flow.

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)

 

Notes

Is based on: Checklist 'Release Policy' from the ITIL Process Map

By:  Stefan Kempter , IT Process Maps.

 

 ›  ›  ›  ›