ITSM Series #4: Release Management

THE ITSM SERIES

1. Incident Management
2. Problem Management
3. Change Management
4. Release Management
5. Service Level Management
6. Service Request Fulfilment
7. …

When reading ITILversion 2 you could clearly see software distribution stamped across the whole release management process. Version 3 release management aims to be more than that. Its purpose seems to have grown to be the transition motor. But in my opinion, the release management process is still a mixture of sound project management (ITIL v3 is extremely ignorant on project management interfaces), the software release cycle and deployment and some management of change (not change management). If you thumb through the ITIL v3 documentation you will not find a precise goal of release (and deployment) management.

The ISO 20000 specification contains a short summary of the objective of release management:

Objective: To deliver, distribute and track one or more changes in a release into the live environment.

The emphasis is added by me. The version with the phrase “in a release” comes from the part 1 of the specification, while part 2 (the code of practice) contains the objective without the word release.

A while ago I had some high hopes on the then still forthcoming ITIL v3 release management. They were not fulfilled as I would have like it to be. So I will try to define what I would like to see in release management.

Goal of Release Management

Release management coordinates and verifies the introduction of new or updated items into the live IT environment. It controls the roll-out of these items starting from build and/or acquisition to hand over to production.

Proper release management controls the variety of items used in your IT environment.

In my opinion, everything that has not been used in your IT environment should undergo the release management process. The exact scope of this of course depends on your own risk and security requirements. For some organisations a minor patch to an application needs to be regarded in full detail, others will be happy when every major software version is under control. The same is true for services and hardware (e.g. a new server model versus a new hard disk size/version).

The Principles of Release Management

1. Define release units & scope

   What is the contents of each individual release? Define this in cooperation with your service catalog/portfolio and service level management. Define release units for your services and also for your internal environment.

2. Define your release policy

   Define one general release policy, which is flexible enough to handle the different rate of change vs. stability requirements your organisation needs. Then define the release policy for each individual release unit. Never assume there is only one type of release policy requirement for all release units.

   A too strict a policy

   I remember one organisation that applied a single policy one release management, which contained 2 major releases each year, no minor releases and individually created patches without timing restrictions. This was OK for their central services, but it wrought havoc with all the other services and internal environments. This resulted in an enormous flood of individual patches that were not implemented in releases. Release management was having a negative impact on the quality of building and implementing changes.

3. Define release and deployment models

   Not every release unit can be deployed using the same plan and methods. Define models that allow a customizationof the way your deployment works. Many people think of deployment as a software roll-out. Deployment can also be the roll-out of upgraded hardware. If you have defined for example a “Basic Midrange Windows Server”, you may upgrade the hardware platform at a given point in time. All new “Basic Midrange Windows Servers” will receive the new hardware and existing servers will be upgraded according to the release policy, which should be based upon your hardware refresh agreement or plans.

4. Align release management with IT architecture management

   If release management is the gate through which all new things have to go, it is the most important interface for your IT architects.

5. Release management defines CI models in the CMDB

   In a good CMDB (maybe SKMS?) you have a model for each CI. This model defines what the CI is and contains all the general information that is common amongst all the instances of this model. This data needs to come from the release management process.

6. Define your project management interface

   In many IT shops every larger modification of the current status is a project. I do envision a time when the number of projects will decrease, because many of the modifications will be handled in processes. But this a far future. In the mean time you have to make sure that projects will not bypass your release management process.

Make sure your goal and principles for release management are well understood. It is far too easy to confuse change- and release management and it is your task make the distinction clear. The most common distinction unfortunately is a bad one. Release is often driven by the development side, while change management is driven by the production side. That should not be the case. Both are driven by transition side!

Activities of Release Management

It is quite hard to find the official trigger for release management to start in the ITIL(r) documentation. I would propose that every time a change is requested that includes an up to now unknown object (unavailable piece of software, new service requirement, new hardware type, etc.) release management is triggered. Additionally the deployment activities may be triggered for known items, if there is a new deployment need (e.g. new location to be setup).

1. Release Planning
   Define your parameters for your upcoming release. Make sure you define the most important of the magic triangle (time – completeness – budget) at this stage. If you target a dedicated date for final roll-out, you may be more variable on the exact content of your release or your budget will be flexible (usually not the preferred option). The release management planing activity is covering the same grounds as most project management methods do on planning a release project. So my advice is to leverage what you have and integrate release into project management standards, if available. Remember to include requirement engineering, build/acquisition, test (and test design), training, pilot, deployment and financial management criteria in your plans.
2. Preparation of Build & Test
   The new or updated service design (service design package, SDP) should be made available. This is the task of service design, but release management has to wait for them to complete. This is also the place where transition-, release- and deployment criteria should be added to the service design at latest. This step should include defining the CI types and models your new release will be made from within the configuration management system.
