Changes and deployments

A change records its summary, risk, scheduled start and end, rollback plan, service and state. A review row records the meeting date, reviewer, decision and reason. The Change Reviewer decides whether the change can proceed. The Release Operator uses an approved change to schedule implementation and record a deployment outcome for the service. The deployment keeps the service, environment, version, time, rollback reference and state; the team compares it with the change using the shared service and planned versus deployed times. Rollback checks capture the expected and actual result for each checkpoint.

Suppose a release is intended to address recurring memory pressure on a monitored service. The Release Operator drafts the change, names the affected service, sets a risk and records a rollback plan. The Change Reviewer examines the schedule and reason, then approves or rejects the review row. If approved, the operator proceeds with the scheduled implementation. After deployment, the operator records whether the deployment became healthy or failed and reviews a fresh server sample and availability check. A healthy deployment status and observed service health should be checked together before the change is verified.

• Decision. Keep the review row and its reason linked to the change before implementation begins.
• Window. Put the planned start and end on the change so service owners know when to expect work.
• Outcome. Record deployment state and rollback checkpoints after the work, including failures.

Choose who may draft a change and who is an independent reviewer. Define how risk is selected, what must be in the rollback plan and which services need a maintenance window. Agree who may approve a deployment and who verifies the result. A maintenance window provides site and timezone context; it should align with the change schedule when the work is expected to affect availability.

Rehearse an approved release for one service. Ask the Release Operator to record the planned window and rollback plan. The Change Reviewer enters a decision with a reason. The operator implements only after approval, records the deployment and checks the expected service result. Capture a rollback check with an actual result. The Service Owner should compare the decision and schedule with the release result using the shared service and planned versus deployed times, then review the later service check.

Repeat with a rejected decision. The operator should leave the change out of implementation and retain the reason. Then rehearse a failed deployment. The failure remains visible and the rollback record identifies what was checked; it must not be rewritten as a healthy result simply because a later attempt succeeds.

• Changes In Review — Find proposals waiting for a decision.
• Change Schedule — Review approved and implementing changes by window.
• Failed Availability Checks — Inspect service observations after the release.

Follow change review for the decision and service recovery for the post-change check.