Deployment Strategies

A deployment moves a software change into an environment. A deployment strategy controls how that change replaces the version already serving users.

The strategy does not make a change safe by itself. It controls exposure while tests, health checks, and operators decide whether the new version should advance.

This course gives you a practical map of the main strategies. You will learn what each strategy optimizes, what it costs, and what evidence you need during a rollout.

The problem: change without uncontrolled impact

Every production change introduces risk. The new version may fail to start, return errors, slow down, or interact badly with shared data.

A useful strategy limits the blast radius. This is the portion of users, requests, or systems affected when a change fails.

Think of a deployment as a controlled transition:

known version -> limited exposure -> health decision -> wider exposure
                                      |
                                      +-> stop and recover

The transition needs more than a traffic mechanism. You also need a defined health model, promotion criteria, and a recovery action.

Separate deployment from release

Deployment puts code or configuration into an environment. Release exposes behavior to users.

A feature flag can separate the two events. You can deploy dormant code, then enable it for selected users through configuration. This adds control, but it also adds flag lifecycle and testing work.

Keep this distinction clear. A successful deployment only proves that the new version reached its target. It does not prove that users received correct behavior.

The main strategy families

All-at-once

An all-at-once deployment shifts the whole target to the new version in one step. An in-place form stops the old application, installs the new version, and starts it again.

This approach has the fewest moving parts. It also gives a failed change the largest immediate blast radius. Planned downtime may be acceptable for an internal tool or a workload with a clear maintenance window.

Rolling update

A rolling update replaces instances in batches. Old and new versions run together until the rollout completes.

The strategy can preserve availability without a second full environment. Batch size and spare capacity determine the pace. Kubernetes expresses these controls through maximum unavailable and maximum surge settings.

Rolling updates require mixed-version compatibility. Both versions may use the same APIs, queues, caches, and database during the transition.

Blue-green

A blue-green deployment keeps two complete environments. Blue serves the current version. Green receives the new version and is tested before traffic moves.

The clean traffic switch supports fast recovery when blue remains ready. The cost is duplicate capacity during the transition. You must also define the environment boundary and handle shared state deliberately.

A database can weaken the apparent simplicity. Both environments may need current data. AWS recommends separating schema changes from code changes and keeping transitions backward compatible.

Canary

A canary exposes a new version to a small production population for a limited time. The rest of the population remains on the control version.

You compare version-specific evidence, then promote, pause, or stop. A strong canary process needs a way to target exposure, an evaluation process, and release-pipeline integration.

Start with signals tied to user outcomes. Request failures, latency, and crashes often say more than a noisy resource metric. Compare the canary with a concurrent control when possible. Time alone can change system behavior and distort a before-and-after comparison.

Progressive rings and linear rollout

Progressive exposure moves through larger groups or traffic shares. A ring might begin with the service team, continue to internal users, then reach external cohorts. A linear rollout shifts traffic in equal increments at fixed intervals.

Each stage needs an observation window and an explicit gate. Waiting without checking meaningful health signals only makes the rollout slower.

Choose by constraints, not fashion

Start with the failure you need to contain.

Constraint	Useful starting point	Main concern
Downtime is acceptable	All-at-once or in-place	Recovery time
Limited spare capacity	Rolling update	Mixed-version behavior
Fast traffic reversal matters	Blue-green	Duplicate capacity and shared state
Real production evidence is required	Canary	Routing and trustworthy evaluation
Different user groups need staged access	Rings or feature flags	Cohort control and configuration hygiene

No row makes the decision for you. A stateful worker may not tolerate two versions even when a canary controller is available. A small service may gain little from a complex traffic-routing layer.

Ask these questions before choosing:

1. Can old and new versions run at the same time?
2. Can both versions safely read and write shared state?
3. Can you identify which version served each request or job?
4. Which signals decide promotion or recovery?
5. How quickly can you stop exposure?
6. Does recovery mean shifting traffic, redeploying, or rolling forward?
7. How much temporary capacity can you afford?

Build the safety system around the strategy

Define the following controls before production:

• Versioned artifact: identify exactly what is running and preserve a known-good candidate.
• Pre-deployment checks: test the change before any production exposure.
• Health model: select signals that represent correct service behavior.
• Stage gates: state the evidence and duration required to advance.
• Halt criteria: stop automatically or manually when evidence crosses a boundary.
• Recovery plan: rehearse traffic reversal, rollback, or roll-forward.
• Data compatibility: sequence schema and code changes so both active versions remain safe.
• Audit trail: record the artifact, stage, decision, and outcome.

Automation makes the sequence repeatable. It does not choose good signals for you. A precise automated gate built on an irrelevant metric still makes a poor decision.

Understand rollback limits

Rollback can mean several different actions:

• redirect traffic to the previous environment;
• restore a previous workload revision;
• redeploy a known-good artifact;
• disable a feature flag;
• apply a forward fix that restores compatibility.

These actions are not interchangeable. Traffic reversal is quick only while the previous environment remains healthy and compatible with current data.

Treat data changes as a separate recovery problem. A destructive schema change may prevent the old application from returning safely. Backward-compatible, staged changes preserve more recovery options.

A practical operating loop

Use the same loop with any strategy:

1. Define the artifact and target population.
2. Verify prerequisites and recovery readiness.
3. Expose the smallest useful stage.
4. Compare version-specific health with control and absolute limits.
5. Promote only when the gate passes.
6. Halt and recover when the gate fails.
7. Observe the completed rollout before removing recovery capacity.
8. Record what happened and improve the next rollout.

The core skill is not naming patterns. It is matching exposure, evidence, and recovery to the system you operate.