Predecessors/Before You Begin

Release and deployment management is very closely related to change management, and arguably a successor to a good change management program.  Please make sure you understand change management before diving into release management.

Release and Deployment Management

Release and deployment management is about defining a lifecycle for certain types of changes (e.g. how changes to server operating systems are built, tested, and deployed), and it's about grouping changes together (e.g. all the changes for server operating systems occur at the same time).

For example, Unilever said in their 2007 itSMFusion presentation that their desktop changes are scheduled so that

• T-2 weeks to go-live: change is in development
• T-1 week to go-live: change is in test, running on specific test users' computers
• Go-live, scheduled the first Sunday of every month: changes applied in production

This process makes it easy to understand how changes are applied to desktops, ensures that changes are tested, and ensures that time and resources are available for the changes.  The testing group knows that if their desktop is messed up in the last week of a month, there is probably something wrong with the next load.

Often project management takes on a "release management" role of making sure that the schedule for production changes is understood, that changes are tested, etc.  With a strong release management process, project management can trust their changes to release management and then release management can coordinate changes from multiple projects, and relieve some of the effort from project managers.

University-specific risks

It is tempting to begin release management with software development projects, as release management defines a standard lifecycle and people are often familiar with their software development lifecycle.  However, it's better to focus on areas where

• lots of small, low-priority changes are needed
• there is little definition as to how changes can be made in production

These criteria could apply to your software development lifecycle, but more likely apply to other types of changes e.g. OS patches or vendor-provided application upgrades.  You will get much more value for your effort if you start with problem areas, rather than trying to re-define your existing (and working) processes under the title "release management."

Release management is a good time to take care of the "under-the-radar" issues, that need to happen but don't get much attention, to build wins for release management.

"Release management" is not a tool issue.  You don't buy a tool and suddenly have release management.

Your release management process needs to work especially well with your change management process.

Videos, Photos, and Presentations

Really long video from Cambridge about release management in open-source software: