Deployment Practice

• · DPL1 — Deployments to production use a progressive rollout strategy (canary or rolling) proportional to risk, not a single instant full-traffic cutover for significant changes.
• · DPL2 — Database schema changes are backward-compatible with the previous application version during rollout (expand-contract pattern), so a mid-deploy state never breaks.
• · DPL3 — Rollback is tested and fast — a previous release can be restored in minutes, verified periodically, not assumed to work.
• · DPL4 — Deployment includes automated post-deploy health verification (smoke tests, key metric checks) before considering the release complete.
• · DPL5 — Data migrations are reversible or have a documented, tested reversal plan before running against production.

• · A schema migration that both adds a new column and requires the old one removed in the same deploy → split into expand (add new, deploy, backfill) then contract (remove old, deploy) phases.
• · No smoke test runs automatically after deploy → add one checking the top 2-3 critical endpoints before calling the release "done."
• · Rollback procedure last tested "a while ago" → test it again before it's needed under pressure.
• · A risky deploy going out at 5pm Friday with no one watching → reschedule or ensure an owner is actively monitoring through stabilization.
• · 100% traffic cutover for a significant behavior change → consider canary/rolling instead, even if it adds a few minutes to the rollout.

• · Big-bang cutover — 100% instant traffic switch for a significant change, no canary, all-or-nothing risk.
• · Breaking migration in one deploy — adding a NOT NULL column and removing the old one simultaneously, guaranteed to break if the deploy is even briefly mid-rollout with mixed application versions.
• · Untested rollback — a rollback procedure that's never actually been run, discovered broken during a real incident when it's needed most.
• · Friday-evening risky deploy — a major schema/infra change shipped right before everyone leaves for the weekend, no one watching when it breaks.
• · No post-deploy verification — deploying and immediately moving on, discovering the release broke something only when a user reports it hours later.

• [ ] Progressive rollout (canary/rolling) used for non-trivial changes. (DPL-E1)
• [ ] Schema migrations follow expand-contract, no breaking mid-rollout state. (DPL-E2)
• [ ] Rollback tested periodically, not assumed. (DPL-E3)
• [ ] Post-deploy smoke tests verify critical paths. (DPL-E4)
• [ ] Data migrations have a tested/documented reversal path. (DPL-E5)
• [ ] High-risk deploys scheduled with an owner actively monitoring. (DPL-E6)

• Continuous Delivery

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• bookContinuous DeliveryJez Humble & David Farley. Addison-Wesley
• blogDatabase Refactoring / Expand-Contract patternMartin Fowler