Deployment Strategies

Think of it as

The three differ in one variable — what fraction of traffic the new version receives over time — and everything else follows from that. Rolling ramps: 25%, 50%, 75%, 100% as instances are replaced, using no extra capacity because each new instance takes a retired one's place. That makes it the cheap default, and its cost is that both versions are live throughout, so a bug is exposed to a growing share of users and the rollback is another full roll. Blue/green steps: the green fleet is built and warmed with no traffic, smoke-tested for real, then the load balancer switches everything at once. You pay for double capacity during the switch and you gain the fastest possible rollback — flip back to blue, which is still running and still warm. Canary holds: a small slice, maybe 5%, goes to the new version while you watch error rate and latency for that slice specifically, and only when it looks right do you continue. It is the only one of the three that gives you evidence from production before full exposure, and it costs the machinery to route by share and to compare metrics *per version*, which is worth naming because a canary without per-version metrics is just a slow rolling deploy. What unites them, and matters more in Django than the choice itself, is that they all put two versions of your application in front of one database. Nothing about the strategy changes that: blue and green share the schema, the canary shares it with the stable fleet, and a rolling deploy has both versions writing rows for minutes. So the schema in effect during a deploy has to satisfy the old code and the new code simultaneously, which is exactly the expand-and-contract discipline — add the column, deploy code that writes both shapes, switch reads, and remove the old shape in a later release. Get that wrong and the strategy makes it worse rather than better: a canary that drops a column takes down the 95% that did not receive the new code. Two smaller consequences are worth holding. Sessions and caches are shared too, so a change to what you store in a session or under a cache key has to be readable by both versions or the deploy shows up as random logouts. And background workers are a third fleet: if a task signature changes, the old workers are still consuming messages the new code produced, so tasks need the same backward-compatibility treatment as the schema.

Think of it as

The reason flags matter is that a deploy and a release are usually the same moment, and that moment carries two different risks at once — did the build break anything, and is the new behaviour right? A flag separates them. The code goes out dark, so the deploy proves only that nothing broke, and the behaviour is enabled afterwards on a schedule you control and can reverse instantly. That reversal is the property people underrate: turning a flag off takes effect at the next request, whereas rolling back a deploy takes a pipeline run, and during an incident that difference is the difference between a blip and an outage. Flags come in a few shapes and it is worth being deliberate about which you are creating. A release flag is temporary and exists to control the rollout of one change — it should be deleted within weeks of reaching 100%. An operational flag ("skip the recommendation service") is a permanent switch used to degrade under load, and it is legitimate to keep. An experiment flag splits traffic to compare outcomes, and it has its own lifecycle owned by whoever reads the results. A permission flag ("this customer has the reporting add-on") is not a feature flag at all — it is authorisation, and it belongs in your permission model where it can be audited. Mixing those up is how a flag system becomes an unremovable second permission system. Two practical rules keep flags from becoming a liability. First, every flag is a branch in the code and therefore a doubling of the states you must reason about; ten flags is a thousand combinations, most of which nobody has ever run. So flags need an owner and a removal date, and the cleanup is part of the work rather than a follow-up ticket that never gets done. Second, evaluation must be cheap and safe. A flag checked in a template loop that hits the database each time is an N+1 you added on purpose, so cache the values for the request or for a short TTL; and every check needs a default for when the flag store is unreachable, because a flag system that fails closed can take down the feature it was protecting. In Django, the natural home for the check is a small service function rather than a scattered `if` — one place to read, one place to instrument, and one place to delete when the flag goes.

Think of it as

Zero-downtime replacement is an ordering problem, and the order is counter-intuitive: you tell the world you are unavailable *before* you become unavailable. The sequence is fail readiness, keep serving, wait one load-balancer check interval so it stops sending you new work, then stop accepting connections, then finish what is in flight, then exit. Skip the first two steps and the drain is racing the balancer: requests keep arriving at a process that has stopped accepting them, and the client sees a refused connection. That is the whole of the "a few 502s on every deploy" phenomenon. Underneath that sit the two numbers, and they have to nest. Gunicorn drains for `--graceful-timeout` and then force kills; systemd's `TimeoutStopSec` and a container platform's termination grace period each have to be larger, or the platform sends the kill and the drain you configured never completes. Add the pre-stop wait to the sum: if you wait ten seconds for the balancer plus thirty seconds of draining, the platform needs more than forty. Health checks split into the two kinds §90 covers, and the deploy use is worth restating in one line: liveness is "restart me", readiness is "send me traffic", and only readiness participates in a deploy. A readiness check that verifies the database is right; a *liveness* check that verifies the database is a way to turn a five-second database blip into a fleet-wide restart. Keep readiness cheap and cached for a couple of seconds, because it is polled constantly by every instance. Smoke tests are the last gate and the one most often skipped, because "the pipeline is green" feels like enough. It is not: the pipeline tested the artefact in CI, and the smoke test is the first evidence that this artefact works *in this environment*, with its real configuration, its real database, its real object storage and its real DNS. Keep them few and fast — a handful of requests that touch the paths that matter — and make them assert content rather than status. A page that returns 200 with a rendered error banner passes a status check and fails a real one. Above all, the smoke result must be wired to the rollback: a smoke test whose failure does not trigger anything is a notification, not a gate.

Think of it as

Every release is really two changes with different undo properties. The code is versioned, immutable and already built, so going back is a redeploy of an artefact that exists. The database is shared, mutable state that both versions see at once, so "going back" means running something new against data that has already moved. That asymmetry is what the roadmap means by migrations making rollback harder, and planning is the practice of noticing it before you need it. Classify the release first. An additive schema change — a nullable column, a new table, a new index — leaves the previous version fully runnable, so rollback is a redeploy and nothing else. A destructive change — dropping a column, renaming one, tightening a constraint — removes something the previous version needs, so the moment it applies the old image can no longer start; the release is forward-fix-only from then on, and that should be written in the release notes rather than learned at 02:00. Then look past the schema at the two other categories that no redeploy touches. Data transforms: a migration that rewrote or deleted rows cannot be undone by reversing the migration, because the reverse operation restores the *shape* and not the values — re-adding a dropped column gives you a column full of nulls. Emitted side effects: emails sent, payments captured, webhooks delivered, events published to a broker. Those left your system, so the only "undo" is a compensating action — a refund, a correction email, a tombstone event — which is a product decision, not an operational one. A useful planning habit is to write the rollback line at the same time as the migration, and to make it specific: "redeploy v1.13; the new column is nullable and unused by v1.13" is a plan, while "we can roll back if needed" is not. Add the trigger — what observation makes you do it — and the deadline, because most bad releases are recognised in the first ten minutes and the cost of waiting is linear. Finally, know the escape hatches when there is no rollback: a feature flag turns a behaviour change into something reversible in seconds without touching the schema, and expand-and-contract turns a destructive change into two releases where the risky half happens after the code has been running for a week. Both are planning decisions made before the code is written, which is why rollback planning belongs at design time and not at deploy time.