Standard 4 stops to get here · leads to 3

Release Strategy

The plan for how a new model or software version reaches users: all at once, to a small slice first, or silently alongside the old one, with a way back if it fails.

Your route here

4 stops · basics first
  1. Dataset ✓ understood

    A collection of data examples used for training, validating, or testing machine learning models.

  2. Training ✓ understood

    The process of fitting a model to data by repeatedly measuring how wrong its outputs are and adjusting its parameters to reduce that error.

  3. Inference ✓ understood

    Running a trained model on new inputs to get predictions, with its weights frozen: the stage of a model's life that users actually interact with.

  4. Model Serving ✓ understood

    Deploying trained models as services that can handle prediction requests in production environments.

  5. Release Strategy · you are here ✓ understood

Picture it

Blue-green

  • Two identical environments
  • Switch all traffic at once
  • Roll back by switching back

Canary

  • New version gets a small slice
  • Compare it against the rest
  • Widen the slice if it holds up

Shadow

  • New version sees real requests
  • Its answers are logged, not served
  • Zero user impact while you compare
Notice the trade: each strategy exposes the new model to less user risk, or to real traffic sooner, but none of them gives you both for free.

A release strategy decides how a change goes live. Shipping a new model version to every user at once is the fastest option and the riskiest: if it is worse in some way offline tests missed, everyone sees the problem at the same moment. Release strategies trade a little speed for the ability to catch problems early and undo them quickly.

The main patterns, each with its own entry:

  • Blue-green deployment: run two production environments, as identical as possible. The new version is prepared in the idle one, then the router flips all traffic over. Rolling back means flipping back.
  • Canary deployment: send the new version to a small subset of users or servers first, the “canary”, while the rest stays on the old version as the control. Google’s SRE workbook describes canarying as effectively an A/B testing process: compare the two groups, then decide whether to continue the rollout.
  • Shadow deployment: the new model receives copies of real requests and its predictions are recorded but never shown to users. You learn how it behaves on live data with no user-facing risk, at the cost of running both models.

What changes for ML

For ordinary software, a bad release usually shows up as errors or crashes. A bad model can return perfectly well-formed predictions that are simply less accurate, so a release strategy for ML depends on model monitoring that tracks quality signals, not just uptime. Outcome signals can take hours or days to arrive, which argues for longer canary windows or a shadow phase first. Measuring whether the new model actually improves the product is the job of an A/B test, which often runs as the final stage of a rollout.

Where it sits

Before this

Model Serving
Release Strategy

Leads to

Blue-Green Deployment Canary Deployment Shadow Deployment

Explore nearby

Shipping AI Canary Deployment Gradually rolling out new model versions to subset of traffic before full deployment. Shipping AI Blue-Green Deployment Running two identical environments to enable zero-downtime model updates and rollbacks. Shipping AI Shadow Deployment Running a new model alongside production without affecting user experience, for validation. Evaluation A/B Testing Comparing two model versions in production by routing traffic to each and measuring performance differences. Shipping AI Model Monitoring Tracking model performance, data distribution, and predictions in production to detect issues and degradation. Shipping AI MLOps Practices for deploying, monitoring, and maintaining machine learning models in production, combining ML and DevOps principles.

Sources

  1. Google SRE Workbook, "Canarying Releases" . Chapter 16, The Site Reliability Workbook
  2. Martin Fowler, "BlueGreenDeployment" . bliki, 2010
  3. Danilo Sato, "CanaryRelease" . martinfowler.com bliki, 2014