DevOps / Intermediate: controlled delivery systems / Lesson 9

Continuous delivery and release strategies

Choose a rollout strategy according to user risk, state compatibility, and observable recovery conditions.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Compare rolling, blue-green, and canary exposure.
Define observable promotion and abort conditions.
Evaluate shared-state compatibility before rollback.

Separate delivery from automatic deployment

Continuous delivery keeps verified software in a state that can be released through a repeatable process. Continuous deployment automatically releases qualifying changes under an explicit policy. Neither means every repository push must reach users immediately. Promotion should refer to an immutable artifact and its evidence. Human approval can be useful for particular risks, but approval without a clear decision or current evidence becomes waiting rather than protection. Define who may authorize exposure, what is checked, and which action stops or reverses a rollout when the user-facing contract degrades.

Compare exposure patterns

A rolling update replaces instances gradually, so old and new versions coexist. Blue-green delivery prepares a separate environment and switches routing, increasing temporary capacity and requiring a data strategy. A canary exposes a limited cohort and compares behavior before expansion. Feature flags separate code deployment from user exposure, but add configuration and cleanup obligations. The first synthetic record specifies a canary decision with a bounded cohort and observation window. Its percentages are teaching choices, not a universal safe threshold. Choose the pattern by state, capacity, traffic representativeness, and recovery needs.

yaml Synthetic exposure agreement

artifact_id: lab-build-42
strategy: canary
initial_cohort_percent: 5
expansion: only-after-evidence-review
abort: user-error-budget-or-data-integrity-regression
recovery: reviewed-compatible-artifact

The record names exposure and decision rules without invoking a deployment system. Five percent is illustrative and may still be unsafe for a critical or unrepresentative workload.

Set an observation contract

A rollout needs evidence from the actual user path, not only process startup. Compare error rate, latency distribution, business outcomes, and resource pressure against a suitable baseline. A low-traffic cohort may produce too little evidence for a confident decision; a fixed five-minute timer does not create statistical power. Segment important clients and avoid comparing unrelated populations. The second simulation computes cohort failure proportions from fixed counts without producing live traffic. In a real analysis, include denominator size, uncertainty, and known seasonal effects before attributing a difference to the new version.

python Synthetic cohort arithmetic

baseline = {"bad": 4, "total": 1000}
canary = {"bad": 3, "total": 100}
for label, values in (("baseline", baseline), ("canary", canary)):
    rate = 100 * values["bad"] / values["total"]
    print(label, f"{rate:.1f}%")

Expected output

baseline 0.4%
canary 3.0%

The rates are 0.4% and 3.0%. These fixed samples illustrate normalization; they do not establish causation or a statistically justified rollout decision.

Plan coexistence and rollback

Old and new versions may share a database, message format, cache, or session state. Verify bidirectional compatibility during overlap before choosing gradual exposure. A traffic rollback does not undo writes already accepted by the new version. Some changes require a forward repair or data reconciliation instead. Preserve the previous artifact and compatible configuration, and test the route back in an authorized environment. Limit the number of simultaneous changes so a failing cohort has an interpretable cause. A rollback button is valuable only when its state assumptions remain true at the moment it is used.

Finish the release rather than abandon it

After rollout, verify all intended instances use the selected artifact and configuration, confirm user behavior, and close temporary controls deliberately. Remove expired flags, retire old capacity only after recovery requirements allow it, and retain evidence for the agreed period. A deployment job reporting success may only mean the platform accepted a request. Distinguish request acceptance, controller convergence, readiness, and post-release outcomes. Record aborts and recovery actions as first-class results so the team can improve its policy. The complete process includes cleanup and learning, not merely the first successful route switch.

Common errors and fixes

The platform accepts a release but users fail

Why it happens: Request acceptance was treated as full rollout success.
How to fix it: Verify convergence, readiness, and the user-facing contract.
Prevent it next time: Make post-release evidence a required stage.

Rollback breaks shared data

Why it happens: The new version wrote incompatible state.
How to fix it: Use the reviewed forward or reconciliation recovery plan.
Prevent it next time: Test mixed-version compatibility before exposure.

A short canary is promoted with little traffic

Why it happens: Elapsed time replaced sufficient evidence.
How to fix it: Require meaningful samples and relevant cohort comparisons.
Prevent it next time: Define observation criteria before release.

Check your understanding

1. Compare a blue-green switch with a rolling update for shared-schema changes.

Show worked solution

Both can require coexistence or rollback compatibility with the shared database. Blue-green isolates application capacity but does not automatically isolate data. Identify accepted writes and schema compatibility first; choose exposure and recovery only after proving those assumptions.

2. A canary has no failures among two requests. Is it ready for full expansion?