Du commit à la production : comment les outils communiquent dans un pipeline réel

Vous poussez un commit. Et ensuite ?

Si vous avez déjà vu un déploiement bloqué parce que le serveur CI n'a pas reçu la notification, ou parce que quelqu'un a dû copier manuellement un artefact d'un endroit à un autre, vous connaissez la douleur. Les outils sont tous là. Le pipeline est configuré. Mais quelque part au milieu, la chaîne se brise. Quelqu'un doit se connecter en SSH à une machine, exécuter une commande à la main, et espérer que rien ne se passe mal.

C'est le moment où le CI/CD cesse d'être automatisé et devient une collection d'étapes manuelles déguisées en outils.

Le vrai travail d'un pipeline ne réside dans aucun outil en particulier. Il réside dans la façon dont ces outils se connectent. Un commit dans votre dépôt doit déclencher le serveur CI. Le serveur CI doit savoir où envoyer l'artefact terminé. Le registre d'artefacts doit notifier l'outil de déploiement qu'une nouvelle version est prête. Et l'outil de déploiement doit coordonner le processus de migration de base de données avant ou après le démarrage de la nouvelle version.

Cette chaîne de déclencheurs et de flux de données est ce qui fait qu'un pipeline fonctionne réellement. Parcourons-la depuis le début.

La chaîne de déclenchement : chaque outil a deux missions

Chaque outil dans un pipeline joue deux rôles. Il reçoit un déclencheur de l'outil qui le précède, et il envoie un déclencheur à l'outil qui le suit. Si une connexion se brise, le pipeline s'arrête. L'équipe doit intervenir manuellement, et vous revenez exactement au problème que le CI/CD est censé résoudre : des processus manuels lents et sujets aux erreurs.

La chaîne commence par un commit. Un développeur fusionne des modifications dans la branche principale, ou ouvre une pull request qui est fusionnée. Le serveur Git détecte cet événement. Cet événement doit atteindre le serveur CI. Le mécanisme de livraison peut être un webhook, un polling ou un bus d'événements. La méthode importe moins que le fait que le serveur CI sache que du nouveau code l'attend.

Le diagramme de séquence suivant illustre cette chaîne de déclencheurs et de flux de données :

Voici un exemple concret de cette chaîne de déclenchement dans un workflow GitHub Actions :

name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: |
          docker tag myapp:${{ github.sha }} registry.example.com/myapp:${{ github.sha }}
          docker push registry.example.com/myapp:${{ github.sha }}
      - name: Trigger deployment
        run: |
          curl -X POST https://deploy.example.com/api/deploy \
            -H "Authorization: Bearer ${{ secrets.DEPLOY_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"artifact": "myapp", "version": "${{ github.sha }}", "env": "staging"}'

Le serveur CI exécute son pipeline. Cela inclut les étapes de build, de test et de packaging. Le résultat est un artefact. Cet artefact peut être un binaire compilé, une image conteneur, un fichier de configuration ou un package de migration de base de données. Il doit aller dans un registre. Un registre n'est pas simplement un dossier sur un serveur. C'est un système de stockage structuré où chaque artefact a une version, des métadonnées et des informations de provenance sur la façon dont il a été construit.

Maintenant, l'outil de déploiement doit savoir qu'une nouvelle version est disponible. Certains outils de déploiement surveillent le registre directement. D'autres attendent un déclencheur du serveur CI ou un webhook du registre. Dans les deux cas, l'outil de déploiement doit recevoir l'information que la version X de l'artefact Y est prête pour un environnement spécifique.

L'outil de déploiement déploie ensuite vers l'environnement cible. Mais les déploiements d'applications sont rarement isolés. Avant que la nouvelle version ne s'exécute, la base de données a souvent besoin de modifications : une nouvelle colonne, un index modifié ou une migration de données. Les migrations de base de données doivent s'exécuter dans le cadre du déploiement, pas comme une étape manuelle séparée. L'ordre compte. Parfois, la migration doit s'exécuter avant le démarrage de la nouvelle version de l'application. Parfois, elle doit s'exécuter après. Cela dépend si la modification est rétrocompatible.

Une fois le déploiement terminé, le pipeline n'est pas fini. Vous devez vérifier que la nouvelle version fonctionne normalement. Cela peut être un health check, un test de smoke, ou un signal d'observabilité montrant qu'il n'y a pas de pic soudain d'erreurs. Si la vérification échoue, le rollback doit être déclenché automatiquement ou en un clic.

Le flux d'artefacts : les données qui circulent entre les outils

Tout au long de cette chaîne, des données circulent entre les outils. Métadonnées de commit, version d'artefact, statut du pipeline, résultats de test, configuration d'environnement et identifiants pour accéder à chaque outil. Ces données doivent passer d'un outil au suivant sans intervention manuelle.

