Rolling, Blue-Green, and Canary Releases

What you will be able to do

• Distinguish existing version from candidate version in a realistic rolling, blue-green, and canary releases case.
• Interpret the delivery evidence and boundary associated with rolling update.
• Choose an appropriate action involving canary evaluation without exceeding the named operational scope.
• Verify rollback signal through an observable service result and reproducible handoff.

01

Frame Rolling, Blue-Green, and Canary Releases

Choose rolling, blue-green, or canary release behavior from service risk, capacity, traffic control, observation quality, and recovery needs.

A search service can run two versions at once and exposes latency and error metrics. The team must release a risky ranking change with limited user impact.

Keep the delivery target, declared intent, execution evidence, reliability boundary, and recovery choice separate. Start with observable state and preserve enough context for another operator to reproduce the decision.

02

Existing version

The existing version is the known service baseline during a progressive release. Within rolling, blue-green, and canary releases, this role answers a separate delivery or reliability question and keeps its own evidence.

Keep a healthy control population on the current package. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not remove the recoverable version before evaluating the change. The observable result is specific: the control continues serving normal traffic.

03

Candidate version

The candidate version is the exact tested artifact proposed for wider exposure. Within rolling, blue-green, and canary releases, this role answers a separate delivery or reliability question and keeps its own evidence.

Deploy the immutable candidate to the selected initial capacity. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not substitute a rebuild after approval. The observable result is specific: the exposed instances run the approved artifact digest.

04

Rolling update

A rolling release replaces parts of the service while old and new versions coexist. Within rolling, blue-green, and canary releases, this role answers a separate delivery or reliability question and keeps its own evidence.

Limit unavailable and additional capacity according to service needs. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not assume coexistence is safe when versions are incompatible. The observable result is specific: healthy increments replace the old population progressively.

05

Canary evaluation

A canary exposes a small production subset and compares its behavior before expansion. Within rolling, blue-green, and canary releases, this role answers a separate delivery or reliability question and keeps its own evidence.

Compare candidate latency and errors with the control population. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not expand on elapsed time without defined evaluation evidence. The observable result is specific: the canary meets the release criteria before wider rollout.

06

Rollback signal

A rollback condition defines the evidence that ends or reverses a release. Within rolling, blue-green, and canary releases, this role answers a separate delivery or reliability question and keeps its own evidence.

Stop and restore the known package when the error criterion fails. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not continue expanding while the cause remains uncertain. The observable result is specific: traffic returns to the healthy baseline and impact stops growing.

07

Apply Rolling, Blue-Green, and Canary Releases to One Service Change

Use one bounded delivery decision: A search service can run two versions at once and exposes latency and error metrics. The team must release a risky ranking change with limited user impact.

First, keep a healthy control population on the current package. Then, deploy the immutable candidate to the selected initial capacity. Keep both observations attached to the exact revision, environment, or service window.

Next, limit unavailable and additional capacity according to service needs. After that, compare candidate latency and errors with the control population. Close the work only after you stop and restore the known package when the error criterion fails.

08

Recap Before Practice and Prove

Existing version: The existing version is the known service baseline during a progressive release. In this service case, keep a healthy control population on the current package. Preserve the boundary: do not remove the recoverable version before evaluating the change.

Candidate version: The candidate version is the exact tested artifact proposed for wider exposure. In this service case, deploy the immutable candidate to the selected initial capacity. Preserve the boundary: do not substitute a rebuild after approval.

Rolling update: A rolling release replaces parts of the service while old and new versions coexist. In this service case, limit unavailable and additional capacity according to service needs. Preserve the boundary: do not assume coexistence is safe when versions are incompatible.

Canary evaluation: A canary exposes a small production subset and compares its behavior before expansion. In this service case, compare candidate latency and errors with the control population. Preserve the boundary: do not expand on elapsed time without defined evaluation evidence.

Rollback signal: A rollback condition defines the evidence that ends or reverses a release. In this service case, stop and restore the known package when the error criterion fails. Preserve the boundary: do not continue expanding while the cause remains uncertain.