Pourquoi ne jamais reconstruire pour la production

Il y a quelques semaines, une équipe avec laquelle je travaillais a rencontré un problème étrange. Leur environnement de staging passait tous les tests. L'équipe QA avait validé. Le product owner avait donné le feu vert. Mais lors du déploiement en production, les utilisateurs ont commencé à voir des erreurs qui n'étaient jamais apparues pendant les tests.

L'équipe a passé deux jours à déboguer. Ils ont comparé les fichiers de configuration, vérifié les variables d'environnement et passé en revue les modifications de code. Tout semblait identique. Finalement, quelqu'un a remarqué que les timestamps de build étaient différents. L'artefact exécuté en production n'était pas le même que celui qui avait passé tous les tests en staging.

C'est une histoire qui se répète chaque jour dans les équipes. La cause racine est presque toujours la même : quelque part entre le staging et la production, quelqu'un a décidé de reconstruire l'application au lieu de promouvoir l'artefact existant.

Les deux chemins : Reconstruire vs. Promouvoir

Chaque pipeline de livraison logicielle comporte plusieurs environnements. Le développement pour essayer de nouvelles fonctionnalités. Le staging pour la vérification par la QA ou les product owners. La production où les utilisateurs réels interagissent avec votre application.

Lorsque vous devez déplacer un artefact d'un environnement au suivant, vous avez deux choix.

Reconstruire signifie prendre le code source d'un commit spécifique et relancer le processus de build pour l'environnement cible. Le pipeline récupère le code, télécharge les dépendances, compile l'application et produit un nouvel artefact.

Le diagramme suivant illustre les deux chemins et leurs résultats :

flowchart TD A[Début : besoin de déployer en production] --> B{Choisir un chemin} B --> C[Reconstruire] B --> D[Promouvoir] C --> E[Récupérer le code source] E --> F[Télécharger les dépendances] F --> G[Compiler l'application] G --> H[Nouvel artefact avec nouveau checksum & timestamp] H --> I[Déployer en production] I --> J[Risque : différent de l'artefact testé] D --> K[Artefact existant dans le registre] K --> L[Marquer comme approuvé pour la production] L --> M[Déployer les mêmes octets en production] M --> N[Certitude : correspond à l'artefact testé]

Promouvoir signifie prendre l'artefact qui existe déjà dans votre registre, celui qui a déjà été construit et vérifié dans un environnement précédent, et le marquer comme approuvé pour l'environnement suivant. Pas de nouveau build. Pas de nouvelle compilation. Juste un changement de métadonnées qui dit "cet artefact est maintenant autorisé en production."

Ces deux approches semblent similaires, mais elles produisent des résultats fondamentalement différents.

Le risque caché de la reconstruction

Lorsque vous reconstruisez pour la production, vous créez un nouvel artefact. Il a un ID de build différent. Un timestamp différent. Et surtout, les dépendances téléchargées lors de ce nouveau build peuvent être différentes de celles utilisées lors du build de staging.

Considérez ce qui se passe lorsque votre processus de build exécute npm install, pip install ou go mod download. Ces commandes contactent des dépôts distants pour récupérer des paquets. Si un mainteneur de paquet a publié une mise à jour mineure entre votre build de staging et votre build de production, votre artefact de production inclura cette mise à jour. Même si le changement est techniquement rétrocompatible, il introduit une différence entre ce que vous avez testé et ce que vous exécutez en production.

Le même risque s'applique à votre chaîne d'outils. Si votre système CI met à jour la version du compilateur, l'image de base ou les outils de build entre les builds, la sortie peut changer de manière subtile. Du code qui compilait parfaitement lors du build de staging pourrait produire des instructions machine différentes lors du build de production.

Vous perdez la certitude que ce qui a été testé est ce qui est exécuté en production. Vous passez de la confiance à l'espoir.

Pourquoi la promotion fonctionne mieux

La promotion élimine cette incertitude. L'artefact est construit une fois, stocké dans votre registre et vérifié en staging. Lorsqu'il passe tous les contrôles, vous le promouvez en production en mettant à jour ses métadonnées ou ses tags. Pas de nouvelle compilation. Pas de nouveau téléchargement de dépendances. Les mêmes octets qui s'exécutaient en staging sont maintenant exécutés en production.

En pratique, la promotion fonctionne généralement via le tagging. Dans un registre de conteneurs, vous pouvez avoir une image taguée comme staging. Après vérification, vous ajoutez un tag production à la même image. L'image elle-même ne change pas. Seules les étiquettes changent. Votre système de déploiement surveille le tag production et récupère l'image lorsqu'il apparaît.

Cette approche simplifie également les rollbacks. Si la nouvelle version cause des problèmes en production, vous pointez vers l'artefact promu précédent. Vous n'avez pas besoin de reconstruire à partir d'un ancien commit, en espérant que les dépendances et la chaîne d'outils d'il y a trois mois soient toujours disponibles. L'ancien artefact est déjà dans votre registre, exactement comme il était lors de sa promotion précédente.

La vérification a toujours lieu avant la promotion

La promotion ne signifie pas sauter la vérification. Avant qu'un artefact ne passe du staging à la production, il doit réussir un ensemble défini de tests. Tests unitaires, tests d'intégration et tous les contrôles spécifiques à l'environnement qui ont du sens pour votre application. Ces tests s'exécutent contre l'artefact en staging. S'ils réussissent, l'artefact est promu. S'ils échouent, l'artefact reste en staging, et l'équipe corrige le code source, reconstruit et recommence le processus de vérification.

La différence clé est que la vérification et la promotion utilisent le même artefact. Vous ne testez pas une version et n'en déployez pas une autre.

Quand la reconstruction peut être nécessaire

Il existe des cas légitimes où la reconstruction est le bon choix. Si votre artefact inclut une configuration spécifique à l'environnement qui doit être intégrée dans le build, vous pourriez avoir besoin de builds séparés pour chaque environnement. Si vos exigences de conformité imposent que les artefacts de production soient construits dans un pipeline séparé et plus sécurisé, vous pourriez devoir reconstruire.

Mais ces cas sont des exceptions, pas la règle. La plupart des équipes peuvent séparer la configuration du code. La plupart des exigences de conformité peuvent être satisfaites en signant les artefacts après la promotion plutôt qu'en les reconstruisant. Si vous vous surprenez à reconstruire régulièrement pour la production, demandez-vous si la raison est une nécessité technique ou simplement une habitude.

Liste de contrôle pratique pour la promotion d'artefacts

Avant de configurer votre workflow de promotion, vérifiez ces points :

  • Votre processus de build produit un seul artefact qui fonctionne dans tous les environnements
  • Votre registre prend en charge le tagging ou les mises à jour de métadonnées sans ré-upload
  • Votre système de déploiement peut surveiller les changements de tags et déclencher des déploiements
  • Votre processus de rollback référence les artefacts précédemment promus, pas les anciens commits
  • Votre équipe comprend que "promouvoir" signifie changer les métadonnées, pas reconstruire

L'essentiel à retenir

La décision entre reconstruire et promouvoir se résume à une question : voulez-vous être certain que ce que vous avez testé est ce que vous avez déployé, ou voulez-vous espérer que le nouveau build produise le même résultat ?

La promotion vous donne la certitude. La reconstruction vous donne l'espoir. En production, la certitude compte plus que l'espoir. Construisez une fois, vérifiez minutieusement, promouvez en toute confiance. Vos utilisateurs vous remercieront, et vos sessions de débogage seront plus courtes.