Pipelines CI/CD et stratégies de déploiement

Du commit à la production : à quoi sert un pipeline

La section 0.8 (comment les logiciels sont construits) a présenté l’intégration continue (chaque changement est fusionné et vérifié automatiquement), la livraison continue (la branche principale peut toujours être mise en production) et le déploiement continu (chaque changement qui passe les contrôles va en production sans décision humaine). Cette section les traite comme de l’architecture : la conception du chemin que suit un changement, et les stratégies qui l’amènent en production sans nuire aux utilisateurs.

L’idée centrale est le pipeline de déploiement, décrit par Jez Humble et David Farley dans Continuous Delivery (2010). Chaque commit déclenche une séquence automatisée d’étapes. Les premières étapes sont rapides et peu coûteuses, et détectent la plupart des problèmes ; les suivantes sont plus lentes, plus réalistes et plus coûteuses. Un changement ne passe à l’étape suivante que si la précédente a réussi : plus un build avance, plus il a gagné la confiance. Un échec, où qu’il se produise, arrête ce build et revient directement à la personne qui a fait le changement, pendant qu’elle l’a encore bien en tête.

Le pipeline compte pour les architectes pour trois raisons. D’abord, c’est là que la déployabilité, un attribut de qualité vu en section 2.6, est réellement obtenue ou perdue. Ensuite, sa vitesse limite la rapidité avec laquelle l’organisation peut réagir à une évolution du marché ou à une vulnérabilité de sécurité : si un correctif d’une ligne met deux jours à atteindre la production, l’architecture a deux jours de retard, quel que soit l’aspect du code. Enfin, la forme du système contraint la forme du pipeline : des services déployables indépendamment peuvent avoir des pipelines indépendants, mais un monolithe distribué impose des mises en production coordonnées, aussi astucieux que soient les outils.

Build once, deploy many, et le dépôt d’artefacts

Une règle de Continuous Delivery encore enfreinte étonnamment souvent est build once, deploy many (construire une fois, déployer partout) : compiler et empaqueter chaque changement exactement une fois, puis promouvoir ce même artefact dans chaque environnement. Si une équipe reconstruit pour le staging, puis à nouveau pour la production, ce qu’elle a testé n’est pas ce qu’elle a livré. Un correctif différent du compilateur, une dépendance résolue pendant la nuit vers une version plus récente ou une image de base modifiée peuvent faire diverger les deux builds, et les tests ne prouvent rien sur le second.

Ce qui diffère d’un environnement à l’autre, c’est la configuration, fournie au moment du déploiement ou du démarrage (adresses de bases de données, identifiants, réglages des feature flags), jamais intégrée à l’artefact. C’est le facteur de configuration de l’application douze facteurs. Une image de conteneur étiquetée orders:4f1c2ab (le hash du commit) est déployée en test, en staging et en production ; seuls ses variables d’environnement et ses secrets montés changent.

Le dépôt d’artefacts est le stockage entre le build et le déploiement : un registre de conteneurs (Amazon ECR, Azure Container Registry, Google Artifact Registry, GitHub Container Registry, Harbor) ou un dépôt universel comme JFrog Artifactory ou Sonatype Nexus pour les paquets et les binaires. Traitez-le comme une infrastructure critique. Déployez par digest immuable (sha256:...) plutôt que par un tag modifiable comme latest, qui peut être déplacé pour pointer vers une autre image ; conservez les artefacts qui sont ou ont été en production aussi longtemps que vous pourriez avoir besoin d’y revenir ou de les examiner ; et enregistrez la provenance, c’est-à-dire le commit, l’exécution du pipeline et les dépendances qui ont produit chaque artefact.

Développement basé sur le tronc et petits lots

La façon dont le code est réparti en branches détermine la fréquence à laquelle il est réellement intégré. Dans le développement basé sur le tronc, chacun intègre de petits changements dans une seule branche principale (le tronc) au moins une fois par jour, soit en faisant des commits directement, soit par des branches de courte durée et des pull requests qui vivent quelques heures, pas des semaines. Le programme de recherche DORA a associé à plusieurs reprises les branches de courte durée et les fusions fréquentes à une meilleure performance de livraison, et c’est une condition préalable à l’intégration continue au sens littéral : du code qui reste trois semaines sur une branche n’est pas intégré en continu.

