How you deploy determines how confidently you can change things, which determines how fast you can move. Every strategy below is a different answer to one question: how much of your traffic are you willing to expose to a change you have not yet proved?

With the exception of a full-stop replacement, every strategy here runs two versions of your code simultaneously — during a rolling update, throughout a canary, and across a blue-green cutover while connections drain. That single fact generates most of the real difficulty.

• Database schema changes must be backward compatible for the duration. The old code must keep working against the new schema. This is why the expand-and-contract pattern exists and why it is non-negotiable at any scale.
• API changes must be additive. A new required field breaks the old callers still running beside you.
• Message formats must be readable by both. A queue holds messages written by the new version and consumed by the old one.
• Cached data must be compatible. A serialisation change means the new version cannot read what the old one cached, or worse, misreads it.

The last row deserves emphasis. Stateless services roll back; data does not. You can redeploy yesterday's binary in a minute, and you cannot un-write the rows it produced. Any change that mutates data needs a separate, explicit reversal plan — and it should be written down before the change, because writing it during an incident is how bad decisions happen.

A canary that nobody watches is a slow deploy. The value is entirely in the comparison, and there are three ways to get it wrong:

• Compare canary against a baseline, not against history. Run a small control on the old version at the same moment and compare the two. Comparing this hour's canary against last hour's fleet confounds your change with time of day, load and everything else that moved.
• Gate on the right signals: error rate, latency at the tail rather than the mean, saturation, and at least one business metric. A deploy that halves your conversion rate while every technical metric stays green is exactly the case a technical-only gate misses.
• Bake long enough for the failure mode you fear. Five minutes catches a crash loop. It does not catch a memory leak, a connection-pool exhaustion, or anything that only appears at a daily peak. Match the bake time to the slowest failure you are trying to detect, and be honest that a fast canary is only screening for fast failures.

Flags are the most powerful of these techniques because they separate deploying code from releasing behaviour. Code ships continuously, dark; the release is a configuration change with instant reversal and no deploy.

They also accumulate. A codebase with four hundred flags has an unknowable number of code paths — combinatorially, it is untestable — and every one is a branch someone must reason about. The disciplines that work:

• Every flag has an owner and an expiry date at creation. Not a policy, a required field.
• Alert on stale flags the same way you alert on anything else that is overdue.
• Distinguish the two kinds. A release flag is temporary and must be removed. An operational flag — a kill switch, a rate limiter, a degradation toggle — is permanent infrastructure and should be treated as such. Conflating them is why flag clean-up projects stall: people are reluctant to delete flags that turn out to be load-bearing.
• Flags are a control-plane dependency. If your flag service is down, what do your services do? The answer must be a safe default cached locally, not a failure — a flag system that can take down every service that reads it has inverted the whole point.

Four numbers describe a delivery system, and the useful thing about them is that they trade off against each other in ways that expose whether you are actually improving:

The pairing is what matters: frequency and failure rate together, lead time and restore time together. Optimising either one alone produces a predictable pathology, and a team reporting only the flattering half of each pair is telling you something.