Pourquoi votre pipeline a besoin d'une stratégie de stockage d'artefacts solide

Vous venez de terminer la compilation de votre application. Tous les tests sont passés. Les scans de sécurité n'ont rien trouvé. Le journal de build affiche un chèque vert immaculé. Il est maintenant temps de déployer. Mais lorsque vous ouvrez le tableau de bord de déploiement, vous réalisez que vous n'avez aucune idée de l'artefact à utiliser. Le serveur de build a déjà nettoyé son espace de travail. Le développeur qui a lancé le build est en congé. Il ne reste qu'un vague souvenir : "le build a réussi".

Ce scénario est plus courant que la plupart des équipes ne l'admettent. Le build fonctionne, mais l'artefact disparaît. Ou pire, le pipeline de déploiement reconstruit l'artefact à partir de zéro en production, en utilisant une version différente d'une dépendance, produisant quelque chose qui n'a jamais été testé.

Le problème n'est pas le build. Le problème est que l'artefact a été traité comme un fichier temporaire, et non comme un livrable vérifié qui doit être stocké, étiqueté et suivi.

Ce que signifient réellement "Packager" et "Publier"

Lorsque votre pipeline termine les tests et les scans, il entre dans une phase que de nombreuses équipes expédient : le packaging et la publication. Ces deux étapes transforment un build réussi en un actif réutilisable.

Le packaging est le processus de conversion de votre code vérifié en un format exécutable dans votre environnement cible. Le format dépend de ce que vous construisez :

• Pour les applications conteneurisées, le packaging signifie créer une image de conteneur.
• Pour les applications Java, cela signifie produire un fichier JAR ou WAR.
• Pour les bibliothèques JavaScript ou Python, cela signifie créer un package que npm ou pip peut installer.
• Pour l'infrastructure, cela peut signifier générer un module Terraform validé ou un modèle CloudFormation.

La publication est l'action d'envoyer cet artefact packagé vers un registre ou un référentiel où il pourra être récupéré ultérieurement par les pipelines de déploiement. Un registre n'est pas qu'un simple bucket de stockage. C'est un système structuré qui maintient vos artefacts organisés, versionnés et découvrables.

Voici un extrait YAML minimal qui montre comment un pipeline CI package une image de conteneur et la publie avec une balise de version unique :

- name: Build and tag Docker image
  run: |
    docker build -t myregistry.com/myapp:1.0.0-b20240315-a1b2c3d .

- name: Push image to registry
  run: |
    docker push myregistry.com/myapp:1.0.0-b20240315-a1b2c3d

Les images de conteneur vont dans des registres de conteneurs comme Docker Hub, Amazon ECR ou Harbor. Les packages d'application vont dans des référentiels d'artefacts comme Nexus, Artifactory ou GitHub Packages. Les modules d'infrastructure vont dans des registres de modules ou des dépôts Git avec un étiquetage approprié.

L'élément clé qui fait ou défait cette phase

Le versioning n'est pas optionnel. Chaque artefact que vous publiez doit avoir une version unique et traçable. Il ne s'agit pas de suivre le versioning sémantique parce que cela fait professionnel. Il s'agit de pouvoir répondre à une question : "Qu'est-ce qui tourne exactement en production en ce moment ?"

Si votre artefact est étiqueté latest ou stable, vous ne pouvez pas répondre à cette question. Ces étiquettes changent avec le temps. Elles ne vous disent rien sur les modifications de code qu'elles contiennent. Lorsqu'un bug apparaît en production et que vous devez remonter jusqu'au commit qui l'a introduit, une étiquette comme latest ne vous donne aucune information.

Une bonne chaîne de version combine une version sémantique avec des métadonnées de build. Quelque chose comme 1.2.3-b20240315-a1b2c3d vous indique le numéro de version, la date de build et le hash du commit. C'est suffisant pour retracer l'artefact jusqu'au code source exact, au job de build exact et aux résultats de test exacts.

