CI/CD : le pipeline minimal qui évite les mises en production à risque
Mis à jour le
Un pipeline CI/CD utile tient en peu d'étapes : installer les dépendances de façon reproductible, vérifier les types, analyser le code, construire, déployer une préversion, puis contrôler la production. L'objectif n'est pas de tout tester, mais de rendre chaque mise en ligne banale et réversible.
Les étapes, de la moins chère à la plus chère
L'ordre compte : une étape qui échoue tôt économise toutes les suivantes. On commence donc par ce qui est rapide — vérification des types, lint — avant le build et les tests longs.
- Installation à partir du fichier de verrouillage (npm ci), pour que la CI construise exactement ce que vous avez testé.
- Vérification des types et lint : quelques secondes, et une bonne part des régressions arrêtées avant le build.
- Build de production : il échoue sur des erreurs que le mode développement tolère.
- Tests automatisés, limités à ce qui casse réellement en production.
- Déploiement d'une préversion par pull request, puis contrôle de la production après mise en ligne.
Un pipeline est aussi une surface d'attaque
Un workflow dispose de secrets et, potentiellement, d'un droit d'écriture sur le dépôt. Accordez au jeton de la CI les permissions minimales, réservez les secrets aux étapes qui en ont besoin et ne les exposez jamais à du code venu d'un fork.
Les actions tierces s'exécutent avec ces mêmes droits. Les référencer par l'empreinte d'un commit plutôt que par une étiquette modifiable évite qu'une mise à jour malveillante ne s'invite dans votre chaîne de livraison.
Après le déploiement : vérifier, pouvoir revenir en arrière
Un déploiement « réussi » signifie seulement que le build est passé. Un contrôle après mise en ligne — la page d'accueil et une ou deux routes critiques répondent bien 200, et non 500 ou une redirection inattendue — confirme que le site fonctionne réellement.
Enfin, annulez les exécutions devenues obsolètes quand un nouveau commit arrive sur la même branche, et gardez le retour à la version précédente à un clic : un retour arrière rapide vaut mieux qu'un correctif écrit dans l'urgence.
En bref
Quelle différence entre intégration continue et déploiement continu ?
L'intégration continue vérifie automatiquement chaque modification (types, lint, build, tests). Le déploiement continu met en ligne automatiquement ce qui a passé ces vérifications. On peut adopter la première sans la seconde.
Pourquoi utiliser npm ci plutôt que npm install en CI ?
npm ci installe exactement les versions du fichier de verrouillage et échoue si celui-ci ne correspond pas à package.json. Le build de la CI est ainsi reproductible, ce que npm install ne garantit pas.
Que vérifier après un déploiement ?
Au minimum, que les routes critiques répondent avec le code HTTP attendu. Un build réussi ne prouve pas que l'application démarre ni que ses variables d'environnement sont correctes.