Les branches de fonctionnalité de longue durée semblent plus sûres, parce que le travail inachevé est tenu à l’écart, mais le risque n’est que reporté : plus deux branches divergent longtemps, plus la fusion finale est grosse et risquée, et plus longtemps le pipeline voit du code qui n’est pas celui qui sera livré. GitFlow, un modèle de branches avec des branches develop et release de longue durée publié par Vincent Driessen en 2010, a été largement adopté ; en 2020, Driessen a ajouté une note indiquant que les équipes qui livrent en continu, comme pour les applications web, devraient envisager un flux de travail plus simple. Les équipes qui doivent travailler sur de gros changements dans le tronc utilisent deux techniques : les feature flags, qui masquent un comportement inachevé, et le branch by abstraction, qui introduit une interface devant l’ancienne implémentation, construit la nouvelle derrière elle et bascule quand elle est prête.

Les praticiens sont réellement en désaccord à la marge. Les projets open source qui ont de nombreux contributeurs non fiables s’appuient sur des pull requests de plus longue durée et sur la relecture, et les équipes réglementées ont parfois besoin de branches de version explicites pour l’audit. Le principe qui survit au désaccord est la taille des lots : plus chaque changement est petit, plus il est facile à relire, tester, déployer, diagnostiquer et annuler.

name: delivery
on:
  push:
    branches: [main]
env:
  IMAGE: registry.example.com/food/orders:${{ github.sha }}
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make lint test              # fast feedback first
      - run: docker build -t "$IMAGE" . && docker push "$IMAGE"
  staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh staging "$IMAGE" && ./smoke-test.sh staging
  production:
    needs: staging
    runs-on: ubuntu-latest
    environment: production            # can require an approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh production "$IMAGE" --canary 5

Stratégies de déploiement

Une stratégie de déploiement décide comment la nouvelle version remplace l’ancienne en production, et donc combien d’utilisateurs une mauvaise version peut toucher avant d’être arrêtée. Les stratégies diffèrent par l’infrastructure supplémentaire qu’elles exigent, la rapidité de leur retour arrière et le fait que deux versions tournent ou non en même temps. Chaque fois que deux versions tournent en même temps, elles doivent être compatibles avec les données et les messages l’une de l’autre : c’est le prix de toutes les stratégies sauf la recréation.

Le déploiement bleu-vert a été décrit par Martin Fowler en 2010, qui en attribue le mérite à Dan North et Jez Humble ; le déploiement canari, nommé d’après les canaris que les mineurs emportaient pour détecter le gaz, a été présenté par Danilo Sato sur le même site en 2014. Dans Kubernetes, les mises à jour progressives sont intégrées ; les déploiements bleu-vert et canari viennent généralement d’un contrôleur de livraison progressive (Argo Rollouts, Flagger) ou d’un service mesh et du routage pondéré de la Gateway API. Sur les plateformes managées, les fonctionnalités équivalentes s’appellent traffic splitting (répartition du trafic) ou deployment slots (emplacements de déploiement).

Séparer le déploiement de la mise en production avec des feature flags

Le déploiement installe une nouvelle version du logiciel dans un environnement ; la mise en production rend un comportement accessible aux utilisateurs. Les traiter comme un seul événement fait de chaque déploiement un événement métier, avec toute la nervosité que cela entraîne. Les feature flags (feature toggles) les séparent : le nouveau code est déployé désactivé, et le comportement est mis en production plus tard, progressivement et de façon réversible, en changeant la configuration. L’article de Pete Hodgson Feature Toggles (aka Feature Flags) sur martinfowler.com (2017) distingue quatre catégories selon leur durée de vie et le caractère plus ou moins dynamique de leur décision.

Les flags ont un coût de possession. Chaque flag double les chemins dans le code qu’il protège, ajoute des combinaisons à tester et laisse du code mort une fois sa décision arrêtée. Hodgson recommande de traiter les flags comme un stock : ajouter une tâche de suppression quand un toggle de mise en production est créé, donner aux flags des dates d’expiration, ajouter des tests qui échouent dès qu’un flag a dépassé sa date, et limiter le nombre de flags qui peuvent exister en même temps. La perte de Knight Capital en 2012, décrite en section 1.3, impliquait un flag réaffecté qui a réactivé du vieux code sur un serveur oublié lors d’un déploiement manuel : un rappel de ne jamais réutiliser les noms de flags et de supprimer le code mort derrière les flags dont la décision est arrêtée. À grande échelle, les flags sont servis par un service dédié (des options open source comme Unleash et Flagsmith, des offres commerciales comme LaunchDarkly, ou l’API OpenFeature, indépendante des fournisseurs) afin qu’un changement se propage en quelques secondes et soit tracé.

Les changements de base de données dans le pipeline

