31 lines
1.2 KiB
Markdown
31 lines
1.2 KiB
Markdown
# ADR-0033: Promotion plans and rollback snapshots
|
|
|
|
## Status
|
|
|
|
Accepted in M12 on 2026-08-26.
|
|
|
|
## Context
|
|
|
|
Approval alone does not describe blast radius, canary semantics, resource placement, migration or
|
|
restoration. A single-click approval-and-swap cannot be reconciled safely after races or restart.
|
|
|
|
## Decision
|
|
|
|
An approved request permits an immutable PromotionPlan. Execution journals a separate idempotent
|
|
LifecycleOperation and captures an immutable rollback snapshot before activation. Subject versions
|
|
provide compare-and-swap protection, and the database enforces single production-stable deployment.
|
|
Successful canary requires a second explicit review; failures and incomplete restart stages roll back
|
|
conservatively.
|
|
|
|
## Consequences
|
|
|
|
Requester, approver and executor are auditable even for one owner. Plan changes create new plans.
|
|
Failed rollback becomes manual intervention, never false stable. Embedding reindex and schema-breaking
|
|
plans are representable but not auto-executed by M12.
|
|
|
|
## Rejected alternatives
|
|
|
|
- Mutating deployment rows directly: loses intention and recovery state.
|
|
- Automatic promotion after canary: removes the explicit production decision.
|
|
- Reconstructing rollback from current rows: current truth may already be partially changed.
|