Learning Hub
← DevOps & Infrastructure

Deployment strategies and safe rollback

6 min readΒ·Updated 2026-09-09

Deployment strategy controls how a new version receives traffic and how quickly risk can be contained. Rolling, blue-green, and canary releases trade infrastructure cost, speed, observability, and blast radius.

Deployment strategy controls how a new version receives traffic and how quickly risk can be contained. Rolling, blue-green, and canary releases trade infrastructure cost, speed, observability, and blast radius.

At a glance

Question Practical answer
When is it useful? A canary sends five percent of traffic to a new checkout version, compares error and latency signals, then increases traffic or rolls back automatically.
What should you do? Design a release for one service with entry criteria, health signals, traffic stages, database compatibility, abort thresholds, and a rehearsed rollback command.
How do you know it worked? The previous version remains deployable, rollback fits the recovery objective, database changes are backward compatible, and decision owners know the stop signal.
Common failure Rollback code cannot undo an irreversible data migration; use expand-migrate-contract and tested restore procedures.
flowchart LR
  A[Question] --> B[Deployment strategies and safe rollback]
  B --> C[Small example]
  C --> D[Evidence]

The important idea is not to stop at a definition: connect the concept to a small example and observable evidence.

Worked example

A canary sends five percent of traffic to a new checkout version, compares error and latency signals, then increases traffic or rolls back automatically.

Before acting, write the success signal. Change one condition at a time, observe the result, and record assumptions. For Deployment strategies and safe rollback, this separates what you know from what you are merely guessing.

Practice in 20–30 minutes

Goal: Design a release for one service with entry criteria, health signals, traffic stages, database compatibility, abort thresholds, and a rehearsed rollback command.

  1. Record the starting state and your prediction.
  2. Implement the smallest version without adding unnecessary tools.
  3. Change exactly one input or constraint and repeat.
  4. Save a command, screenshot, output, or checklist as evidence.

Expected result: The previous version remains deployable, rollback fits the recovery objective, database changes are backward compatible, and decision owners know the stop signal.

What can go wrong

Rollback code cannot undo an irreversible data migration; use expand-migrate-contract and tested restore procedures.

When the result differs from your prediction, do not change many things at once. Check inputs, versions, environment, permissions, and logs, then repeat from the smallest example.

Definition of done

  • I can explain the concept in my own words.
  • I completed the small example and kept evidence.
  • I know one failure mode and how to check it.
  • Someone else can repeat the work without guessing missing steps.

Go deeper

Use the linked resource or repository at the end of the page when you need a full implementation. Check current versions before applying commands to a real project.