Qu'est-ce que le progressive delivery : canary et blue-green

Qu'est-ce que le progressive delivery ? C'est une façon de mettre un changement en production par petites étapes contrôlées, en vérifiant chaque étape sur des métriques réelles avant de passer à la suivante. Si les chiffres se dégradent, la mise en production s'arrête ou revient en arrière toute seule. Vous ne jouez plus toute votre base d'utilisateurs sur un seul déploiement.

Vous connaissez probablement cette situation. Une pull request est approuvée, la CI est verte, le déploiement part un mardi après-midi, et vingt minutes plus tard quelqu'un demande sur Slack pourquoi la latence du tunnel de paiement a doublé. Le progressive delivery sert à raccourcir cette conversation, et à la faire arriver sur 5 % du trafic plutôt que sur 100 %.

Ce que le progressive delivery change vraiment

Le delivery continu répond à une seule question : peut-on livrer ce changement en production sans risque ? Le progressive delivery en ajoute une seconde : qui le voit en premier, et qu'est-ce qui nous dit d'arrêter ?

Le geste central consiste à séparer le déploiement de la mise en production. Déployer, c'est faire tourner le nouveau code sur les serveurs. Mettre en production, c'est exposer les utilisateurs à ce code. Une fois ces deux étapes découplées, vous pouvez déployer un mercredi à 14 h et ouvrir la fonctionnalité à votre rythme, à une audience choisie, avec un moyen de revenir en arrière.

La plupart des sources s'accordent sur trois briques : le déplacement progressif du trafic (canary), les environnements parallèles (blue-green) et les feature flags. Elles ne s'opposent pas. Les équipes matures les combinent à des niveaux différents.

Canary : quelle part du trafic, et qui décide ?

Une release canary envoie une petite part du trafic, disons 5 %, vers la nouvelle version, pendant que le reste reste sur l'ancienne. Si le taux d'erreur, la latence et la saturation restent dans vos seuils, la part augmente : 5 %, 25 %, 50 %, 100 %. Sinon, le trafic repart vers l'ancienne version.

Le piège : les répartitions fines exigent un composant capable de répartir le trafic. La documentation d'Argo Rollouts indique que des pourcentages canary précis demandent un gestionnaire de trafic, comme un service mesh ou un ingress controller. Sans cela, vous n'obtenez qu'un contrôle grossier basé sur le nombre de réplicas, et les « 5 % » peuvent signifier « un pod sur vingt ».

Voici à quoi ressemble un canary en étapes dans un manifeste Argo Rollouts. Il est volontairement court.

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 10m }   # surveiller les tableaux de bord ou lancer l'analyse
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 100

Renoncez au canary si votre service reçoit si peu de trafic que 5 % représentent quelques requêtes par heure. Vous attendrez un signal indéfiniment, ou pire, vous prendrez du bruit pour de la sécurité. Pour les services peu sollicités, des feature flags réservés aux utilisateurs internes forment une meilleure première barrière.

Blue-green : quand un second environnement complet en vaut la peine ?

Le blue-green fait tourner deux environnements de production complets. Le bleu sert les utilisateurs. Le vert reçoit la nouvelle version et y est testé pendant qu'il est inactif. Une fois satisfait, vous basculez le trafic de l'un vers l'autre.

Selon la documentation d'Argo Rollouts, la bascule est totale : l'ancienne version garde tout le trafic de production jusqu'à ce que la nouvelle soit vérifiée, puis la répartition passe de 0 % à 100 %. C'est à la fois la force et la faiblesse de l'approche. Le retour arrière tient en un seul basculement, donc il est rapide. Mais le test a lieu avant l'arrivée des vrais utilisateurs, et le coût correspond au double d'infrastructure pendant que les deux côtés tournent.

L'approche en vaut la peine pour un service avec état ou à forts enjeux, où une mise en production partielle prêterait à confusion, par exemple un parcours de paiement où deux versions ne doivent jamais traiter une requête en même temps. Renoncez-y si votre migration de base de données ne peut pas tourner sur les deux versions à la fois, car alors le « retour arrière instantané » est une fiction.

Où placer les feature flags ?

Canary et blue-green travaillent au niveau de l'infrastructure. Les feature flags travaillent à l'intérieur de l'application. Un flag entoure un chemin de code d'une condition que vous modifiez à l'exécution, sans redéployer.

C'est l'outil le plus fin de la boîte à outils. Vous pouvez exposer une fonctionnalité aux collaborateurs, puis à 1 % des comptes, puis à un segment de clients, et la couper en quelques secondes si elle se comporte mal. Certaines équipes voient les flags comme une technique parmi d'autres, d'autres comme le socle de toute l'approche. En pratique, la seconde lecture tient : dès que vous voulez mettre en production par audience plutôt que par serveur, il vous faut un flag.

Les flags ont toutefois un coût. Chaque flag est une branche que vos tests doivent couvrir, et un ticket de nettoyage que quelqu'un doit fermer. Si vous voulez la version longue, nous avons détaillé la mécanique et la dette dans ce qu'est un feature flag. Considérez chaque flag comme éphémère par défaut, avec un responsable et une date de suppression.

LaunchDarkly et Statsig vendent la couche de gestion : règles de ciblage, journaux d'audit, déploiements progressifs en pourcentage et expérimentations.

Qu'est-ce qui rend une mise en production progressive et non simplement lente ?

L'automatisation. Une mise en production qui se met en pause dix minutes pendant qu'un humain scrute un tableau de bord, c'est un déploiement lent. Elle devient du progressive delivery lorsqu'une machine vérifie les métriques et prend la décision.

Le schéma est le même partout :

