Blogs

2 min read

All About Release Management...Version 1.0

Sep 7, 2009 11:00:00 AM

ITIL’s Release Management process bears a striking resemblance to ITIL Change Management—in fact, one could fairly consider Release Management to be a directly supportive process to Change Management. Release Management focuses on the practical need for organized coordination in the change process. It’s meant to ensure that changes are implemented in accordance to business needs and concurrent IT Service Management processes.

Release Management more specifically applies to changes to a “live” environment—that is, a working software or hardware environment (a word processor, email interface, software application, etc) that’s active, being used internally or externally. Release management protects these live environments by regulating the release of new configuration items; it uses the ITIL framework to control and monitor the flow of upgrades into live environments, where each upgrade is considered a “release.”

To more clearly illustrate this concept, consider these three levels of releases to a live environment—using the fictional email service “Mockingbird Version 1.0″ as an example:

  • Major Releases introduce completely new functions to a service, drastically improving the service’s capabilities. Major Releases advance the version number by a full numerical increment—for example, Mockingbird Version 1.0 advances to Mockingbird Version 2.0.
  • Minor Releases introduce fixes for known problems into the baseline technology of a service. Such changes would reflect themselves numerically by advancing the version number of a service by the first decimal place—for example, Mockingbird Version 2.0 advances to Mockingbird Version 2.1.
  • Emergency Releases introduce quick (and at least temporary) fixes to repair unexpected problems that interrupt critical services. These changes advance a version number by the second decimal place—for example, Mockingbird Version 2.1 advances to Mockingbird Version 2.1.1.

It’s best to consider each release as a separately-deployed part of the service, the progression of which should look like this:

  • Planning
  • Building
  • Testing
  • Deploying

ITIL clearly describes two “levels” of Release Management in its book:

  • Service Design (higher level)
  • Release and Deployment Management (lower level)

The Service Design level should handle the framing and building of the release solution, while ITIL suggests the release project stages listed above should be handled by the lower level and should involve a project team, scope, design, and plan of its own. The Release and Deployment Management level literally drives the solution’s release, but only because of the sound development and planning by the higher level—meaning it is almost impossible to achieve lower level success without a solid understanding of the higher level.

We hope this blog provides you with a basic overview of Release Management. It’s sometimes difficult to explain ITIL concepts without using laymen’s terms– from our experience consulting companies on their use of ITIL, a basic overview is an essential foundation for understanding the application of ITIL principles into your business.

Would you like more from us? Contact us here.

Webinars

Case Studies

Blog