Canary Release

Le rollout progressif : la nouvelle version reçoit d'abord 1%, puis 10%, puis 50% du trafic, surveillée à chaque étape. Le pattern qui transforme un déploiement risqué en série de micro-validations contrôlées.

Problème

Un Blue-Green pur est tout-ou-rien : 0% ou 100% du trafic sur la nouvelle version. Pour un mapping EDI critique ou un gateway AS2, la bascule à 100% expose tout le trafic au risque de régression simultanément. Si la nouvelle version a un bug sub-1% (cas limite mal couvert), il faut beaucoup de messages pour s'en rendre compte : dans l'intervalle, des milliers de transactions ont déjà été traitées avec le bug.

Forces

• Le risque doit être plafonné : au moment où on découvre la régression, on n'a affecté que X% du trafic.
• Les SLO doivent être mesurables en temps réel : le rollout dépend des métriques live (latence, error rate, ack rate).
• La distribution doit être déterministe : un même partenaire/message ne doit pas alterner entre v1 et v2 sur des appels successifs.
• L'incrément doit être configurable : la séquence 1% / 10% / 50% / 100% ou 5% / 25% / 100% selon criticité.
• Le rollback doit être automatisable : si les SLO se dégradent, retour automatique à l'étape précédente sans intervention humaine.

Solution

Déployer la nouvelle version comme un canari (référence à l'usage historique des canaris dans les mines). À l'étape 1, 1% du trafic est routé sur v2.0 — c'est le canari, qui « meurt » si quelque chose va mal. Les SLO sont surveillés (latence, error rate, taux d'ack) sur cette fraction du trafic. Si OK, on monte à l'étape suivante (10%, 50%, 100%) avec validation à chaque palier. La distribution est typiquement faite par hash de l'ID de message ou de l'ID de partenaire, pour garantir la stabilité. Le rollback est automatique sur dépassement de seuil. Outils : Flagger (CNCF, basé sur Istio/Linkerd), Argo Rollouts (Kubernetes), AWS AppMesh, Google Cloud Deploy.

Rollout progressif avec surveillance SLO :

   Étape 0 : 100% v1.0 (baseline)
              ▼
   Étape 1 : 1%  v2.0 + 99% v1.0   ─ 1h surveillance
              ▼  (SLO OK ?)
   Étape 2 : 5%  v2.0 + 95% v1.0   ─ 2h
              ▼
   Étape 3 : 10% v2.0 + 90% v1.0   ─ 4h
              ▼
   Étape 4 : 25% v2.0 + 75% v1.0   ─ 8h
              ▼
   Étape 5 : 50% v2.0 + 50% v1.0   ─ 12h
              ▼
   Étape 6 : 100% v2.0             ─ stable, nettoyage v1.0

   À chaque étape : si SLO dégradé (error rate ↗, latency ↗) :
   - rollback immédiat à l'étape précédente
   - investigation
   - rebascule à plus faible % ou abandon

Implémentation EDI

Cas concret : déploiement d'un nouveau validateur EN 16931 avec règles 2025 affinées. Sans Canary : bascule à 100%, si une règle est trop stricte et rejette des factures légitimes, rejet massif détecté au bout de 2-3h, impact business majeur. Avec Canary : étape 1 à 1% pendant 1h, monitoring des taux de rejection. Si rejection rate baseline = 0,2% et que v2.0 monte à 2%, alerte → rollback automatique → investigation. Si OK, montée à 5%, 10%, etc. Le routeur est un Istio VirtualService avec poids : http: [{ route: [{ destination: { host: validator, subset: v1 }, weight: 90 }, { destination: { host: validator, subset: v2 }, weight: 10 }] }]. Le contrôleur Flagger automatise la promotion progressive selon les SLO Prometheus. Variante intéressante : canary par partenaire — la v2 est activée d'abord sur 1 partenaire pilote coopératif, puis étendue.

Anti-patterns

• Canary sans observabilité : monter à 50% sans surveiller les SLO = blind canary = aucun bénéfice vs Blue-Green tout-or-nothing.
• Distribution non déterministe : un même partenaire alterne entre v1 et v2 → mappings incohérents, audit impossible.
• Pas de critère de promotion explicite : la décision de passer à l'étape suivante est laissée à l'œil de l'ops → erreurs.
• Canary qui prend des jours : les paliers sont trop espacés, la fenêtre d'exposition est longue, deux partenaires utilisent v1 et v2 en parallèle sur des longues durées (problèmes de cohérence).
• Pas de rollback automatique : dépendre de l'astreinte humaine pour rollback annule le bénéfice de réaction rapide.
• Canary infini : rester à 25% « pour voir » pendant des mois — décision indéfiniment reportée.

Patterns liés

• Feature Flag — la brique applicative qui pilote la distribution.
• Blue-Green Deployment — version tout-ou-rien, complémentaire au Canary.
• Dark Launch — variante où le trafic est dupliqué sans retour utilisateur.
• Circuit Breaker — protection runtime indépendante.
• Chaos Engineering — la mise en stress préalable au Canary pour valider la résilience.

Sources

• Sato D. — CanaryRelease (martinfowler.com, 2014). La définition canonique du pattern. martinfowler.com — CanaryRelease
• Beyer B., Jones C., Petoff J., Murphy N. — Site Reliability Engineering, O'Reilly 2016. Chapitre 16 sur le tracking des changements en production. sre.google/sre-book
• Argo Rollouts — Documentation officielle du contrôleur Kubernetes pour canary et blue-green. argoproj.github.io — argo-rollouts
• Flagger (CNCF) — Documentation du progressive delivery operator pour Istio, Linkerd, NGINX. flagger.app
• Kim G., Humble J., Debois P., Willis J. — The DevOps Handbook, IT Revolution Press 2016 (2e éd. 2021). Patterns de déploiement progressif.
• Beda K., Burns B., Hightower K. — Kubernetes Up & Running, O'Reilly 2022. Chapitre sur le déploiement progressif avec Argo et Flagger.