Du Commit au Déploiement Complet : Construire un Pipeline de Progressive Delivery

Vous mergez votre code dans la branche principale. Le pipeline CI passe au vert. L'artefact est prêt. Et maintenant ?

Dans la plupart des équipes, l'étape suivante est simple : déployer en production. Mais si vous avez déjà vu un déploiement mal tourner — un bug qui n'apparaît qu'avec du trafic réel, une régression de performance qui s'installe silencieusement, une fonctionnalité qui déroute les utilisateurs — vous savez que « déployer à tous les utilisateurs d'un coup » est un pari que vous n'êtes pas obligé de prendre.

Le progressive delivery change cela. Au lieu d'un unique interrupteur, vous déployez les changements progressivement, en utilisant le routage de trafic, les feature flags et la supervision automatisée pour décider à chaque étape s'il faut continuer ou revenir en arrière. Cet article explique comment assembler un pipeline de progressive delivery complet, depuis le moment où le code est mergé jusqu'à ce que la fonctionnalité soit entièrement en production et stable.

Le diagramme suivant présente les étapes du pipeline en un coup d'œil :

flowchart TD A[Commit / Merge] --> B[Build & Tests] B --> C[Canary Ring<br>1% traffic] C --> D{Monitor Metrics} D -- Pass --> E[Staged Rollout<br>10% → 25% → 50%] D -- Fail --> F[Auto Rollback] E --> G{Monitor & Gate} G -- Pass --> H[Full Rollout<br>100%] G -- Fail --> F H --> I[Flag Cleanup] F --> J[Notify Team]

Le Build et les Tests de Base

Le pipeline commence comme n'importe quel autre. Quand un développeur merge du code dans la branche principale, le pipeline exécute les tests unitaires, les tests d'intégration et les scans de sécurité. Ce sont les mêmes vérifications que vous avez déjà — rien de spécial pour l'instant.

Si tout passe, le pipeline produit un artefact déployable. C'est là que le progressive delivery commence à différer d'un pipeline standard. L'artefact ne va pas directement à tous les utilisateurs. Il entre dans le premier anneau de déploiement, généralement appelé l'anneau canary.

L'Anneau Canary : Votre Premier Vrai Test

L'anneau canary reçoit une petite fraction du trafic — disons, un pour cent de toutes les requêtes. Le pipeline déploie la nouvelle version sur les serveurs qui servent cet anneau. Puis il active les feature flags pertinents pour les utilisateurs qui atterrissent dans cet anneau.

Voici un exemple GitLab CI qui définit l'anneau canary et les étapes de déploiement progressif :

stages:
  - canary
  - staged-rollout
  - full-rollout

canary-deploy:
  stage: canary
  script:
    - kubectl set image deployment/my-app canary=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app --replicas=1
  environment:
    name: production/canary
    url: https://canary.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

auto-promote:
  stage: staged-rollout
  script:
    - sleep 600  # fenêtre de monitoring de 10 minutes
    - ./check-metrics.sh  # vérifier le taux d'erreur, la latence dans les SLO
    - kubectl set image deployment/my-app-10pct my-app=my-app:$CI_COMMIT_SHA
    - kubectl scale deployment/my-app-10pct --replicas=2
  needs: ["canary-deploy"]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

rollout-50pct:
  stage: staged-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app-50pct my-app=my-app:$CI_COMMIT_SHA
  needs: ["auto-promote"]
  when: manual  # nécessite une approbation manuelle

rollout-100pct:
  stage: full-rollout
  script:
    - ./check-metrics.sh
    - kubectl set image deployment/my-app my-app=$CI_COMMIT_SHA
  needs: ["rollout-50pct"]
  when: manual

Les feature flags ajoutent une couche de contrôle supplémentaire ici. Même si la nouvelle version est en cours d'exécution, des fonctionnalités spécifiques peuvent être activées uniquement pour certains utilisateurs au sein de l'anneau canary. Cela vous permet de tester non seulement la stabilité de la nouvelle version, mais aussi le comportement d'une fonctionnalité particulière sur de vrais utilisateurs, sans exposer tout le monde.

Pendant que la nouvelle version s'exécute dans l'anneau canary, l'observabilité entre en jeu. Le pipeline surveille le taux d'erreur, la latence et d'autres métriques définies dans vos Service Level Objectives (SLO). Si toutes les métriques restent dans des limites acceptables pendant une période définie — disons, dix minutes — le pipeline passe automatiquement à l'étape suivante. Si une métrique viole le seuil, le pipeline déclenche un rollback automatique : le trafic est redirigé vers l'ancienne version, les feature flags sont désactivés, et l'équipe est notifiée.