C'est le flux d'artefacts. Plus le flux d'artefacts est propre, moins il y a d'erreurs causées par des informations perdues en cours de route. Lorsqu'un déploiement échoue parce que quelqu'un a oublié de mettre à jour un fichier de configuration, ou parce que la mauvaise version d'artefact a été déployée, la cause racine est presque toujours un flux d'artefacts brisé.

Un flux d'artefacts bien conçu inclut :

• Un identifiant unique pour chaque artefact qui renvoie au commit exact et à l'exécution du pipeline.
• Une configuration spécifique à l'environnement stockée séparément de l'artefact lui-même, afin que le même artefact puisse être promu de la staging à la production sans être reconstruit.
• Une gestion des identifiants qui permet à chaque outil de s'authentifier auprès de l'outil suivant sans secrets codés en dur.
• Une propagation du statut pour que chaque outil de la chaîne sache si l'étape précédente a réussi ou échoué.

Le pipeline n'est pas toujours linéaire

La chaîne de déclenchement semble linéaire, mais les pipelines réels ne sont pas si simples. Parfois, un seul commit déclenche plusieurs pipelines simultanément : un pour l'application, un pour l'infrastructure, un pour la base de données. Ou plusieurs commits s'accumulent avant de déclencher un déploiement. Certaines équipes utilisent un modèle de branche de release où les commits sont regroupés et déployés ensemble. D'autres déploient chaque commit directement en production.

Le modèle de déclencheurs et de flux de données détermine comment votre pipeline se comporte sous pression. Si vous choisissez des outils sans comprendre comment ils vont se connecter, vous vous retrouvez avec un pipeline qui fonctionne en démonstration mais qui casse en production. L'outil qui a l'air génial sur le papier pourrait ne pas bien s'intégrer avec votre registre d'artefacts. L'outil de déploiement qui gère les conteneurs à merveille pourrait n'avoir aucun support pour les migrations de base de données.

C'est pourquoi la sélection des outils devrait commencer par la chaîne, pas par les fonctionnalités individuelles. Cartographiez comment un commit devient un service en cours d'exécution en production. Identifiez chaque point de passage. Ensuite, évaluez les outils en fonction de la façon dont ils gèrent ces passages.

Le risque de la prolifération d'outils

Lorsque chaque équipe choisit ses propres outils sans coordination, le résultat n'est pas un pipeline fluide. C'est une prolifération d'outils. Une équipe utilise Jenkins. Une autre utilise GitHub Actions. L'équipe base de données a son propre outil de migration. L'équipe infrastructure utilise Terraform avec un backend d'état différent. Chaque outil fonctionne en isolation, mais les connecter nécessite des scripts personnalisés, des étapes manuelles et beaucoup de connaissances tribales.

La prolifération d'outils n'est pas seulement un problème de maintenance. C'est un problème de fiabilité. Chaque intégration personnalisée est un point de défaillance. Chaque passage manuel est un endroit où des erreurs se produisent. L'objectif n'est pas d'utiliser le même outil pour tout. L'objectif est d'avoir une chaîne de déclenchement et un flux d'artefacts cohérents, quels que soient les outils que vous choisissez.

Liste de contrôle pratique pour connecter les outils

Avant de finaliser une sélection d'outils, parcourez cette liste de contrôle pour chaque point de passage dans votre pipeline :

• Comment le serveur Git notifie-t-il le serveur CI d'un nouveau commit ?
• Comment le serveur CI pousse-t-il l'artefact vers le registre ?
• Comment l'outil de déploiement apprend-il l'existence d'une nouvelle version d'artefact ?
• Comment l'outil de déploiement déclenche-t-il les migrations de base de données ?
• Comment le pipeline vérifie-t-il que le déploiement a réussi ?
• Comment le rollback est-il déclenché, et inclut-il le rollback de la base de données ?
• Quelles données circulent entre chaque paire d'outils, et sont-elles transmises automatiquement ?

Si l'un de ces passages nécessite qu'une personne fasse quelque chose manuellement, vous avez trouvé une lacune qui causera des problèmes tôt ou tard.

L'essentiel à retenir

Un pipeline n'est aussi fort que sa connexion la plus faible. Les outils que vous choisissez importent moins que la façon dont ils se transmettent les déclencheurs et les données. Commencez par cartographier la chaîne du commit à la production. Identifiez chaque passage. Ensuite, choisissez des outils qui s'intègrent dans cette chaîne, pas des outils qui ont l'air impressionnants isolément. Le meilleur pipeline n'est pas celui qui a le plus de fonctionnalités. C'est celui où un commit circule jusqu'à la production sans que personne ait à s'arrêter pour comprendre quoi faire ensuite.