Le code peut revenir en arrière en quelques secondes ; les données, non. Un déploiement qui renomme une colonne, puis fait l’objet d’un retour arrière, laisse l’ancien code face à un schéma qu’il ne comprend pas. La réponse, traitée en détail dans l’évolution des schémas, consiste à rendre chaque changement de schéma rétrocompatible avec la version du code en cours d’exécution, au moyen de l’expansion-contraction : ajouter d’abord la nouvelle structure, déployer du code qui écrit dans les deux et lit l’une ou l’autre, faire le backfill, basculer les lecteurs, et ne supprimer l’ancienne structure que dans une version ultérieure, une fois que plus rien ne l’utilise.

Dans le pipeline, cela signifie que les migrations sont des artefacts versionnés qui s’exécutent comme une étape à part, avant le déploiement du code qui en a besoin, et qu’elles sont testées sur une copie des données de la taille de la production, afin qu’un verrou sur une grande table soit découvert en staging plutôt qu’à l’heure du déjeuner. Les étapes destructrices (suppression de colonnes ou de tables) sont différées et exécutées séparément, car c’est le seul type de changement qu’un retour arrière ne peut pas annuler. Un contrôle utile dans le pipeline fait échouer le build quand une migration n’est pas additive, sauf si elle est explicitement marquée comme une étape de contraction.

Livraison progressive et analyse canari automatisée

La livraison progressive, un terme popularisé en 2018 par James Governor, du cabinet d’analystes RedMonk, combine les canaris, les feature flags et la vérification automatisée : un changement atteint des publics de plus en plus larges, et à chaque étape, c’est le système, et non une personne qui surveille des tableaux de bord, qui décide de continuer ou non. La décision repose sur l’analyse canari automatisée : les métriques du canari (taux d’erreur, percentiles de latence, saturation, signaux métier comme les commandes passées) sont comparées statistiquement à celles d’une référence. Netflix et Google ont publié en open source leur moteur d’analyse, Kayenta, en 2018 ; Argo Rollouts et Flagger fournissent des étapes d’analyse similaires dans Kubernetes.

Trois détails décident si l’on peut se fier à l’analyse. Comparez ce qui est comparable : une référence neuve de l’ancienne version recevant la même part de trafic évite d’imputer à la nouvelle version des différences dues à des caches froids ou à des redémarrages récents. Ayez assez de trafic : à 5 % d’un service qui traite dix requêtes par minute, une heure de canari voit trente requêtes, trop peu pour détecter un taux d’erreur de 1 % ; les services à faible trafic ont donc besoin de paliers plus longs, d’une charge synthétique ou d’une autre stratégie. Choisissez des métriques liées aux objectifs de niveau de service et aux résultats métier, car une version peut être rapide et sans erreur tout en facturant silencieusement de mauvais frais de livraison.

Retour arrière ou roll forward

Quand une mise en production tourne mal, il y a deux façons d’en sortir. Le retour arrière (rollback) revient à l’artefact précédent, ce qui est rapide et ne demande aucun nouveau code, à condition que la version précédente fonctionne toujours avec les données actuelles et avec les versions des autres services. Le roll forward (correction vers l’avant) fait passer un correctif par le pipeline, ce qui est plus lent mais parfois la seule option, par exemple après une migration de données irréversible ou un changement dont d’autres services dépendent déjà.

Une bonne règle par défaut est revenir en arrière d’abord, diagnostiquer ensuite : rétablir le service avec l’action sûre la plus rapide, puis enquêter sans pression. Corriger vers l’avant sous pression tend à contourner les contrôles du pipeline, et un correctif précipité sur un incident de production est une source classique de l’incident suivant. Le retour arrière n’est une vraie option que s’il est prévu dès la conception : artefacts précédents conservés, changements de schéma compatibles dans les deux sens pendant au moins une version, messages lisibles par les anciens comme par les nouveaux consommateurs, et chemin de retour arrière lui-même exercé régulièrement. Une équipe qui n’est jamais revenue en arrière devrait supposer qu’elle en est incapable.

Mesurer le pipeline

Les métriques DORA de livraison logicielle présentées en section 2.6 (délai de mise en œuvre des changements, fréquence de déploiement, taux d’échec des changements, temps de rétablissement après un déploiement en échec et taux de reprise des déploiements) sont en grande partie des propriétés du pipeline et de l’architecture réunis. Les petits lots et le développement basé sur le tronc raccourcissent le délai et augmentent la fréquence ; les tests automatisés et l’analyse canari font baisser le taux d’échec des changements ; un retour arrière rapide et les flags raccourcissent le temps de rétablissement. Mesurez-les par service, observez les tendances plutôt que des valeurs isolées, et n’en faites jamais des objectifs individuels, ce qui ne fait qu’inviter à tricher.