Blame
|
1 | # Change Management |
||||||
| 2 | ||||||||
| 3 | Use a proportional process: small reversible changes need less ceremony than migrations or compatibility changes, but every production-affecting change needs an understood verification and rollback path. |
|||||||
| 4 | ||||||||
| 5 | ## Before a change |
|||||||
| 6 | ||||||||
| 7 | Identify the affected product/service, expected behaviour, dependencies, data/config migrations, compatibility impact, validation method and rollback method. For high-risk changes, record an explicit maintenance window and recovery owner outside the wiki if required. |
|||||||
| 8 | ||||||||
| 9 | ## During a change |
|||||||
| 10 | ||||||||
| 11 | Capture the deployed version/commit and avoid mixing unrelated changes into the same recovery boundary. Stop when validation fails rather than stacking further speculative changes over an unknown state. |
|||||||
| 12 | ||||||||
| 13 | ## After a change |
|||||||
| 14 | ||||||||
| 15 | Verify the intended behaviour, record any operator-facing differences, update affected wiki reference pages, and close temporary migration instructions once they are no longer needed. |
|||||||
| 16 | ||||||||
| 17 | For releases, start from [[Templates/Release-Checklist]]. |
|||||||