Deployment strategies

Why strategy matters

Most outages follow a change. A good deployment strategy limits the blast radius and makes rollback fast.

The main strategies

Recreate (big bang)

Stop the old version, start the new one. Simple, but there is downtime and no easy rollback.

Rolling update

Replace instances a few at a time. No downtime and little extra capacity, but for a while both versions serve traffic, so they must be compatible. Rollback means rolling back the same way.

Blue-green

Run two identical environments. Blue serves live traffic; deploy to green, test it, then switch the router to green. Rollback is flipping back. Cost: double the capacity during the switch, and shared state (databases) still needs care.

Canary

Send a small share (1%, 5%, 25%...) of traffic to the new version, watch the metrics, then widen. If errors rise, roll back automatically. Needs good monitoring and traffic splitting.

100%

Figure SDA-CORE-12-1 · Canary · © forcsguy.com

Feature flags

Ship code switched off, and enable it for chosen users (or a percentage) at runtime. It separates deploying from releasing, and gives an instant kill switch. Remove old flags to avoid clutter.

100%

Figure SDA-CORE-12-2 · Four ways to put a new version live · © forcsguy.com

Databases are the hard part

Code can roll back instantly; data cannot. Use expand and contract:

1. Expand: add new columns or tables, compatible with the old code.
2. Deploy code that works with both shapes and writes to both if needed.
3. Migrate data (backfill in batches).
4. Contract: remove the old structure in a later release.

Never combine a destructive schema change with the code that depends on it in one step.

Checklist for safer releases

• Automated tests and a staging environment that resembles production.
• Health checks and automatic rollback on failure.
• Monitoring on error rate and latency, watched during rollout.
• Small, frequent changes over large, rare ones.
• A written, practised rollback plan.

More on this site