Production Change Control Policy
Standardize how production changes are proposed, approved, executed, and verified.
Objective
Standardize how production changes are proposed, approved, executed, and verified.
Approval Model
- Single approval authority: owner (explicit approval or direct manual execution by owner)
- No production docker compose action should run without explicit owner approval.
Change Classes
- Standard: low-risk, repeatable, documented runbook available
- Significant: medium-risk with service impact potential
- Emergency: time-critical changes under active incident
Required Change Record
Before execution, each production change must include:
- change summary
- affected stacks/services
- risk assessment and expected impact
- rollback plan
- validation plan
- owner approval reference
Pre-Execution Gate
- Confirm backups or rollback checkpoints for stateful services.
- Confirm monitoring/health checks are available for post-change validation.
- Confirm dependencies and maintenance window alignment.
Execution Rules
- Use approved runbooks from repository docs.
- Minimize blast radius by rolling one component at a time where possible.
- Record start/end times and deviations from plan.
Post-Execution Validation
- Validate route, health, and auth behavior from expected access paths.
- Confirm no unintended public exposure after change.
- Confirm logs and alerts are normal.
- Mark result as success, partial, or rollback.
Emergency Change Flow
- Allow immediate containment when active risk is present.
- Record owner approval as soon as possible if action is time-critical.
- Convert emergency actions into permanent tracked follow-up items.
Documentation Sync Rule
After accepted or executed changes, update these files as applicable:
docs/state/accepted-suggestions.mdxdocs/state/requirements.mdxdocs/state/already-implemented.mdx(server-completed items only)docs/state/next-steps.mdx