Une dépendance que vous ne pouvez pas reconstruire n'est pas vraiment vôtre

L'affirmation

Le logiciel qui fait tourner votre entreprise n'est fiable que dans la mesure de votre capacité à le reconstruire depuis le source, et la plupart des équipes découvrent bien trop tard qu'elles ne le peuvent pas. L'application se déploie bien tant que les serveurs existants continuent de tourner, mais les versions exactes qui la faisaient fonctionner n'ont jamais été enregistrées, la construction dépend de la configuration du portable d'un développeur, ou un paquet critique a disparu de l'internet — et le jour où il vous faut reconstruire de zéro, sur une nouvelle machine, après une panne, vous constatez que vous ne pouvez pas reproduire la chose que vous exécutez depuis des années. Une construction que vous ne pouvez pas reproduire est un passif déguisé en système fonctionnel.

Pourquoi « ça tourne » n'est pas « vous pouvez le reconstruire »

Un système qui tourne et un système reproductible sont des propriétés différentes, et l'écart entre eux est invisible jusqu'à ce qu'il soit fatal. Le système qui tourne fonctionne parce qu'une combinaison précise de versions de paquets, de bibliothèques système et de configuration s'est trouvée réunie une fois et n'a pas été dérangée. Personne n'a noté cette combinaison, parce qu'on n'avait pas à le faire — elle tournait déjà. Puis le serveur tombe, ou il faut passer à une seconde machine, ou un correctif de sécurité force une reconstruction, et vous tentez de recréer un état que personne n'a enregistré, de mémoire et par conjecture, sous pression, pendant que le système est en panne.

Les modes de défaillance sont précis et courants : la construction tire « la dernière » version d'une dépendance, qui est désormais une version différente et incompatible de celle qui fonctionne ; un paquet dont la construction a besoin a été retiré de son registre par son auteur ; la construction ne réussit que sur la machine d'une personne à cause de quelque chose installé là il y a des années que personne n'a documenté. Chacun de ceux-ci transforme une reconstruction de routine en un projet d'archéologie.

Figez chaque version, exactement

Le fondement de la reproductibilité est que votre construction spécifie la version exacte de tout ce dont elle dépend, et jamais le mot « dernière ». Un fichier de verrouillage enregistre la version précise de chaque dépendance directe et transitive, pour qu'une construction aujourd'hui et une construction dans deux ans se résolvent en paquets identiques :

# versionnez le fichier de verrouillage ; c'est le releve de ce qui fonctionne
package-lock.json      # npm
poetry.lock            # python
Cargo.lock             # rust
# la regle : le fichier de verrouillage est versionne, et la construction l'utilise tel quel
npm ci                 # installe exactement le verrouillage, echoue s'il derive

La distinction entre npm install et npm ci capte tout le principe : le premier peut mettre à jour des versions, le second installe exactement ce que dit le fichier de verrouillage et refuse si la réalité a dérivé du relevé. Votre construction devrait utiliser la forme stricte, pour qu'une construction reproduise l'état enregistré ou échoue bruyamment — jamais ne substitue silencieusement une version différente.

Rapatriez ce que vous ne pouvez pas vous permettre de perdre

Figer une version n'aide pas si le paquet lui-même disparaît, et les paquets disparaissent — les auteurs les suppriment, les registres les retirent, les entreprises ferment. Pour les dépendances sans lesquelles votre construction ne peut vraiment pas avancer, gardez votre propre copie plutôt que de croire que le registre public la servira toujours. Cela peut être un miroir de registre privé qui met en cache tout ce qu'utilisent vos constructions, ou le rapatriement des dépendances critiques directement dans votre dépôt. Le test est : si le registre public était injoignable une semaine, pourriez-vous encore construire et déployer ? Pour tout ce dont la réponse doit être oui, il vous faut une copie que vous contrôlez.

Rendez l'environnement de construction lui-même reproductible

Des dépendances applicatives figées sont minées si l'environnement autour — le système d'exploitation, le moteur du langage, les bibliothèques système — est ce qui se trouvait sur la machine de construction. La construction devrait déclarer son environnement aussi explicitement qu'elle déclare ses dépendances, pour produire le même résultat quelle que soit la machine qui l'exécute. Une image de conteneur bâtie depuis une base figée est la façon courante d'y parvenir :

FROM node:22.9.0-bookworm-slim   # fige, pas node:latest
# le moteur, le SE et les dependances de l'app sont maintenant tous specifies

Avec l'environnement figé, la construction cesse de dépendre de l'état accidentel d'une machine particulière, et « ça marche sur mon portable » cesse d'être une catégorie de problème, car il ne reste aucun état propre à un portable dont elle puisse dépendre.

Stockez l'artefact, pas seulement la recette

Même une construction parfaitement reproductible prend du temps à s'exécuter, et pendant un incident le temps est la chose qui vous manque. Gardez les artefacts construits — les images de conteneur, les binaires compilés — dans un registre que vous contrôlez, étiquetés par version, pour que récupérer une version reconnue bonne soit tirer et exécuter un artefact existant plutôt que le reconstruire depuis le source sous pression. La construction reproductible est votre garantie de pouvoir recréer n'importe quelle version ; l'artefact stocké est ce qui vous laisse la déployer en secondes quand l'alternative est une construction de dix minutes exécutée les mains tremblantes.

Le test qui le prouve

La seule façon de savoir que votre construction est reproductible est de la reproduire, délibérément, avant d'y être forcé. Prenez une machine vierge — sans aucun des réglages accumulés par votre équipe — et construisez et déployez votre application à partir de rien d'autre que le dépôt de source. Si cela fonctionne, vous avez une véritable capacité de reprise, et vous avez documenté, en le faisant, exactement ce qu'exige la reprise. Si cela échoue, vous avez trouvé les pièces manquantes un après-midi calme plutôt que pendant une panne, ce qui est tout le propos de l'exercice. Une construction qui a été reproduite de zéro sur une machine vierge est une construction que vous avez réellement ; une qui n'a jamais tourné que sur les serveurs où elle est née est une construction que vous empruntez à la chance.