Pourquoi ne jamais reconstruire un artefact après qu'il a passé les tests

Imaginez ceci : votre équipe vient de passer trois heures à exécuter des tests sur un build en staging. Tout est vert. Le responsable de la release dit : « Super, reconstruisons-le pour la production. » Quelqu'un déclenche une nouvelle compilation, empaquette le résultat et déploie. Une heure plus tard, la production génère des erreurs qui ne sont jamais apparues en staging. Le code est le même, mais l'artefact est différent. Vous venez de perdre la seule garantie qui comptait : ce que vous avez testé n'est pas ce qui est en cours d'exécution.

Ce scénario se produit plus souvent que la plupart des équipes ne l'admettent. La solution n'est pas un meilleur outil de build. C'est une discipline qui commence dès le lancement de votre pipeline.

Construire une fois, utiliser partout

La première règle de la gestion des artefacts est simple : construire exactement une fois. Cet artefact unique voyage à travers tous les environnements, du développement à la production. Pas de recompilation. Pas de réempaquetage. Pas de « laisse-moi le reconstruire avec le flag de production ».

Le diagramme suivant illustre comment un artefact unique se déplace à travers les environnements par promotion, sans jamais être reconstruit :

Il ne s'agit pas de paresse. Il s'agit de certitude. Quand vous reconstruisez, vous introduisez des variables. Peut-être que le serveur CI avait un état de cache différent. Peut-être qu'une dépendance a été mise à jour entre deux builds. Peut-être que l'agent de build avait une version de bibliothèque légèrement différente. N'importe lequel de ces éléments peut produire un binaire qui se comporte différemment de celui que vous avez testé.

Le même artefact qui a passé toutes les vérifications en staging doit être le même artefact qui s'exécute en production. Si vous ne pouvez pas le garantir, vous ne pouvez pas faire confiance à vos tests.

Donner à chaque artefact une identité traçable

Vous devez être capable de répondre à une question à propos de n'importe quel artefact : d'où vient-il ? Cela signifie que chaque artefact doit porter une identité qui le relie au code source exact, à l'exécution exacte du pipeline, et au moment exact de sa création.

Automatisez cela. Ne laissez jamais un humain attribuer un numéro de version. Votre pipeline doit générer un identifiant de build qui combine :

• Un horodatage du début du build
• Un numéro de build séquentiel
• Le hash du commit Git

Avec cette combinaison, vous pouvez prendre n'importe quel artefact de votre registre et savoir précisément quel commit l'a produit, quel pipeline l'a construit et quand. Pas de supposition. Pas de « je pense que ça vient de la release de la semaine dernière ».

Placer les artefacts dans un registre, pas sur un serveur

Quand un build se termine, l'artefact doit quitter immédiatement le serveur CI. Il ne doit pas rester dans un espace de travail, sur le portable d'un développeur ou dans un dossier réseau partagé. Il va directement dans un registre central d'artefacts.

Le registre devient la source unique de vérité. N'importe quelle équipe, n'importe quel pipeline, n'importe quel environnement sait exactement où trouver l'artefact dont il a besoin. Sans registre, vous aurez du mal à répondre à des questions simples comme « Quelle version de l'artefact est actuellement en production ? » ou « Puis-je reproduire le build exact de la release du mois dernier ? »

Un registre vous donne aussi le contrôle. Vous pouvez définir des permissions, appliquer des politiques de rétention et suivre qui a accédé à quoi. Ces capacités deviennent critiques à mesure que votre équipe grandit et que plusieurs pipelines commencent à consommer des artefacts.

Promouvoir, ne pas reconstruire

Une fois qu'un artefact a passé tous les tests en staging, le pipeline ne doit pas le reconstruire pour la production. Au lieu de cela, il promeut l'artefact existant. La promotion signifie modifier les métadonnées : mettre à jour un label, déplacer l'artefact vers un dossier différent, ou le marquer comme « prêt pour la production » dans le registre.

Le fichier lui-même reste identique. Les mêmes octets qui ont traversé tous les tests sont les mêmes octets qui s'exécuteront en production. C'est le cœur des déploiements reproductibles.

Mais comment savoir si l'artefact n'a pas été corrompu ou falsifié entre les tests et la promotion ? C'est là que la vérification entre en jeu.

Vérifier avant de faire confiance

Avant qu'un artefact ne passe en production, votre pipeline doit vérifier son intégrité. La méthode la plus courante est la vérification par somme de contrôle.

Quand le build se termine, le pipeline calcule une somme de contrôle de l'artefact, généralement avec SHA256. Cette somme de contrôle est stockée avec les métadonnées de l'artefact. Avant la promotion, le pipeline recalcule la somme de contrôle et la compare à la valeur stockée. Si elles ne correspondent pas, quelque chose s'est mal passé. Le fichier a peut-être été corrompu pendant le stockage, ou quelqu'un a peut-être modifié l'artefact sans autorisation.

Pour des garanties plus fortes, utilisez la signature. Le pipeline signe l'artefact avec la clé privée de l'équipe. Pendant la promotion, le registre vérifie la signature. La signature fait plus que vérifier l'intégrité. Elle prouve que l'artefact a été réellement construit par votre pipeline officiel, et non par quelqu'un d'autre qui a eu accès à votre registre. Cela compte quand plusieurs équipes partagent le même registre ou quand des artefacts sont extraits de sources externes.

Le filet de sécurité

Ces quatre disciplines fonctionnent ensemble comme un filet de sécurité :

• Construire une fois garantit la cohérence entre les environnements.
• Le versionnage automatique garantit la traçabilité jusqu'au code source.
• Le registre central garantit l'accessibilité pour tous les consommateurs.
• La promotion sans reconstruction garantit la reproductibilité.
• La vérification garantit la confiance dans l'intégrité de l'artefact.

Si l'un de ces éléments est faible, votre pipeline a une faille. Vous pouvez avoir une belle configuration CI/CD sur le papier, mais en pratique, vous êtes à une reconstruction d'un incident de production que vos tests n'ont jamais détecté.

Une checklist rapide pour votre pipeline

Si vous mettez en place ou révisez la gestion des artefacts, parcourez ceci :

• Le pipeline construit-il chaque artefact exactement une fois par commit ?
• Chaque artefact a-t-il un identifiant de version automatisé et traçable ?
• Les artefacts sont-ils poussés vers un registre central immédiatement après le build ?
• Le pipeline promeut-il les artefacts en modifiant les métadonnées, et non en reconstruisant ?
• Une vérification de somme de contrôle ou de signature est-elle effectuée avant la promotion en production ?

Si vous avez répondu non à l'une de ces questions, vous avez une lacune qui mérite d'être corrigée avant votre prochaine release.

Ce que cela signifie pour votre équipe

Quand votre équipe suit systématiquement ces disciplines, le pipeline devient prévisible. Vous arrêtez de vous demander si la production exécute le même code qui a passé les tests. Vous arrêtez de chercher des différences entre les builds. Vous commencez à faire confiance à votre processus de déploiement.

Et une fois cette confiance établie, vous pouvez vous concentrer sur la couche suivante : comment les artefacts circulent à travers les environnements, qui a l'autorité de promouvoir, et comment les politiques sont appliquées automatiquement. Mais rien de tout cela n'a d'importance si vous ne pouvez pas faire confiance à l'artefact lui-même. Construisez une fois. Promouvez, ne reconstruisez pas. Vérifiez avant de déployer. Tout le reste repose sur cette base.