Managing interaction between change and release management

A release always produces changes to one or more configuration items (CIs), such as software installations, servers, and client workstations. CI changes are managed through the change management process. Therefore, a release must be associated with one or more approved changes that are scheduled in your data center. A change that is associated with a release cannot be completed until the release is completed.

About this task

So that you can manage the interactions between change management and release management, their key features are tightly integrated.

Typically, simple changes are not associated with releases. For complex changes, such as large-scale software deployments that affect multiple application servers and client workstations, major business application updates, and major changes to the network infrastructure, the release process is required to ensure an ordered, efficient, auditable change.

Multiple changes can be associated with a release, but a change cannot be associated with more than one release.

Several operations are used to associate changes with a release. For example, you can create a change from within a release to handle CI changes that your release is planned to make. Additionally, a Change Manager can add approved changes to a release from within the Changes application; this operation generates an Add Change to Release request. An Add Change to Release request can be accepted either within the Releases application or from the ISM Request application. The request can also be rejected, and changes can be removed from a release.

You can modify the business logic that drives the acceptance of a change into a release, and you can also configure e-mail notifications that are sent along the way to Change and Release Owners, Task owners, and other involved users.

The following topics provide instructions for performing the operations that are used to associate changes with a release.