Release Management - Apoyar Wiki

Release Management

From Apoyar Wiki

Jump to: navigation, search
  • Mission

The mission of the Release Management process is to ensure that changes are implemented to keep the functionality and service levels of the services aligned with the ever-changing business needs of their customer(s).


  • Description

The Release Management process consists of four procedures.

The first procedure is called "Change Request Handling". It is used by the release managers to review the support requests and problems that have been passed to Release Management.

The second procedure is called "Release Definition". This procedure is used by release managers to organize CAB meetings and by CAB members when they decide which of the change requests that have been collected for CAB review should be fulfilled by the next release. Release managers also use this procedure to split the requirements of releases into logical groups that can be handled efficiently by change coordinators.

The third procedure is called "Business Justification". It is used by the release managers when additional funding needs to be obtained for the implementation of a release.

The fourth procedure is called "Release Coordination". Release managers use this procedure to initiate the implementation of releases and to decide on corrective actions as needed.


    • Change Request Handling

After a change coordinator of a service has passed a change request to the release manager of the service, the release manager reviews the request to gain an understanding of its requirements. The release manager passes the change request back to the change coordinator if it does not require the involvement of Release Management. Only change requests that ask for the implementation of a non-standard change must be handled by Release Management, with the exception of change requests that have been submitted for the prevention or fix of a problem, provided that their implementation:

      • can be coordinated by a single change coordinator,
      • will not cause the functionality of a service to become different, and
      • does not require any additional funding.

If the request does require the involvement of Release Management, the release manager checks to see if it requires CAB approval. The CAB does not need to review the change request if it asks for the implementation of a change to prevent or fix a problem and if this change will not cause the functionality of a service to become different. If CAB approval is required, however, the release manager adds the change request to the list of requests that are waiting to be reviewed during the next meeting of the service's CAB.


    • Release Definition

When the next CAB meeting for a service is due, the release manager of the service sends out the invitations to the service's CAB members. In the invitation, the release manager specifies the deadline until which change requests can be submitted for review during the next CAB meeting. After the change request submission deadline has passed, the release manager finalizes the list of change requests that will be reviewed during the next CAB meeting and sends it to the CAB members so that they can discuss the change requests internally before the meeting.

The finalized list of change requests is reviewed during the meeting. After all change requests have been reviewed, each CAB member lets the release manager know which change requests he/she would like to see rejected and which change requests he/she would like to see included in the next release. A change request is rejected when at least two-thirds of the CAB members agree that it should be rejected. Similarly, a change request is included in the next release when two-thirds or more of the CAB members have asked for it to be included. Change requests that are neither rejected nor included in the next release will be reviewed again during the next CAB meeting. Before closing the CAB meeting, the CAB members agree on the date, time and location of the next CAB meeting.

After the CAB meeting, the release manager ensures that the requesters of the rejected change requests are informed by completing these change requests. Having done this, the release manager publishes the minutes of the CAB meeting and registers the new release. To this release he/she links a change for the coordination of the release and links the change requests that are to be included in the release to this change.

The release manager then reviews these change requests with the change coordinator of the service for which the release is to be implemented and the change coordinators of the supporting services that will also need to be changed. Together they divide the requirements of the different change requests amongst them and they draft a high-level implementation plan that indicates the duration of each change, as well as the dependencies between these changes.


    • Business Justification

If an approved business case is not required for the release, the release manager cancels the business justification work order that is part of the change to which the change requests of the release are linked. On the other hand, if the next release cannot be implemented using the budget(s) already available to the service provider, the release manager prepares a business case to justify the release. Having prepared the business case, the release manager requests approval for the business case to ensure that a budget will be made available for the implementation of the new release.

If the business case was rejected, the release manager adjusts it if this could still get the business case approved. If it is not possible to get the business case approved, the release manager lets the requesters of the release know that the business case for the release has been rejected. If the release was defined by the CAB, the release manager moves the change requests that are linked to the release back to the change that acts as the placeholder for change requests that are to be reviewed during the next CAB meeting. Before closing the release, the release manager also contacts the CAB members to inform them that the business case of their release has been rejected and gives them the option to bring the next CAB meeting forward.


    • Release Coordination

The release manager prepares a document for each change coordinator that details the release requirements that the change coordinator will be responsible for. The release manager sends the requirement documents to the change coordinators and ensures that the requested changes are registered and linked to the release.

When a change coordinator has informed the release manager that one of the release's changes has been completed, the release manager enters a short update in the release.

If the change could not be implemented successfully, the release manager works with the coordinators of the changes that are linked to the release to determine how the (partial) failure of the change implementation affects the overall implementation of the release. If it is still possible to implement one or more additional changes to ensure that all or most requirements of the release are fulfilled, or if one or more additional changes are required to ensure that the rollback of the release is completed, the release manager documents the requirements for the additional change(s) before passing them to the appropriate change coordinator(s).

After the last change that a change coordinator was asked to get implemented for the release has been completed, the release manager ensures that the requesters are informed whether or not their requirements were fulfilled by the release implementation. If the release was defined by the CAB, the release manager moves any change requests which requirements were not fully met back to the change that acts as the placeholder for change requests that are to be reviewed during the next CAB meeting. The release manager also informs the CAB members (if the release was defined by them) and the approvers of the business case (if one had to be prepared for the release).

Having updated the requesters and approvers of the release, the release manager continues by organizing and conducting the post-implementation meeting. During this meeting, the release manager reviews the entire lifecycle of the release with the service provider of the service for which the release was implemented and the change coordinators who coordinated one or more of the release's changes. After the meeting, the release manager publishes the improvement suggestions and decisions that were agreed on by the attendees of the meeting. Finally, the release manager closes the release.

Personal tools