deployment-strategies

Topics in the source

• Deployment strategies
• 1. Separate deploy from release
• 2. Choose the strategy the risk warrants
• 3. Make rollback the first thing you test
• 4. Make the database change independent of the code change
• 5. Define promotion and abort before you start
• 6. Manage flag debt deliberately
• Report

Every deployment strategy is a way of buying information before you are fully committed. They differ in what they cost and how much they tell you. The question that decides everything: how quickly can you undo it, and what does undo not cover? A strategy without a tested rollback is not a strategy. The most useful idea here, and the one that unlocks the rest. Deploying is shipping the code; releasing is turning the behaviour on. When they are the same event, every deploy is risky and every rollback is a deploy. Split them with a flag, and you can ship code continuously, turn a feature on for one account, and turn it off in seconds without a build. Done when: you can change behaviour without shipping code. | Strategy | Buys you | Costs | | --- | --- | --- | | Rolling | Simple, no extra capacity | Both versions live at once; slow rollback | | Blue-green | Instant switch and instant rollback | Double capacity during the switch | | Canary | Real traffic on a small blast radius | Needs traffic splitting and per-version metrics | | Feature flag | Per-user control, instant off | Flag debt, and both code paths must work | | Shadow | Zero risk, real inputs | No user-visible result; needs re

This is an excerpt. Refer to the complete source and its current requirements.