Release Policy planning (Part 1)
By Laurent Duenas, March 15th 2013
Introduction to Release Policy planning ?
Release policy is a set of rules defining the content of Release Units and the scheduling of all planning, build, and deployment (into the Live environment) operations. The content of Release Unit is based on the type and the size of the update. The frequency of the release update depends mainly on business expectations and on other constraints (as IT department organization, IT vendors’ roadmaps). It defines also naming convention, designs build and integration models, to manage releases in an industrialized way.
“Release management” is usually part of the vocabulary of Design departments or Editors. Integration teams are generally less involved in Release management. They get releases at the end of the chain to deploy them. This implies that in most cases, planning of release evolution (used here in the sense ”version”) is orchestrated by Design departments. As Release team (integration team) is often limited to an implementation role in this field, it deploys on demand, attempting to comply with service commitments, Design team made on its own.
For ITIL, the notion of Release “belongs” to Release as well as Design since it gathers all applicative and infrastructure components which contribute to deliver (an entire or part of) an IT Service. So, most “guarantees” embedded in the version are supported by ITSM processes in which Release Management plays a major role.
This ITIL notion of release (compliant with the definition of an “end-to-end” IT Service vision) does not exist (or practically doesn't) in companies or organizations in general. Only companies delivering integrated systems (hardware + software) share this vision because releases cannot be considered separately.
The Release Policy guarantees stability in order to limit any potential impact on the availability of Services for user and limits any unexpected workload variation for integration teams.
► As the Release mode includes changes complying with a business-approved schedule, it does not risk to disrupt Service availability outside time slots
► As they no longer work on a "on-the-fly" basis, integration teams do not depend any more on development hazards (which, by their nature, depend on business hazards), and thus, have a better control on their workload, their schedules and last but not least, their budgets
Illustration of a planning structured by a Release policy: Delays are managed with industrial methods and do not have impacts on the planning of the next releases, or the organization of teams:
Copyright © 2014 - PRACT Publishing