Deployment Strategies

Deploying software is the act of replacing what users are running with something new. How you do the replacement determines how much risk you take, how quickly you can roll back, and how much infrastructure you need.

Analogy

A restaurant rolling out a new menu has the same choices. Rolling deployment is reprinting menus one table at a time over the dinner service — cheap, but for twenty minutes some tables are ordering off the old menu and some off the new, and if the new menu renamed a dish the kitchen gets confused. Blue/green is opening a second dining room across the hall with the new menu pre-loaded, then at 6pm you politely walk every guest across and lock the old room's door — one clean flip, but you're paying rent on two rooms. Canary is handing the new menu to one booth and watching whether they complain before you reprint the rest. Feature flags are keeping both menus in every server's apron and telling them which to offer each guest — fast to reverse, but if you leave it running for a year, no server remembers which menu is which anymore.

Rolling deployment

In a rolling deployment, instances are updated one at a time (or in small batches). At any point during the rollout, some instances run the old version and some run the new version.

Before:  [v1] [v1] [v1] [v1]
Step 1:  [v2] [v1] [v1] [v1]
Step 2:  [v2] [v2] [v1] [v1]
Step 3:  [v2] [v2] [v2] [v1]
Done:    [v2] [v2] [v2] [v2]

Wins: No extra infrastructure. Works on any platform that runs multiple instances. Kubernetes rolling updates are this.

Loses: Requests can be served by v1 or v2 simultaneously during rollout. If v2 changes the API contract or database schema in an incompatible way, some requests fail. Rolling deployments require backward-compatible changes.

Rollback: Re-issue the deployment with the old image. You go backward through the rolling update.

Blue/green deployment

Two identical environments exist: blue (current production) and green (new version). Traffic is switched atomically from blue to green at the load balancer level.

Load balancer → blue (v1)    # before
Load balancer → green (v2)   # after (atomic switch)

Wins: Zero mixed-version traffic. Rollback is instant — flip the load balancer back to blue. Green stays live for a time, ready for immediate rollback.

Loses: Requires double the infrastructure during deployment. Session state and database connections may be disrupted at switch time if not handled carefully.

Canary deployment

A canary routes a small percentage of traffic (1%, 5%, 10%) to the new version before committing to a full rollout. Metrics are observed. If the canary is healthy, traffic is gradually shifted.

Traffic split:  v1 95% │ v2 5%
                v1 80% │ v2 20%
                v1 50% │ v2 50%
                v1  0% │ v2 100%

Wins: Real production traffic validates the new version with limited blast radius. Metrics-based rollout can be automated: if error rate > threshold, halt and roll back.

Loses: Requires traffic splitting infrastructure (Kubernetes ingress weights, AWS target group weights, etc.). More operationally complex. Requires good metrics.

Feature flags (progressive delivery)

A feature flag decouples deploying code from enabling behaviour. The code ships to all instances; a runtime flag controls whether users see the new feature.

deploy v2 to all instances
flag.enable("new-checkout") for 1% of users
flag.enable("new-checkout") for 10% of users
flag.enable("new-checkout") for 100% of users

Wins: Instant rollback (toggle the flag off). Safe for large teams: multiple features can ship in the same codebase at different rollout percentages. Separates deployment risk from feature risk.

Loses: Flag debt accumulates. Old flags must be cleaned up or the codebase fills with dead branches. Flags complicate testing — every combination of flags is a different code path.

Choosing the right strategy

Strategy	Rollback speed	Infrastructure cost	Mixed-version risk	Good for
Rolling	Minutes	None extra	Present	Most deployments
Blue/green	Seconds	2× during deploy	None	Stateless services with clean cutover
Canary	Seconds	Moderate	Present but limited	High-risk changes with good metrics
Feature flags	Instant	None extra	Present	Features, A/B tests, gradual rollouts

Most teams use rolling as the default and reach for canary or feature flags for high-risk changes. Blue/green is worth the cost when an instant, clean cutover is required.

Database migrations and the deployment contract

Any strategy that runs v1 and v2 simultaneously — rolling and canary — requires that the database schema be compatible with both versions at the same time. This forces expand-contract migrations:

1. Expand: Add the new column with a nullable default. Both v1 and v2 work.
2. Migrate: Backfill data. Both versions still work.
3. Contract: Once v1 is gone, make the column non-nullable, drop old columns.

Feature flags avoid this if you control which users see v2. Blue/green avoids it if the database switch is atomic. Rolling and canary cannot avoid it.