A Beginner’s Guide to ITIL Release Management

A company’s Information Technology (IT) team supports and manages several complex, interrelated systems, and it never stops growing. These systems require regular maintenance and upgrades.

Without established processes, an IT team quickly becomes overwhelmed or forgets a step when executing a key maintenance task, leading to system issues.

I’ve experienced first-hand how IT staff thought they had completed routine maintenance only to discover a mistake because they didn’t possess documentation and tried to work from memory.

The UK government realized the problem in the 1980s, and established a set of standardized IT processes called the Information Technology Infrastructure Library (ITIL). Today, ITIL processes are used across the globe.

One of ITIL’s key processes involves release management. This important component of an IT team’s responsibilities can make or break entire systems. What’s involved in ITIL release management? Let’s take a look.

Overview: What is ITIL release management?

ITIL’s release management process includes these important steps: plan, schedule, and execute any change to an IT system. The change itself is called a release, or release package.

Release management’s process objective is to ensure system users aren’t adversely affected when changes are introduced into the real world, called the production environment, and that the system can continue to achieve its intended function.

Release management is also called release and deployment management. The deployment piece refers to the act of rolling out the release to system users.

Every release requires categorization based on its scope. Consider the following typical categorization structure:

• Major release: When introducing new functionality to an IT system, it’s considered a major release.
• Minor release: A minor release denotes changes to existing system functionality.
• Emergency release: As the name implies, these changes respond to an emergency. The most common scenario is a system failing to perform as intended, called a bug. If the bug prevents normal usage, you have to fix the bug immediately through an emergency release.

In ITIL v3, release management falls under an umbrella called ITIL service transition. The service transition is a component of the overall ITIL life cycle, which breaks up the ITIL processes into a structure defining how you roll out new IT systems to your organization.

Release management vs. change management: What's the difference?

Another ITIL process is change management. This process oversees changes to an IT system. Sound familiar? The difference between change management and release management is that the former acts like a gatekeeper of IT changes while the latter involves the actual implementation of those changes.

In change management, proposed changes undergo careful review to determine if the change is necessary and to understand the implications and expected outcomes.

Once changes are approved as part of the change management process, the IT team switches to the release management process to perform the actual changes.

The ITIL release management process

Six steps encompass the release management process. Each process step is executed in the order outlined below.

Larger IT organizations may employ a release manager, responsible for overseeing releases. The release manager walks the team through each of the six process steps, acting as a project manager to ensure all steps are completed successfully.

Process 1: Release management support

When a change is approved, the first step is to develop guidelines for how to implement the release, who is involved, and how it’s supported to ensure a smooth rollout. These guidelines are documented in the release management support step.

Process 2: Release planning

The release planning process entails planning out the details of the actual release and deployment. Every release includes multiple phases, from making the changes to testing them and rolling them out.

Each phase requires planning. Think of it like a mini project management plan. This plan includes several details related to the release such as the following.

• Who is involved in each phase.
• The extent of the work, such as building test scripts to perform automated testing of the system changes.
• Scheduling when to perform the work and when to roll out the changes to users.
• Creating a risk management plan, which might include runbooks, so IT teams know what to do if something goes wrong.
• Determining any communication for users of the system and when that communication goes out.

Process 3: Release build

This step involves the actual implementation of the approved changes. These changes occur in an environment outside production since they require thorough testing before exposing the changes to users.

If the changes involve software, an in-house team of software developers executes these changes. If changes are related to hardware, someone on the IT team trained on the hardware addresses the changes.

If the software or hardware is owned and operated by an external vendor, that vendor is contacted to help implement the changes.

Process 4: Release deployment

Once changes are ready for rollout to the production environment, testing takes place to ensure the changes don’t compromise the system.

Testing is done in a special test environment. The test cases represent step-by-step procedures for testing the changes and what to look for in the results to validate that the changes are working as designed.

After the changes pass every test case, the IT team introduces the changes to the production environment either automatically or manually. They might use the following methods.

• Big Bang: Changes roll out to all users simultaneously. The changes usually take place at a day and time when users are asleep or otherwise not using the system, such as after work hours or on the weekend. This allows the IT team time to evaluate if the deployment went smoothly and that the changes are working as intended with minimal impact to users.
• Phased approach: Changes go out to a few users to validate the release did not create issues, and then gradually expands to more users, each time checking to confirm no issues exist, until all users get the change.
• Pull approach: Users are invited to update their systems with the changes. An example of this approach is having an app on your smartphone that notifies you of a new update. You then choose whether to install the update.

The release deployment step is also necessary when any training and communication dissemination takes place.

Process 5: Early life support

Despite thorough planning and testing, an IT team can’t know if a release will go smoothly until after it’s introduced to users. That’s why ITIL processes call for the early life support step, where the IT team is in a heightened alert mode for a period of time after a release goes live to address issues quickly.

In IT, the term for a technical issue is "incident." Addressing incidents as they crop up is called incident management.

An IT team usually includes a technical support group for users called the help desk. The help desk acts as the first line of defense in a release, addressing any incidents that crop up.

If they can’t resolve the problem, they escalate the issue to the appropriate team members. To streamline the technical support process, the team uses IT help desk software designed to track incidents and user requests through a ticketing system.

Process 6: Release closure

The release closure process, as its name suggests, wraps up the release management process. This occurs after the outstanding post-launch issues, if any, are resolved.

As part of this process, you must confirm all impacted systems are properly updated and configured to accommodate the changes, and any required documentation is completed, including a list of the incidents that occurred after the launch.

This documentation is used to evaluate how the team can improve for the next release.

Final advice about ITIL release management

A robust IT release management process is a must. How else can you ensure changes are introduced smoothly and with minimal disruption to users?

Depending on your IT changes, you can automate portions of the release management process. I recommend you introduce automation to the testing portion for the sake of efficiency, accuracy, and thoroughness.

With the ITIL release management process defined and executed with every release, you’ll find IT rollouts occur with less stress and happier users.