The booking portal of Nordlicht Reisen GmbH, a fictional travel agency, consists of a web app, an interface (API) and a service for payments. With every rollout, the question is no longer "how does the new version get into production", but: Who sees it first, how fast does the circle grow, and how do we get back? That is the skill of this lesson: deployment strategies (blue-green, canary, ring, progressive exposure, feature flags, A/B tests) and deployments in the sequence of their dependencies.
Prior knowledge: Revisions of Azure Container Apps, setting the traffic to 10 percent and rolling back, is taught in K3, lesson 3.7.6; stages, dependsOn and needs you know from lesson 4.3, checks and approvals from lesson 4.7. Here the topic is the design: which strategy for which service and what it looks like in the pipeline. Feature flags in detail follow in lesson 4.10, procedures against downtime and the hotfix path in lesson 4.9.
Not run against Azure, GitHub or Azure DevOps; from the reference of Microsoft and GitHub: All commands, YAML files and menu paths of this lesson come from the documentation or are derived from it; they were not run in this course.
A common frame: who sees what, when
In its guides to safe deployments, Microsoft describes a basic idea: progressive exposure. A version is first shown to a small group with high risk tolerance; if it proves itself, the circle grows until everyone uses it. That limits the blast radius of an error. The strategies of this lesson are ways to get there, each with a way back of its own.
| Strategy | Principle | Way back | What it costs |
|---|---|---|---|
| Blue-green | two identical environments; the new one (green) is tested and then gets the traffic | traffic back to blue | two environments at the same time |
| Canary | the new version first gets a small part of the servers or the traffic | share to 0, the rest stays | controlling the share |
| Ring | fixed groups (rings) of users or environments, one after the other | the rollout stops at the ring where the error shows | several stages, wait time |
| Progressive (progressive exposure) | the umbrella term: stages, feature flags, voluntary participation | depends on the means | observation between the stages |
| A/B test | two versions side by side to measure which one reaches a goal better | switch one version off | measurement, evaluation |
Blue-green
In a blue-green deployment, you set up two identical environments. One (blue) runs the current version and gets the users' traffic; in the other (green), the new version runs, at first without traffic. After the tests, you direct the traffic to green. If there are problems, you direct it back; blue is still running. Microsoft summarizes the steps in Container Apps: testing and verification (functional, performance, compatibility), switching the traffic, rollback and role change (next time, green is the stable environment). The guide to safe deployments describes a variant in which the traffic moves to green step by step in larger waves; the two pools must each be able to carry the full load and should be logically separate.
Canary
With canary, a small group (internal or external) gets the new version first; if it runs there without problems, it is extended step by step to larger groups. Microsoft names feature flags as the usual means of activating the new version for the target group. The first ring of a ring deployment can be a canary.
Ring deployment and tiers
Microsoft describes the rings as tiers with a purpose: Tier 0 finds most of the errors that would affect users (internal, high error tolerance), tier 1 covers areas that the team doesn't test in depth (customers with broad usage, a small data center), tier 2 finds errors of scale (public accounts, a medium to large data center), tier 3 errors with large internal accounts and a European region, tier 4 is all remaining units. Between the rings lies the bake time: Some errors show only after hours. Microsoft names one day as generally sufficient, with a peak time in it, and advises in the Well-Architected recommendation to measure the bake times in hours and days and to lengthen them from ring to ring. Faulty rollouts should stop at the ring where they are noticed; you then roll back, forward (with a hotfix) or deploy new infrastructure from the last known good state.
A/B test
An A/B test compares two versions of a service or an interface against a goal. Microsoft calls it easy to use, because the changes are usually small and lie at the customer-facing edge. It is not a safety measure, but a measuring method: What matters is how the traffic is distributed and what is measured. Container Apps names traffic splitting explicitly for blue-green and for A/B tests; Azure App Configuration has the type experiment for it (lesson 4.10).
Microsoft's frame in one line
Two principles apply to all: There is no low-risk deployment in production, so every one follows the same pattern and is automated; and small, frequent deployments are better than rare large ones, because errors are easier to find.