Deployment Strategies
Recreate, rolling, blue/green, canary, shadow and flags — each with how it works, what it risks, what it costs, and how you get back.
Six ways to replace running code, compared on how they work, what they risk, what they cost, how you get back, and what each is actually for.
The simplest strategy, an outage by design — and the only honest answer when two versions of your system genuinely cannot coexist.
Replacing instances in batches keeps the service up — at the price of a window where old and new code run simultaneously against exactly the same state.
Two complete environments and a router between them: reversal in seconds, exposure of one hundred percent, and a database that is still shared.
Exposing a small share of real traffic to the new version and widening only while health holds — the strategy that bounds width rather than duration.
Duplicating production traffic to a candidate that serves nobody — strong evidence about crashes, load and resource use, and no evidence at all about writes.
Shipping code that is switched off, then turning it on for whom you choose — and the four ways a flag system quietly becomes the least reviewed part of production.
Combining a rollout strategy, an automated comparison and a release control into one idea — exposure that increases only while evidence supports it.