Release workflow

The Release Coordinator (or another role entitled to create a new release, such as a Change Coordinator or Incident Analyst) logs a release. As soon as the release is logged it is automatically queued for evaluation by the Release Coordinator.

Next phase: Evaluate

The Release Coordinator checks the information provided - including the model - performs an initial analysis, identifies the necessary changes, and ensures they are part of the release by creating or linking them.

If the decision is to move on with the release, the Release Coordinator transitions it manually to the Plan and design phase.

If not, the release is canceled, and the Release Coordinator manually transitions the release to the Abandon phase.

Next phase: Plan and design or Abandon

The Release Coordinator analyzes the release based on the included changes, plans the resources and tasks required, and reviews, revises, and updates the schedule as necessary.

If the decision is to move on with the release, the Release Coordinator manually transitions it to the Build and test phase

If not, the release is canceled, and the Release Coordinator manually transitions it to the Abandon phase.

Next phase: Build and test or Abandon

In this phase, the implementation and back out plans for the included changes are built and tested.  Release specific plans, such as training plans, are also created.

If the decision is to move on with the release, the Release Coordinator manually transitions it to the Approve deployment phase

Alternatively, the Release Coordinator can cancel the release by manually transitioning it to the Abandon phase, or go back to the Plan and design phase for further planning and elaboration.

Next phase: Approve deployment or Abandon

In this phase, the relevant analyst checks the proposed timing and content of the release, the relative time for the contained changes, validates that all changes have been approved, and confirms that all resources are aligned to execute the contained changes.

Once approved, the release automatically transitions on to the Deploy phase, or back to the Build and test phase, depending on the information provided by the Release Coordinator.

Alternatively, the Release Coordinator can cancel the release by manually transitioning it to the Abandon phase.

Next phase: Deploy, back to Build and test, or Abandon

The changes are implemented according to the implementation plan, with all release tasks completed. In other words, before, during, and after the change implementations, any necessary release specific activities are done. Then the Release Coordinator manually transitions the release to the Early life support phase.

If the execution fails, the Release Coordinator manually transitions the change to the Remediate phase.

Alternatively, the Release Coordinator can cancel the release by manually transitioning it to the Abandon phase.

Next phase: Early life support, Remediate, or Abandon

The remediation plan is implemented.

Next phase: Review

In this phase, the Release Coordinator and relevant IT stakeholders (such as the service owner, technical staff, and so on) monitor the release, resolve problems, and implement improvements to help stabilize the release.

Next phase: Review

The Release Coordinator and relevant IT stakeholders review the result of the release, compare the actual and proposed implementation, and decide whether to create a release model. The release is manually transitioned to the Closed phase.

Next phase: Closed

The release is closed.

Service Management does not allow you to delete release records. A release that is not implemented is classified as Abandoned. It is inactive and not implemented.