CI/CD et contrôles mécaniques

3.1 Les mots, d'abord

CI, intégration continue : à chaque changement, des contrôles automatiques se lancent (build, tests, lint) pour attraper les régressions tôt. CD, déploiement ou livraison continue : une fois vérifié, le code s'écoule vers la préprod puis la prod. Un pipeline est cette chaîne d'étapes. Un verrou est tout contrôle automatique capable de bloquer la ligne.

3.2 Ce que l'automatisation coûte, et ce qu'elle garantit

L'automatisation n'est pas gratuite. Chaque contrôle coûte du temps d'exécution, de l'argent en calcul, et de l'attention (un contrôle bruyant finit ignoré). Vous choisissez donc un régime, pas « tous les contrôles ». Un régime léger lance les contrôles pas chers et à forte valeur à chaque changement (est-ce que ça build, est-ce que ça type-check, une passe de style rapide) et garde les coûteux (bout en bout complet, tests de charge) pour les moments qui comptent.

Note honnête, parce que ce livre ne survend pas : sur mes propres produits, une suite de tests automatisée complète dans le pipeline n'est souvent pas branchée dans la première version. C'est un arbitrage précoce assumé, ajouté après le lancement. Ce qui tourne automatiquement : le site se redéploie à chaque push, et le build doit passer sinon rien ne sort. Le backend se déploie à la main, exprès. Ce mélange, automatique sur le site et manuel sur le backend, est un choix stable, pas une corvée inachevée. Dites ce que vous faites et ce que vous ne faites pas.

La version honnête d'un arbitrage a deux moitiés : le nommer comme un choix délibéré, et nommer le déclencheur qui le fera basculer. « Pas encore de suite de tests automatisée dans le pipeline, parce qu'au début une QA manuelle sur une petite surface va plus vite ; on ajoute la suite dès que la surface dépasse ce qu'une personne peut vérifier à la main, ou dès que la première régression atteint un utilisateur. » Un arbitrage avec un déclencheur est un plan. Un arbitrage sans déclencheur est un trou que vous faites passer pour un plan.

3.3 Bloquant ou informatif

Tous les contrôles ne doivent pas bloquer. Certains arrêtent la ligne : le build échoue, rien ne sort. D'autres se contentent d'informer : un avertissement que vous lisez et sur lequel vous tranchez. Sachez lequel est lequel, parce qu'un contrôle que vous croyez protecteur ne fait peut-être que chuchoter.

3.4 Les façons dont un verrou ment, et comment y remédier

C'est la Loi 5 rendue pratique. Un verrou peut passer au vert sans rien protéger. Il analyse la mauvaise zone. Il ne voit que les fichiers déjà enregistrés dans le versionnage, donc du code tout neuf apparaît comme « tout va bien ». Son motif de recherche rate la vraie forme du code. L'exécuteur compte « rien à faire » comme un succès. Une suite de tests existe mais est branchée pour ne tourner nulle part, donc elle passe en ne s'exécutant jamais.

Le remède est une discipline. Avant de faire confiance à un contrôle sur un terrain neuf, faites-le échouer exprès. Puis figez un cas connu-bon et un cas connu-mauvais en tests, pour que le contrôle sache toujours distinguer « fonctionne » de « inerte ». Et gardez-le silencieux : un verrou qui crie au loup finit désactivé par ceux-là mêmes qu'il devait protéger.