Les métadonnées sont votre filet de sécurité

Une chaîne de version seule est utile, mais elle ne suffit pas. Chaque artefact publié doit transporter des métadonnées qui enregistrent :

• Le hash du commit qui a déclenché le build
• Le nom de la branche
• Le numéro du build
• Le résumé des résultats des tests
• Qui a déclenché le build

Pour les images de conteneur, ces métadonnées vont dans les labels. Pour les fichiers de package, elles vont dans le manifeste ou un fichier de métadonnées compagnon. Ces métadonnées transforment votre artefact d'une boîte noire en un actif documenté. Lorsque quelqu'un demande "Cet artefact a-t-il passé tous les tests requis ?", vous pouvez pointer vers les métadonnées et prouver que oui.

Pourquoi c'est important pour la confiance dans le déploiement

Une fois que votre artefact est packagé, versionné et publié avec des métadonnées, votre pipeline de déploiement peut le récupérer en toute confiance. L'étape de déploiement devient une opération simple : prendre la version X de l'artefact, la déployer dans l'environnement Y.

Sans cette base, le déploiement devient un jeu de devinettes. Les équipes finissent par reconstruire des artefacts dans les environnements de production parce que la sortie de build originale a disparu. Reconstruire en production est dangereux. Le build pourrait utiliser une version de dépendance différente, un compilateur différent ou une image de base différente. Le résultat est un artefact qui n'a jamais été testé, qui tourne dans un environnement où les échecs font le plus de dégâts.

Un artefact correctement stocké élimine ce risque. L'artefact qui a passé tous les tests est exactement le même artefact qui est déployé. Pas de reconstructions. Pas de surprises.

Options de registre courantes

Vous n'avez pas besoin d'une solution d'entreprise coûteuse pour bien faire les choses. L'important est de choisir un registre qui correspond à votre stack et de l'utiliser de manière cohérente.

• Images de conteneur : Docker Hub, Amazon ECR, Google Artifact Registry, Harbor, ou tout registre conforme à OCI.
• Packages d'application : Nexus, Artifactory, GitHub Packages, GitLab Package Registry, ou des registres spécifiques à un langage comme npm ou PyPI.
• Modules d'infrastructure : Terraform Cloud, Git avec des tags sémantiques, ou un registre de modules dédié.

Le registre lui-même importe moins que la façon dont vous l'utilisez. Un registre simple avec un versioning strict et des métadonnées est meilleur qu'un registre sophistiqué où tout le monde pousse des artefacts avec des étiquettes aléatoires.

Une checklist rapide pour votre pipeline

Si vous mettez en place ou révisez votre étape de packaging et publication, parcourez ces vérifications :

• Chaque artefact a une version unique qui inclut un hash de commit ou un numéro de build.
• Aucun artefact n'est publié avec une étiquette comme latest pour une utilisation en production.
• Les métadonnées (hash de commit, branche, numéro de build, statut des tests) sont attachées à chaque artefact publié.
• Le serveur de build ne nettoie pas les artefacts immédiatement après la fin du build.
• Le pipeline de déploiement récupère les artefacts depuis le registre, ne les reconstruit jamais.
• Le registre a des politiques de rétention qui empêchent la suppression accidentelle des artefacts de production.

Et ensuite

Avec votre artefact stocké en toute sécurité et traçable, la prochaine étape est le déploiement. Mais avant de continuer, prenez un moment pour vérifier que votre registre est suffisamment bien organisé pour supporter les rollbacks. Si vous devez revenir à une version précédente, pouvez-vous trouver l'artefact exact du déploiement de la semaine dernière ? Si la réponse est non, votre stratégie de stockage a encore des lacunes.

Un artefact bien stocké est le fondement de déploiements reproductibles et dignes de confiance. Sans lui, chaque déploiement comporte un risque caché. Avec lui, vous pouvez déployer en sachant que ce que vous exécutez est exactement ce que vous avez testé.