Où vivent vos builds : pourquoi chaque artefact a besoin d'un foyer

Imaginez ceci : votre pipeline CI vient de passer au vert. Un développeur demande : "Quel build doit-on déployer en staging ?" Quelqu'un répond : "Celui d'hier, je pense." Une autre personne renchérit : "Non, je l'ai reconstruit localement ce matin. Utilise le mien."

Cette conversation arrive plus souvent que les équipes ne veulent l'admettre. Quand les artefacts vivent sur des laptops, dans des dossiers de workspace CI, ou sur un disque partagé, vous perdez la capacité de savoir de manière fiable ce qui est réellement prêt à être déployé. Le staging peut recevoir une version, la production une autre, et personne ne peut retracer quel artefact a causé l'incident à 2h du matin.

La solution est simple en concept mais cruciale en pratique : vous avez besoin d'un endroit unique et centralisé où chaque résultat de build réside. En termes DevOps, cet endroit s'appelle un registre ou un gestionnaire de dépôts.

Les artefacts se présentent sous différentes formes

Commençons par le type d'artefact familier : un fichier JAR, une archive ZIP, un binaire compilé, ou un package NuGet. Ce sont des artefacts mono-fichier. Des outils comme Nexus, Artifactory, ou les registres de packages intégrés à votre écosystème de langage (npm registry, Maven Central, PyPI) les gèrent bien. Ils stockent le fichier, suivent les versions, et permettent aux pipelines ou aux développeurs de tirer exactement la dépendance dont ils ont besoin.

Considérons maintenant les images conteneur. Une image conteneur n'est pas un fichier unique. Elle est construite à partir de plusieurs couches empilées les unes sur les autres. Vous ne pouvez pas stocker une image conteneur dans un dépôt d'artefacts classique. Elle a besoin d'un registre de conteneurs : Docker Hub, Amazon ECR, Google Container Registry, ou Harbor. Les registres de conteneurs comprennent la structure en couches. Lorsque vous tirez une image, le registre n'envoie que les couches qui n'existent pas déjà sur la machine cible. Cela rend les déploiements plus rapides et économise de la bande passante.

Les images conteneur sont devenues le type d'artefact le plus courant dans les pipelines CI/CD modernes. Mais le principe reste le même, quel que soit le format : le registre est la source unique de vérité pour chaque artefact qui a passé vos builds et tests.

Le registre est le point de transition entre CI et CD

Voici la fonction la plus importante d'un registre dans un pipeline : il marque la frontière entre l'intégration continue et la livraison continue.

Le diagramme suivant oppose le flux correct au flux défaillant qui se produit lorsqu'aucun registre n'existe.

flowchart TD subgraph Correct[Avec Registre] A1[Pipeline CI] -->|pousse artefact avec version| B1[Registre] B1 -->|tire artefact exact| C1[Pipeline CD] C1 --> D1[Staging] C1 --> E1[Production] end subgraph Broken[Sans Registre] A2[Workspace CI] -->|copie manuelle| B2[Laptop] A2 -->|copie manuelle| C2[Disque Partagé] B2 --> D2[Staging] C2 --> E2[Production] D2 -.->|décalage de version| E2 end Correct -.->|contraste| Broken

Regardez le flux. Le travail de la CI se termine au moment où un artefact atterrit dans le registre avec un tag de version clair. Le build est terminé. Les tests sont passés. L'artefact est stocké. La responsabilité de la CI s'arrête là.

La CD commence à partir du registre. La CD ne reconstruit pas l'artefact. Elle tire exactement le même artefact que celui stocké par la CI, puis le déploie dans l'environnement cible. Pas de recompilation. Pas de dépendances différentes. Pas de "Je pense que c'est le même build."

Cette séparation n'est pas seulement technique. Elle concerne la responsabilité. La CI possède la correction du build. La CD possède la correction du déploiement. Si quelque chose casse en production, vous remontez jusqu'à l'artefact exact dans le registre. Vous connaissez sa version, son hash de commit, son timestamp de build. Il n'y a pas de supposition.

Promotion sans modification

Un bon registre permet également la promotion d'artefacts. La promotion est le processus qui consiste à marquer un artefact spécifique comme prêt pour l'environnement suivant. Vous ne modifiez pas l'artefact lui-même. Vous ajoutez des métadonnées.

Par exemple, votre CI produit un artefact tagué 1.2.3-build.45. Cet artefact se trouve dans le registre. Lorsqu'il passe les tests de staging, vous ajoutez un tag : staging. Lorsqu'il passe la validation de production, vous ajoutez un autre tag : production. L'artefact sous-jacent est identique. Seul son statut change.

C'est important car cela maintient une piste d'audit propre. Vous pouvez toujours voir quelle version a été promue vers quel environnement et quand. Sans ce mécanisme, les équipes finissent par reconstruire pour chaque environnement, introduisant des différences subtiles entre ce qui a été testé et ce qui tourne en production.

Ce qui se passe sans registre

Les équipes qui négligent la mise en place d'un registre approprié rencontrent les mêmes problèmes de manière répétée :

  • Les développeurs se demandent quel build déployer.
  • Le staging tourne avec une version différente de celle de la production.
  • Les rollbacks deviennent un jeu de devinettes car personne ne sait ce qui tournait réellement avant.
  • Les scans de sécurité s'exécutent sur certains builds mais pas sur d'autres, faute d'inventaire centralisé.
  • Les audits de conformité se transforment en chaînes d'emails manuelles pour tenter de reconstruire ce qui a été déployé il y a six mois.

Un registre élimine tout cela. Ce n'est pas un luxe. C'est le fondement qui rend les pipelines disciplinés possibles.

Checklist pratique pour configurer votre registre

Si vous configurez un registre pour la première fois, ou si vous révisez votre configuration actuelle, voici une courte checklist :

  • Choisissez le bon type : registre de conteneurs pour les images, dépôt d'artefacts pour les binaires et packages. Certains outils comme Harbor ou Artifactory gèrent les deux.
  • Appliquez l'immuabilité : une fois qu'un artefact est stocké avec un tag de version, n'autorisez pas les écrasements. Un nouveau build obtient une nouvelle version.
  • Définissez des politiques de rétention : tous les builds n'ont pas besoin de vivre éternellement. Gardez les N derniers builds ou les builds des M derniers jours. Archivez ou supprimez le reste.
  • Contrôlez les accès : les pipelines doivent avoir un accès en écriture. Les développeurs et les pipelines CD doivent avoir un accès en lecture. Utilisez des rôles IAM ou des tokens, pas des mots de passe partagés.
  • Taggez les promotions explicitement : utilisez des métadonnées ou des tags pour marquer les artefacts qui sont en staging, en production, ou rollbackés. Automatisez cela dans votre pipeline CD.

L'essentiel à retenir

Un registre n'est pas seulement du stockage. C'est le contrat entre votre processus de build et votre processus de déploiement. Il garantit que ce qui a été construit est exactement ce qui est déployé. Il donne à votre équipe un endroit unique où regarder quand quelque chose tourne mal. Il rend la promotion traçable et les rollbacks fiables.

Configurez votre registre avant votre prochain déploiement. Votre futur vous, en train de déboguer un incident à minuit, vous remerciera.