- How to Define a Process
- Standard ITIL Process Activities
- Change Management and Operations
- Release Management and the Project Life Cycle
- Looking Ahead
This chapter is from the book
This chapter is from the book
This chapter is from the book
Release Management and the Project Life Cycle
Almost every organization has a change management process, but very few have a specifically named and defined release management process. Unless your organization does a lot of software development, you may not have given much thought to release management. Whereas many of the issues described earlier for change management are familiar to you, those described here for release management may cover new ground. This doesn't, of course, make the issues any less important. You will soon discover that release management is every bit as important as change management, and that together change and release management form the core of how new services get introduced to your environment. This section covers the highest-level process issues in release management.
Release Unit Identification
Just as change management begins with defining which activities will require a change record, release management begins with documenting which components will be released simultaneously. ITIL defines a release unit as the set of components that get upgraded, installed, or changed all at the same time. As a simple example, often the next version of a business application requires new versions of middleware software products. This means that the application and the middleware form a release unit, because they are deployed at the same time.
There are many reasons to form a release unit. Vendor prerequisites might determine release units, as in the business application example. Sometimes purchasing considerations define a release unit, such as when new PCs come with a new operating system already installed. The PC and operating system become a single release unit. Project management often determines release units based on an analysis of the risks versus rewards of implementing multiple parts of a complete project at the same time. In some cases, there are valid architectural reasons to create a release unit out of multiple components. Whatever the reason, when your organization determines that multiple components should be joined for the sake of introducing a new service, you have defined a release unit.
You should try to create release units along consistent lines. Some people find that releases based on business application environments work well. They change out the operating system, middleware, and business application all at the same time as part of the release management process. Others like to create release units based on technology types, creating a desktop PC release consisting of bundled hardware, operating system, and standard software.
It takes a great deal of communication to create a release unit policy. It would be extremely difficult to identify in advance every situation that might cause a release unit to be formed, so you should focus instead on creating some guidelines that help people decide how to best create them. Work with the various deployment teams in your organization to understand and document these guidelines. Ultimately, deploying two or more things at once is always more risky than deploying only one component at a time, but most organizations find those risks worth taking in certain circumstances. Understand what those circumstances are, and document them as part of your release unit policy.
Release Policies
As soon as you understand release units, you can begin defining some general policies concerning release management. Most organizations find it useful to define a policy about how many releases should be produced per year. This policy helps in IT planning activities, because the organization can lay out the annual plans based on how many release units are active and how many releases each of those units will go through per the policy.
Of course, the number of releases per year will most likely depend on the number and type of components that make up the release. If a significant component of your release package is a software product, you won't be able to create releases more often than the software publisher produces releases. If you are bundling hardware refresh into your releases, the release cycle will depend on how often you choose to refresh your hardware. This will lead to a release policy that determines the frequency of releases based on the kinds of components that will make up the release unit.
An alternative to defining numbers of releases is to constrain the size of releases. You can constrain the size by either project budget or hours expended. For example, your policy might say that each release will require less than 2,000 hours of planning, testing, and deployment. This kind of policy ensures that your organization doesn't attempt huge projects that have correspondingly large risks. Limits of this kind will force projects to break their desired results into multiple releases and allow your organization to stop those releases if the cost or risk of achieving all the benefits appears too high.
Regardless of how you choose to define release policies, they are worthwhile to define. Release policies help create consistency in your organization and tend to create deployment projects that are roughly the same scope or size. This consistency helps you better evaluate successful and failed projects, and you can tune your release policies to optimize the size and scope of the projects for your organization. By creating fewer, larger releases, you will get larger projects that run longer, consume more resources, and return more value. By optimizing toward smaller releases, you wind up with small projects that generally return value more quickly.
Releases or Bundled Changes
Somewhere in your definition of the release management process, confusion is likely to arise about the difference between a release and a set of bundled changes. Although these may seem similar on the surface, they are really quite different.
Normally changes are bundled as a scheduling tool. There might be three different activities that all require the mainframe to be restarted, so rather than restarting the mainframe three separate times, these changes are bundled. All three things are done, the mainframe is restarted, and the changes are marked as complete. This is a convenient grouping of changes that happens one time because the schedule works out that way.
A release, on the other hand, is determined by a set of permanent policies that define release units and release frequency. The components of the release are related to one another by technology or business purpose, and the relationship is permanent rather than transitory.
A release might be deployed as a single change, or as a group of changes that are related to one another. For example, if the release includes an operating system and a middleware product, these might be deployed through two changes that take place on consecutive weekends. If the first change fails, the second change cannot happen, because the release control process ties the two together into a single release, and the release cannot be only partially deployed. In other words, a release can result in a group of bundled changes, but there are perfectly legitimate reasons to bundle changes that have nothing to do with release management.
Support and the End-of-Life Cycle
One of the key benefits of release management is that it causes an organization to think about the entire life cycle of a release unit. Many organizations have no policies or, at best, ineffective policies, around the end of support. I've been involved with companies that had six or even seven separate versions of an application all being supported because they just didn't know how to sunset that application. A key part of the release management process definition should be a policy surrounding the end of life for your releases.
Normally a release reaches end of life because a newer release replaces it. It might take some time to fully deploy the new release, and during this time both releases will be part of the supported environment. Your policies should take this situation into account and define how long the older versions will be supported. Your policy might insist that each release deployment project include the costs of supporting and then removing the old release.
In addition to the end of any specific release, your policy should consider how to define the end of a release unit. For example, imagine that your release unit consists of a payroll application, web server, database middleware, and common server operating system. You can define new releases as the middleware changes or new versions of the application become available, and each release retires the previous release. But you should also consider when you will move to a new payroll application that requires different infrastructure and thus creates a new release unit. If you make it an organizational policy to include this kind of long-range planning in release management, you will be able to forecast the large number of resources required to actually launch such a large project. This kind of complete life-cycle thinking is one of the hallmarks of a mature release management process.