3. Build & Test
   Build your release package and start testing against the v-model (every level of design of a service has corresponding tests assigned, highest level is designed first but tested last, lowest level designed last, tested first). Make sure to also test your deployment process as realistically as possible. As an example, if you expect to update software at the client level, try to update in a normal office network, not an empty dedicated testing network. If the current release is a self developed application, make sure to have separate teams in place to do development, build and testing.
4. Plan & Prepare Deployment
   Some may notice that I list this activity earlier as in the ITIL(r) v3 books. This is because a pilot to be also a pilot for your deployment and this requires you to have plans in place when your pilot should start. This
5. Service Testing & Pilot
   Often seen as the highest version of the tests. Here you have to make sure that you can meet your service value, so you test for utility (the previous phase tests functionality, which is slightly different) and for warranty. You should test your serviceability here as well. Try to open an incident at the service desk, request some service requests and recover your service from disaster.
6. Transfer, Deployment, Go Live & Phase Out
   This is where your service enters the big stage. It is very hard to do this right and the failure usually originates from earlier activities. Make sure you do all the required steps right and still be prepared for the unexpected. If you big-bang your service, make sure you have all resources at hand to make it work. If you prefer a phased approach, make sure you cover all the little issues that appear when two different services compete for the same business situation. Make sure the business done within the old and the new service are either completely separate or prepare for interfaces. If you replace an existing service (system, software, whatever) remember to phase out the old versions. Your users may like to cling to the environment the had before and finding out that the old version is used more than the new service after your roll-out is a little embarrassing.
7. Verification
   Make sure your service does what is supposed to be doing. In a big-bang situation with a migration on weekends (quite common) make sure that you have the business within your migration / deployment team to do the final acceptance test and sign off. There may still be things the business does that you are not aware off.
8. Early Life Support
   Make sure that you can handle the added support requirements that any new or drastically changed service will generate. Work together with Service Desk, Incident-, Problem and Change Management to handle the additional load. Interface with Service Level Management to get feedback in early in the life-cycle to see if you are meeting your targets. Basically: Show responsibility.
9. Hand Over
   I added this step as a separate one. It is the milestone in your plan showing that now the full responsibility of production is with the production teams. Do this for every release and have the production team verify that they have the information they need. The service is described, the configuration is registered, event management settings and thresholds are OK, operating procedures are defined, new processes or activities are in place, new categories for incident and problem management are registered within the tools, known errors are forwarded to problem management, new standard change models are available, the service request types are not only described but realized in the proper tool and tested. Warning: This list is not exhaustive.
10. Review and Closure
    As always, check what you have done and learn from it. Formally get acceptance from your client, customers and/or users. In large transitions postpone this to occur after the first service review meeting. Forward findings to your improvement programs (SIP / CSI) or create problem records for the more mundane things.

As stated in the Planning activity, many companies handle the deployment of a new release (of anything) as a project, sometimes as part of the project that produces a new service, sometimes as a seperate one. Try not to reinvent the weel when you are working in such a company. Reuse what you have and cooperate with development procedure owners and project management offices.

Some additional not process orientated activities of release management are:

• Release Policy MaintenanceMake sure your policies fit your requirements. Review them, discuss them with the business and improve.
• Define Release ModelsAs with the other processes, release management can benefit hugely from previous experience. The definition of a project is that it is supposed to be a new endeavour to be undertaken. Luckily in processes we may do something we have done before. What the project template is to project managers, the process model is to process managers. Try to define standards, checklists and job lists required for dedicated types or groups of releases / transitions.
• NamingA big thing in ITIL(r) certification, but to most just one of the things you have to do. Make sure to be consistent.

Attributes of a Release

For release management I can not provide all the required data fields you should record. This is partially due to the difference in size that release management targets. The release and deployment of a new version of WinZIP will require less information than replacing the core transaction system of an international bank with a new in-house developed solution. Make sure that you record the data the steps require in one place and try to integrate with CMS and the Change Management System. Do not expect your software distribution system to hold your primary data on release management, nor solely rely on your project management environment.

Try to reference all requirements, grouped changes, tests, service levels, CIs and CI Models / Types from your release. If possible record the baseline assumptions of your deployment.

Conclusion

My prior blog posts on release management received the most traffic from search engines. That showed me the huge interest in proper release management. Unfortunatly it is still a common topic of misunderstanding and there is no widely accepted school of release mamagement, since ITIL(r) by itself has too many shortcomings (even though my activities are based upon ITIL(r) v3).

Proper release management brings the benefit of doing complex things right the first time and guards you from failed service releases and helps you to handle the issues that will inevitably arise (issues like Nokias OVI Store rollout).