Blog

Any software development manager knows or quickly discovers the vital importance of keeping releases under control.

The development team and the support people need to know what features each release has, what issues were addressed, and what concerns are still open. Customer support needs to know the support status of each release from beta to end of life. Anything less leads to confusion and frustration.

ITIL, the Information Technology Infrastructure Library, provides a detailed set of steps for IT release management. Some organizations might find the explicit implementation of every step too much for their needs, but anyone setting up a release process should study the ITL guidelines and adapt them to the organization’s needs.

The steps in ITIL release management

The 20 steps that ITIL uses to describe the process can be grouped into several larger steps, giving a less intimidating overview.

ITIL prescribes a Configuration Management Database, or CMDB. It can take any number of forms, but a repository of information about processes and components is of great value in managing the release process. The CMDB needs to be updated with each release.

Release preparation

Each release requires a plan that gives its goals and methods. It will have a release manager, who may be the same as the project manager.

The main point may be to add a list of features, improve performance, update the user interface, or fix problems. It needs to set a schedule and specify who will sign off on the changes before the release manager makes the final call. Flexibility is necessary, but managers need to know what they’re aiming for. The set of goals has to include not just code but documentation.

The release can be major or minor. It should be numbered according to a consistent plan.

Building and testing

The build process should follow procedures that make it clear what goes into the release, including all supporting components and their versions. The release candidate needs to be thoroughly tested. If any problems show up, they go back to the developers. The release manager verifies that all feature requests and problem reports reach an acceptable state before the candidate can move on.

Conducting the release

Deploying a release is a complicated process. The transition from the previous version needs to be smooth, and it needs provisions for a rollback in case anything goes wrong. A risk assessment should consider how the changes will affect the users and how problematic a failed release and rollback would be.

The stakeholders need to be informed so they’re ready for the changes. They should know what will work differently. If the release is deployed to customers and acceptance is optional, they need information on how to decide, including any issues of compatibility and risks in keeping the old version. If it’s an emergency release to fix a critical bug, communicating the need to update is especially important.

The release needs a post-implementation review to ensure that everything went as planned. If significant issues turn up, it could be necessary to roll back.

Closing out

If the release succeeds, then the release ticket and CMDB will be updated. It provides the basis for supporting the new release and updating the status of previous releases. In some cases, the results of the post-implementation review will indicate the need for starting another release cycle.

Sticking to the plan

Following all the steps may appear cumbersome, but managers should resist the temptation to cut corners and rush releases. It’s better to be a little late and produce something that works than to turn out a buggy release.

Vision Helpdesk follows ITIL standards, ensuring you can smoothly integrate customer support with release management. With a good release plan, you can be confident that the only surprises your users encounter are pleasant ones.