Release workflow
This section describes the metaphases and subordinate phases in the life cycle of a release.
The workflow relies on business rules. Rules repeat from one phase to another when the end user can make a change to a field affected by a business rule during that phase. For more information about the out-of-the-box business rules defined for the release workflow, see Release transition rules.
Metaphase: Classification
A Release Coordinator logs a release including selecting a model.
| Phase | Transition |
Description |
|---|---|---|
| Log | Automatic |
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 |
| Evaluate | Manual |
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 |
Metaphase: Planning
The Release Coordinator:
-
Plans the resources and tasks required. Tasks, for example, may include training for IT staff.
-
Reviews, revises, and updates the schedule for changes as necessary.
This includes producing deployment, implementation, and remediation plans, and an implementation and remediation plan for the release itself, in addition to what is required for the included changes.
-
Assesses the release by determining the risk and impact.
-
Reviews the release, and if not satisfied, may cancel it or return it to an earlier phase, as appropriate.
| Phase | Transition |
Description |
|---|---|---|
| Plan and design | Manual |
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 |
| Build and test | Manual |
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 |
| Approve deployment | Automatic or Manual |
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 |
Metaphase: Deployment
The release happens in this phase. The Release Coordinator coordinates and monitors the change implementation.
| Phase | Transition |
Description |
|---|---|---|
| Deploy | Manual |
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 |
| Remediate | Manual |
The remediation plan is implemented. Next phase: Review |
Metaphase: Validation
The Release Coordinator determines whether the release implementation was successful, and reviews the procedure taken for the purposes of process improvement.
| Phase | Transition |
Description |
|---|---|---|
| Early life support | Manual |
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 |
| Review | Manual |
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 |
Metaphase: Done (End)
The Release Coordinator reviews the implemented release and closes the release if it has been successfully implemented.
An unsuccessful release and an abandoned release are also kept in this metaphase.
| Phase | Transition |
Description |
|---|---|---|
| Close | None |
The release is closed. |
| Abandon | None |
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. |