1. Définir les signaux avant la mise en production : taux d'erreur, latence p95, une métrique métier comme le taux de finalisation de commande.

2. Définir les seuils qui signifient « stop », écrits dans la configuration, pas dans la tête de quelqu'un.

3. Laisser le contrôleur promouvoir, maintenir ou annuler la version selon ces signaux.

Argo Rollouts s'intègre à des fournisseurs de métriques : une mise en production peut être promue ou annulée automatiquement selon le résultat des contrôles. L'une des sources que nous avons lues le formule sans détour : sans retour arrière automatique, le progressive delivery n'est qu'un déploiement lent. Nous sommes d'accord.

Quelles métriques doivent conditionner une mise en production ?

Restez sur un petit ensemble. Trois ou quatre signaux auxquels vous faites déjà confiance valent mieux que vingt sur lesquels vous n'avez jamais posé d'alerte.

Un point de départ réaliste : le taux d'erreurs HTTP 5xx du canary comparé à la référence, la latence p95 du canary comparée à la référence, la saturation (CPU, mémoire, profondeur de file) et une métrique produit. Comparez le canary et la référence au même moment, pas le canary à « la semaine dernière », car les profils de trafic évoluent.

C'est là que votre stack d'observabilité cesse d'être un simple confort. Si vous ne pouvez pas découper vos métriques par version ou par variante de flag, vous ne distinguerez pas le canary de la référence, et toute l'approche s'effondre. Notre introduction à l'observabilité explique comment y arriver.

Comment le progressive delivery s'articule-t-il avec le trunk-based development ?

Les deux se complètent bien. Le trunk-based development garde des branches courtes et fusionne souvent de petites modifications. Le risque : du travail inachevé ou non testé arrive plus souvent sur la branche principale. Le progressive delivery rend cela sûr : le code atterrit sur le tronc, part derrière un flag désactivé, puis est mis en production progressivement.

Petits lots et exposition graduelle rendent aussi le débogage moins coûteux. Quand un canary échoue, la liste des suspects compte une modification, pas quarante. Quiconque a dû dichotomiser une semaine de commits fusionnés à 23 h sait ce que cela vaut.

Par quelle première étape commencer pour une équipe de 10 à 30 ingénieurs ?

Ne commencez pas par installer un service mesh. Commencez par le plus petit élément qui vous donne un bouton d'arrêt.

• Semaine 1 : placez une fonctionnalité risquée derrière un flag et ouvrez-la d'abord à votre propre équipe.

• Semaine 2 : ajoutez des tableaux de bord par version pour le taux d'erreur et la latence. Si votre outillage ne sait pas découper par version, corrigez cela en premier.

• Semaine 3 et après : passez un service sans état sur un contrôleur canary, avec deux ou trois étapes et une annulation automatique sur le taux d'erreur.

Mesurez en heures, pas en « sentiment de sécurité ». Comptez combien d'incidents ont été contenus sur une petite part des utilisateurs, et combien de temps a pris le retour arrière. Ces deux chiffres vous diront si cela fonctionne pour votre équipe.

Où les mises en production progressives cassent-elles le plus souvent ?

Trois endroits, et aucun ne se trouve dans le contrôleur.

Les migrations de base de données. Un canary signifie que deux versions de votre code touchent la même base en même temps. Si la version N+1 supprime ou renomme une colonne que la version N lit encore, le canary fait tomber la référence. La solution sans fioriture : expand and contract. Ajoutez d'abord la nouvelle colonne, livrez du code qui écrit dans les deux, remplissez les anciennes données, basculez les lectures, et ne supprimez l'ancienne colonne que plus tard.

Les sessions persistantes et les caches. Si un utilisateur passe d'une version à l'autre à chaque requête, vous obtenez des bugs impossibles à reproduire. Fixez chaque utilisateur sur une variante pendant toute la mise en production, via un cookie, un identifiant de compte ou l'évaluation d'un flag.

Les métriques en retard. Une métrique de conversion mise à jour toutes les heures ne peut pas conditionner une étape de canary de dix minutes. Conditionnez sur des signaux rapides (erreurs, latence) pendant la mise en production, et examinez la métrique métier lente avant de passer de 50 % à 100 %.

Comment suivre ce qui est en production dans le dépôt ?

Le progressive delivery répartit une mise en production entre des fichiers de configuration, des définitions de flags, des manifestes de rollout et des tableaux de bord. Après quelques mois, la question « quel flag protège le nouveau parcours de facturation, et qui en est responsable ? » devient la routine habituelle : grep, blame, puis demander à quelqu'un.

C'est un problème de lecture de code, pas un problème d'outillage. Chercher dans le dépôt par clé de flag et suivre chaque référence jusqu'à son point d'appel est le moyen le plus rapide de repérer les flags morts et les mises en production inachevées. Un outil qui répond à « où ce flag est-il évalué, et que se passe-t-il quand il est désactivé ? » à partir de votre code réel vous fait gagner plus de temps qu'un tableau de bord de plus.

Ce que nous ne ferions pas

Renoncez au blue-green partout si votre facture d'infrastructure est déjà un sujet de discussion. Renoncez aux canaries sur les services qui ont presque aucun trafic. Renoncez à tout outillage de déploiement que personne dans l'équipe ne sait déboguer à 3 h du matin.

Le vrai problème n'est pas la stratégie choisie. C'est l'écart entre livrer du code et savoir ce qu'il fait en production. Le progressive delivery réduit cet écart une tranche de trafic à la fois, et la première tranche compte le plus : gardez-la petite, rendez-la observable, et donnez-lui un interrupteur d'arrêt.