Partie 13 — CI/CD & automatiser

⏱️ TL;DR — Jusqu’ici tu déploies à la main : tu te connectes en SSH, tu git pull, tu builds, tu redémarres le service, et tu croises les doigts. Ça marche… jusqu’au jour où tu oublies une étape, où « ça marchait sur ma machine », ou où tu casses la prod un vendredi soir. Cette partie transforme ce rituel manuel en un pipeline automatique, testé et répétable : chaque git push sur main déclenche un enchaînement lint → test → build → déploiement → healthcheck, sans intervention humaine. On part du script de déploiement le plus simple, on l’automatise avec GitHub Actions, on déploie sans coupure par releases avec rollback instantané, et on apprend à gérer les secrets sans jamais les committer. À la fin, un merge sur main met FormaCampus en prod tout seul — et un incident se corrige en un clic.

Le problème qu’on résout

Ton app tourne en prod (Parties 9 à 12). Pour livrer une nouvelle version, tu fais le tour : SSH, git pull, npm ci, npm run build, systemctl restart, et tu vérifies à l’œil que le site répond. Cinq étapes, dans le bon ordre, sans en oublier une, à chaque fois, y compris à 23 h quand tu es fatigué.

C’est exactement là que les erreurs naissent. Une étape sautée, une migration oubliée, un build qui échoue après que tu as déjà coupé le service : et la prod est cassée, sans trace de ce qui s’est passé ni de moyen simple de revenir en arrière.

Le déploiement manuel n’est pas « plus simple », il est plus fragile. Cette partie le remplace par une machine : un pipeline qui exécute toujours les mêmes étapes, dans le même ordre, teste avant de déployer, et garde l’historique de chaque livraison. Le déploiement devient un non-événement — banal, sûr, réversible.

Ce que tu sauras faire à la fin de cette partie

• Distinguer CI (intégration continue) et CD (déploiement continu), et décrire le pipeline idéal.
• Écrire un script de déploiement (deploy.sh) robuste, idempotent, avec set -euo pipefail.
• Comprendre les git hooks (post-receive) pour un déploiement déclenché par git push.
• Construire un workflow GitHub Actions complet qui lint, teste, build, puis déploie sur ton VPS par SSH.
• Déployer sans downtime par releases + symlink (façon Capistrano/Deployer) et revenir en arrière en un instant.
• Comparer blue-green, rolling et releases symlink, et gérer les migrations de base pendant un déploiement.
• Ne jamais committer un secret, et savoir où vivent les secrets (serveur, CI, build-time, runtime) et comment les faire tourner.

Les chapitres

Cette partie industrialise le déploiement. La Partie 14 — Observer & superviser prend le relais : une fois que ça déploie tout seul, il faut savoir si ça tourne bien — logs, métriques, monitoring et alerting.

On commence : Pourquoi le CI/CD — pourquoi le déploiement manuel est un piège, et à quoi ressemble le pipeline qu’on vise.