Skip to main content

Deployment Strategy Workshop

Retrieval Prompts​

  1. Compare rolling, blue-green, and canary on resource cost, rollback speed, and blast radius.
  2. Name the four parts of a rollback plan.
  3. When does a feature flag protect you that a canary cannot, and vice versa?
  4. What does it mean to "dark launch" a service?
  5. Why is a maxUnavailable: 0 Kubernetes rolling update meaningfully different from the default?

Compare and Distinguish​

Separate these pairs clearly:

  • blue-green vs canary
  • canary deployment vs canary analysis (metric-gated)
  • rollback vs fix-forward
  • release toggle vs ops toggle (kill switch)
  • progressive delivery vs A/B testing

Common Mistake Check​

For each, identify the error:

  1. "Our rollback plan is to revert the PR and redeploy."
  2. "We don't need rollback -- we only deploy good code."
  3. "Canary with 10 pods means we just watch the first pod."
  4. "Blue-green is always safer than rolling."
  5. "We flipped the flag at 100% last week; we'll remove it next quarter."

Mini Application​

For each of three services described below, produce a rollout plan covering: strategy choice, success metrics, progression steps, rollback trigger, rollback action, rollback owner, rollback deadline.

Service A: checkout-api. User-facing, 5k rps, stateless, behind a load balancer, heavy in-flight-transactions sensitivity.

Service B: report-generator. Internal batch service, runs every 15 minutes, reads from the warehouse, writes reports to S3. No concurrent requests to worry about.

Service C: payments-ledger. Handles money. Writes to a strongly consistent store. Cannot run two versions of schema simultaneously.

One correct answer is not a rolling update for all three. The exercise is defending each choice from the service shape.

Evidence Check​

Your three plans are complete if:

  • each specifies a concrete metric and threshold, not "watch the dashboard"
  • each rollback action is a single command that can be tested in staging
  • you can explain why service C probably needs blue-green and service A probably needs canary
  • each plan names a single rollback owner (no approval chain)

Integrated SQA and Maintenance Drill​

For each service, add the support plan that happens after deployment.

  • pre-release SQA checks: test tier, security scan, performance smoke test, and migration check
  • deployment evidence: artifact digest, environment, approver, and release note
  • maintenance signal: alert or dashboard that proves the service is healthy after release
  • support path: who receives the first report, what log or metric they inspect first, and when rollback starts
  • configuration-management rule: how branches, tags, release notes, and hotfixes are named

Evidence check: write one incident-style note for a bad deploy and show how the process would detect, roll back, and learn from it.