Zero-Downtime Deployments: Feature Flags, Blue-Green, and AI-Generated Rollout Plans
Most production outages happen during deploys, not because of them in the abstract — because of unsynchronized schema changes, missing backward compatibility, or an all-or-nothing cutover. How to avoid all three, with AI doing the rollout planning.
A deploy shouldn't be a moment of risk. If shipping a change requires a maintenance window, careful timing, and someone watching dashboards nervously, the deployment process — not the code — is the problem. Zero-downtime deployment is a set of concrete techniques, not a vague aspiration.
Why deploys break things
- Old and new code run simultaneously during rollout (rolling deploys, multiple pods/instances) — if the new code depends on a schema change the old code can't handle, requests fail during the overlap window.
- An all-or-nothing feature switch means a bug ships to 100% of traffic instantly, with no way to limit blast radius.
- Database migrations that lock tables or aren't backward-compatible break the previous version of the app that's still serving traffic during rollout.
The expand-contract pattern for schema changes
Never make a breaking schema change in one deploy. Split it into phases where both old and new code work at every step.
| Phase | What happens | Both versions work? |
|---|---|---|
| 1. Expand | Add the new column/table alongside the old one; write to both | Yes — old code ignores the new column, new code uses both |
| 2. Migrate | Backfill existing data into the new shape | Yes |
| 3. Switch reads | New code reads from the new column; old code still works off the old one | Yes |
| 4. Contract | Once all instances run new code and nothing reads the old column, remove it | Old version no longer needs to work — safe to drop |
Feature flags: decoupling deploy from release
A feature flag lets you deploy new code turned off, then enable it gradually — 1% of users, then 10%, then 100% — independent of the deploy itself. This turns "did the deploy break something" and "does the new feature work" into two separate questions you can debug independently, instead of one tangled incident.
Context: ASP.NET Core 8 API, using [your feature flag provider, e.g. LaunchDarkly / Microsoft.FeatureManagement].
Task: Add a feature flag `new-pricing-engine` that gates a call to the new pricing calculation versus the existing one, with percentage-based rollout support.
Constraints:
- Flag check must happen at the point of use, not cached at application startup — the flag needs to be adjustable without a redeploy.
- Both code paths (old and new pricing) must remain fully functional and tested — this is a rollout mechanism, not a replacement.
- Include a kill-switch: setting the flag to 0% must be enough to fully revert behavior with no code change.
- Log which path was taken per request (flag on/off) so we can correlate errors with rollout percentage.Deployment strategies compared
| Strategy | How it works | Rollback speed | Best for |
|---|---|---|---|
| Rolling deploy | Instances replaced gradually, old and new run side by side briefly | Slow — requires redeploying old version | Routine deploys with backward-compatible changes |
| Blue-green | Full second environment stood up, traffic switched over instantly | Instant — switch traffic back | Higher-risk releases where instant full rollback matters |
| Canary | Small percentage of traffic routed to new version, monitored, then ramped | Fast — stop the ramp, route traffic back | Releases where you want real production signal before full exposure |
| Feature flags | New code ships dark, enabled independently of deploy | Instant, no deploy needed — flip the flag | Behavior changes you want to decouple from the deploy schedule entirely |
A mature pipeline uses rolling or blue-green deploys for the code itself, plus feature flags for anything behaviorally risky within that code. Ask AI to design the rollout plan naming which mechanism handles which risk — a plan that just says "use feature flags" without addressing the schema migration underneath it is incomplete.
The Production Readiness module in the Advanced program pairs this with the resilience-layer prompts (circuit breakers, retries, graceful degradation) — deployment safety and runtime resilience are two halves of the same reliability story, and treating them separately usually means one gets neglected.