Change review

A release change has a service, summary, risk, scheduled start and end, rollback plan and status. The release manager prepares those details before the change enters review. A date on its own does not explain the operational decision. The reviewer needs to know which service will change, what risk is accepted and what the team will do if implementation needs to be reversed.

For example, a service version may need a maintenance window. The release manager sets the planned window on the change and describes the rollback plan. The CAB reviewer looks at the change and records a decision in a CAB review record. Its decision can be Pending, Approve, Reject or Defer, with a reason and reviewer. The decision belongs to the review record; the release manager follows it when moving the change forward.

• Prepare. Draft changes collect the service, risk, window and rollback plan.
• Decide. The CAB reviewer records a decision with a meeting date and reason.
• Hand off. Approved work can move into implementation, where deployment tracking begins.

Define who can submit a change, who records the CAB decision and who updates the change state after that decision. Agree how risk is assigned and what a usable rollback plan must explain. The scheduled start and end should describe the intended work window so the team can compare overlapping service changes. Reviewers should be able to see the affected service before making their decision.

A deferred decision needs a reason that tells the release manager what to prepare next. A rejection should remain visible in the review history. Approval authorizes the planned release change; it is not evidence that a deployment succeeded. Once the change reaches implementation, the deployment record carries the environment, version and observed outcome.

Create a draft change against a service with a planned window. Raise it for review and verify that it appears in Changes In Review. Have the CAB reviewer record a decision and reason, then check that the change state reflects the accepted decision. A rejected change should not be treated as ready for implementation. An approved change should retain its scheduled window and rollback plan as the delivery team takes over.

During the rehearsal, open the Change Schedule and compare the planned window with other approved or implementing work. After implementation starts, inspect the pending deployment and confirm which service and environment it concerns. If the release is reversed, preserve the outcome in the deployment and change records so a later reviewer can explain what happened.

• Changes In Review — Changes awaiting a CAB decision, with risk and planned window visible.
• Change Schedule — Approved and implementing work placed against scheduled start and end.
• Change Board — The working change states for review and handoff discussions.

The release change process covers the decision and implementation handoff. Continue with deployment outcome to review the result.