LEARN. PRACTICE. GROW.Concept and mechanism
A recovery plan needs activation conditions, decision authority, executor, sequence, duration, and validation. Restoring the previous binary may fail when the release also changed schema, data, or external contracts. Assess current state before choosing rollback, a forward correction, or another mitigation. A feature flag may reduce exposure without undoing effects already produced. In EF Core, reverting a commit does not automatically change the database; Down operations generally cannot reconstruct information the migration deleted or transformed. Check compatibility and recovery impact through service-appropriate procedures. An existing backup does not establish that complete recovery fits within the window.
Guided application
In an original exercise, cut-off is 02:00 UTC, recovery takes 35 minutes, and validation takes ten. The latest start is 01:15 UTC under those estimates and without extra margin. Continuing until 01:50 leaves ten minutes for 45 minutes of work. Define that decision point in advance and reassess it if estimates change. In CodeDeploy, rollback creates a new deployment of the previous revision; the mechanism does not automatically reverse every script effect. For example, files created by scripts may remain outside cleanup of installed files. After recovery, confirm operations, consistency, and outstanding work and record the state actually reached. A successful job does not remove the need for functional validation.
02:00 minus 35 recovery minutes and ten validation minutes gives 01:15 UTC.
Common pitfalls
Rollback as universal reversal; backup as guaranteed timing; cut-off without reserved validation.
Related topics: Scope and coordination · Artifacts and traceability · Readiness and authorization
Prepare recovery of the complete state and reserve time to establish the outcome.
Reference: Rollback redeployments and limits on script side effects · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation