Où va votre build ? Le chaînon manquant entre le code et la production

Vous venez de compiler votre application. Le build a réussi, les tests passent, et vous avez un bel artefact tout neuf dans un dossier sur votre laptop. Et maintenant ?

Si vous ressemblez à la plupart des équipes qui mettent en place leur premier pipeline, l'étape suivante semble évidente : déployer. Mais il y a un problème caché. Cet artefact sur votre laptop est inutile pour le serveur de production qui se trouve dans un datacenter ou une région cloud. Il ne peut pas plonger dans votre dossier local pour récupérer le fichier. Même si le build a été exécuté sur une machine CI dédiée, la cible de déploiement ne peut toujours pas accéder aux fichiers situés sur le disque local de cette machine.

C'est là que la plupart des conceptions de pipeline rencontrent leur premier vrai obstacle. Vous avez besoin d'un endroit où placer l'artefact, accessible à la fois par le processus de build et par la cible de déploiement.

Le problème du stockage partagé

Pensez à ce qui se passe lorsque vous finissez de préparer un repas pour une fête. Vous ne gardez pas la nourriture dans votre cuisine en espérant que les invités viennent se servir directement sur votre cuisinière. Vous mettez la nourriture sur une table où tout le monde peut l'atteindre.

Les artefacts fonctionnent de la même manière. Le processus de build crée l'artefact. Le processus de déploiement doit le récupérer. Ces deux processus peuvent s'exécuter sur des machines différentes, dans des réseaux différents, à des moments différents. Ils ont besoin d'un emplacement partagé, accessible via le réseau.

Cet emplacement partagé s'appelle un registre d'artefacts ou un référentiel d'artefacts. Son rôle est simple : stocker les artefacts et fournir un moyen de les récupérer. Chaque fois qu'un build se termine, il pousse l'artefact vers ce registre. Plus tard, lorsqu'un déploiement démarre, le serveur cible tire l'artefact depuis le registre et l'exécute.

Le diagramme suivant montre le flux de base :

Voici comment pousser un artefact après un build et le tirer sur une cible de déploiement :

# Sur la machine de build : pousser l'artefact vers le registre
curl -X POST \
  -F "file=@myapp-v1.2.3.jar" \
  https://registry.example.com/upload

# Sur la cible de déploiement : tirer l'artefact depuis le registre
curl -O https://registry.example.com/artifacts/myapp-v1.2.3.jar
flowchart TD A[Machine de build] -->|pousse l'artefact| B[Registre d'artefacts] B -->|tire l'artefact| C[Cible de déploiement] D[Réseau différent] -.-> A E[Réseau différent] -.-> C F[Moment différent] -.-> A G[Moment différent] -.-> C

Plus qu'un simple serveur de fichiers

Un registre ne se contente pas de stocker des fichiers. Il conserve également des métadonnées sur chaque artefact : numéro de version, horodatage de création, et souvent le hash du commit Git qui l'a produit. Ces métadonnées deviennent cruciales quand quelque chose tourne mal en production.

Imaginez que vous déployez la version 2.3.1 et que les utilisateurs commencent à voir des erreurs. Vous devez savoir exactement quelles modifications de code ont été intégrées dans cet artefact. Sans métadonnées liant l'artefact à son commit source, vous en êtes réduit à des suppositions. Avec elles, vous pouvez consulter le diff, identifier le problème et décider de revenir en arrière ou de corriger en avançant.

Certains registres prennent également en charge les labels ou les tags. Vous pouvez taguer un artefact comme "validé-staging" après qu'il a passé les tests d'intégration, ou "prêt-production" après une approbation manuelle. Ces tags aident à automatiser le déploiement des artefacts vers les environnements appropriés.

Le piège de la connectivité

Voici une erreur qui piège de nombreuses équipes : elles configurent un registre dans le cloud, mais leurs serveurs de production tournent dans un réseau privé qui n'a pas accès à l'internet public. Le build pousse les artefacts avec succès, mais lorsque le déploiement tente de les tirer, il échoue avec un timeout de connexion.

Le registre doit être accessible depuis tous les serveurs qui ont besoin de déployer. Si votre environnement de production est isolé, votre registre doit se trouver dans ce même réseau, ou vous devez mettre en place un mécanisme pour synchroniser les artefacts à travers les frontières réseau. Certaines équipes exécutent un proxy ou un miroir local qui met en cache les artefacts provenant d'un registre central. D'autres utilisent un registre prenant en charge les points de terminaison de réseau privé.

Cela semble évident quand vous le lisez, mais il est facile de l'oublier quand vous êtes concentré sur la mise en œuvre complète du pipeline. Vérifiez la connectivité avant de construire tout votre processus de déploiement autour d'un registre que vos serveurs ne peuvent pas atteindre.

L'immutabilité est importante

Un bon registre empêche la modification des artefacts après leur stockage. Cette propriété s'appelle l'immutabilité. Cela signifie que l'artefact que vous stockez aujourd'hui sera identique à celui que vous récupérerez dans six mois.

Pourquoi est-ce important ? Sans immutabilité, vous ne pouvez pas avoir confiance dans ce que vous déployez. Quelqu'un pourrait modifier un artefact après qu'il a passé les tests. Un bug détecté en staging pourrait réapparaître en production parce que l'artefact a changé entre les environnements. Le débogage devient un cauchemar car vous n'êtes jamais sûr que l'artefact en production correspond à celui qui a été testé.

L'immutabilité impose un workflow propre : chaque changement produit un nouvel artefact avec une nouvelle version. Il n'y a pas de "mise à jour sur place" pour les artefacts. Si vous devez corriger quelque chose, vous reconstruisez et créez une nouvelle version. Cette discipline rend les déploiements prévisibles et les retours en arrière simples.

Découpler le build du déploiement

Avec un registre en place, le build et le déploiement deviennent deux processus séparés qui peuvent s'exécuter indépendamment. Le build se termine, pousse l'artefact, et passe à autre chose. Le déploiement peut avoir lieu quelques minutes, heures ou jours plus tard. L'artefact reste en sécurité dans le registre, en attendant d'être récupéré.

Ce découplage est puissant. Vous pouvez builder et tester un artefact le matin, le faire examiner par un ingénieur senior l'après-midi, et le déployer en production le soir quand le trafic est faible. Chaque étape se déroule selon son propre calendrier, mais elles font toutes référence au même artefact immuable.

Cela signifie aussi que vous pouvez reconstruire et redéployer le même artefact sur plusieurs environnements. L'artefact qui a passé les tests de staging est exactement le même que celui qui va en production. Pas de recompilation, pas de builds spécifiques à un environnement, pas de surprises du type "ça marche sur ma machine".

Une checklist pratique rapide

Lors de la configuration de votre registre d'artefacts, vérifiez ces points :

  • Accessibilité : Chaque serveur qui doit déployer peut-il atteindre le registre via le réseau ?
  • Immutabilité : Le registre empêche-t-il la modification des artefacts stockés ?
  • Métadonnées : Chaque artefact porte-t-il les informations de version, d'horodatage et de commit source ?
  • Rétention : Combien de temps conservez-vous les anciens artefacts ? Avez-vous une politique de nettoyage ?
  • Authentification : Qui peut pousser des artefacts ? Qui peut les tirer ? Les identifiants sont-ils renouvelés régulièrement ?

L'essentiel à retenir

Le résultat de votre build a besoin d'un foyer accessible à la fois par le processus de build et par les cibles de déploiement. Un registre d'artefacts fournit ce stockage partagé, conserve les métadonnées pour la traçabilité, impose l'immutabilité pour que vous puissiez avoir confiance dans ce que vous déployez, et découple le build du déploiement pour que chaque étape puisse se dérouler selon son propre calendrier. Sans lui, votre pipeline n'est qu'un build qui se termine par un fichier posé sur une machine que personne ne peut atteindre.