Déploiement Progressif : Élargir l'Audience

L'étape suivante est un anneau plus large, servant peut-être dix pour cent des utilisateurs. Le processus se répète : déployer, activer les flags, surveiller, décider. Mais maintenant, vous avez plus de marge pour expérimenter avec les feature flags. Par exemple, vous pourriez activer la nouvelle fonctionnalité uniquement pour les utilisateurs qui se sont inscrits en tant que bêta-testeurs. Cela vous donne des données réelles provenant de vrais utilisateurs sans impacter tout le monde.

Le pipeline continue d'élargir l'audience étape par étape : de dix pour cent à vingt-cinq pour cent, puis à cinquante pour cent, et enfin à cent pour cent. Chaque fois que le pipeline passe à l'anneau suivant, il franchit une porte de promotion. Cette porte peut être une vérification automatisée basée sur les métriques, ou elle peut attendre une approbation manuelle de l'équipe. De nombreuses équipes utilisent une combinaison : des portes automatisées pour les décisions rapides, et une approbation manuelle pour les étapes critiques, comme avant de passer à cent pour cent des utilisateurs.

Nettoyage des Feature Flags

Une fois que la nouvelle version sert tous les utilisateurs, le pipeline n'est pas terminé. Les feature flags qui sont maintenant actifs pour tout le monde doivent être nettoyés. Le pipeline peut exécuter une tâche qui vérifie si un flag est toujours utilisé, puis crée une pull request pour supprimer le code du flag du dépôt. Cela évite que votre codebase n'accumule des flags morts dont personne ne se souvient.

Ce Qui Rend Ce Pipeline Différent

Un pipeline de progressive delivery n'est pas seulement une séquence de déploiements. C'est un système qui combine la gestion du trafic, le contrôle des fonctionnalités, la supervision automatisée et les décisions basées sur les données en un seul flux qui va du commit au déploiement complet. Chaque étape est une couche de sécurité qui garantit que les changements ne cassent pas soudainement l'expérience utilisateur.

La différence clé par rapport à un pipeline traditionnel est que vous ne vous demandez pas « le build a-t-il réussi ? » Vous vous demandez « le changement est-il sûr à exposer à plus d'utilisateurs ? » Cette question ne peut pas être répondue par les seuls tests unitaires. Elle nécessite du trafic réel, de vrais utilisateurs et de vraies métriques.

Checklist Pratique pour Votre Pipeline

Si vous construisez un pipeline de progressive delivery, voici les composants à vérifier à chaque étape :

  • Anneau canary : Reçoit-il une fraction de trafic petite et mesurable ? Pouvez-vous router les utilisateurs de manière cohérente pour que le même utilisateur reste dans le même anneau ?
  • Feature flags : Les flags sont-ils limités à des utilisateurs ou groupes spécifiques ? Pouvez-vous les activer/désactiver indépendamment du déploiement ?
  • Observabilité : Le taux d'erreur, la latence et les métriques métier sont-ils surveillés ? Les seuils sont-ils basés sur vos SLO, et non sur des suppositions arbitraires ?
  • Portes de promotion : Chaque anneau a-t-il une condition claire pour passer à l'étape suivante ? Y a-t-il une étape d'approbation manuelle pour les expansions critiques ?
  • Rollback : Le rollback est-il automatisé lorsque les métriques dépassent les seuils ? Inclut-il à la fois le routage du trafic et la désactivation des flags ?
  • Nettoyage des flags : Existe-t-il un processus pour supprimer les flags après le déploiement complet ? Le pipeline crée-t-il une pull request ou notifie-t-il l'équipe ?

Ce Qu'il Faut Retenir

Un pipeline de progressive delivery transforme le déploiement d'un événement binaire en un processus gradué. Vous ne publiez pas un changement en espérant que tout va bien se passer. Vous le publiez à un petit groupe, vous observez ce qui se passe, et vous décidez s'il faut continuer. Si quelque chose tourne mal, seule une infime fraction des utilisateurs est affectée, et le système se rétablit automatiquement.

Le pipeline ne consiste pas à ajouter de la complexité. Il s'agit d'ajouter du contrôle. Chaque anneau, chaque porte, chaque vérification de métrique est une occasion de détecter un problème avant qu'il ne devienne un incident. Construisez votre pipeline avec cela en tête, et vous dormirez mieux après chaque merge.