Teams that adopt blue-green or canary deployments and still see outages during releases have usually solved only half the problem. The rollout strategy controls traffic; it does nothing about the database schema underneath both versions of the app trying to read and write the same tables.
Why Deployments Still Cause Outages
The most common cause of a "deployment outage" isn't the new code — it's the moment between deploying the new code and the old code still running against a schema that one of them no longer understands. If a migration drops a column the old version still reads, every old-version pod errors until the rollout finishes.
Blue-Green vs Rolling vs Canary
- Blue-green: two full environments, traffic switches atomically. Fast rollback (flip traffic back), but doubles infrastructure cost during the switch and doesn't catch issues gradually.
- Rolling: replace instances in batches. Cheaper, but a bad deploy affects some fraction of traffic while it's rolling out.
- Canary: route a small percentage of traffic to the new version, monitor key metrics, then ramp up. Best failure containment, but requires real-time metric comparison and automated promotion/rollback to be worth the complexity.
None of these substitute for a safe migration strategy — they only limit blast radius once one exists.
Database Migrations Are the Hard Part: Expand-Contract
The pattern that makes schema changes compatible with zero-downtime deploys is expand-contract:
1. Expand: add the new column/table alongside the old one; both versions of the app can run.
2. Migrate: backfill data and switch application writes to the new structure, deployed as its own release.
3. Contract: once every instance is running the new version and nothing reads the old structure, drop it in a separate, later migration.
Renaming a column, changing a type, or dropping a table in a single migration deployed alongside the code that assumes it — is the single most common cause of "the deploy caused an outage."
Health Checks and Automated Rollback
A deployment pipeline needs a real readiness check (the app can serve traffic, not just that the process started) and an automated rollback trigger tied to error rate and latency SLOs, not a human watching a dashboard. If a canary's error rate crosses a threshold, the pipeline should roll back before a human notices, not after a page goes out.
# Example canary promotion gate
steps:
- deploy: canary
traffic: 5%
- analyze:
metrics: [error_rate, p99_latency]
duration: 10m
rollback_if: error_rate > baseline * 1.5
- promote: 100%Feature Flags Decouple Deploy from Release
Deploying code and releasing a feature don't have to be the same event. Feature flags let a team deploy dark, verify the code path in production under a flag, and flip it on for users independently — which means most "releases" carry none of the risk of a deployment at all.
Wise Hustlers builds CI/CD pipelines around expand-contract migrations and metric-gated rollouts by default, because the deployment strategy is only as safe as the schema changes riding along with it.