openskills.info
Course Preview

Deployment Strategies

Deployment strategies determine how new software versions reach production: all-at-once, rolling, blue-green, canary, or feature-flag based. Each trades off between speed, risk, rollback capability, and infrastructure cost.

itDevOps and software delivery

Don't Panic — Deployment Strategies

A deployment strategy is the arrangement for replacing software that is already serving people. It exists because changing every instance at once is a remarkably efficient way to discover a mistake at full volume. The useful question is not which pattern has the most reassuring name. It is how much exposure a change gets before the evidence tells you to continue or stop.

The three pieces are exposure, a health gate, and recovery. Exposure decides who receives the new version: every target, a batch of instances, a separate green environment, a small canary population, or an ordered ring of users. A health gate decides whether the next stage is allowed. Recovery is the particular escape route when the gate says no. These are one system wearing three hats, which is already plenty of hats for a production change.

A rolling update trades spare capacity for overlap. Old and new instances live together while batches change, so their APIs, queues, caches, sessions, jobs, and database schema must tolerate each other. Blue-green keeps two environments and switches traffic after green is ready. That can reverse traffic quickly, but only while blue remains healthy and understands the current data. The database, naturally, has opinions about this.

A canary sends a small production population to the new version while a control stays on the current one. It is not a tiny permission slip. It is an experiment: compare version-specific request failures, latency, crashes, or critical completion during the same period, then keep absolute service limits as well. Partial traffic without evaluation is only partial risk, which is less poetic than it first appears.

Feature flags add another lever. Deployment places code or configuration into an environment; release exposes behavior to users. A flag can keep deployed behavior dormant until a selected cohort receives it. That gives rings more precision, along with two flag states to test and one more thing to remove later.

For a dense reference, open the Cheatsheet: it has the strategy comparison, mixed-version checklist, and data-change sequence. The slides show the flows and decision points. The practice reference turns the idea into a rollout contract, and the exercise asks you to halt a synthetic canary using an explicit limit. The point is not to memorize a list of patterns. It is to make exposure, evidence, and recovery agree before they meet production.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources