Déploiement manuel et CI/CD

Objectifs

À la fin de cette leçon, vous saurez :

• effectuer un déploiement complet à la main, étape par étape ;
• décrire un pipeline CI/CD et ses environnements ;
• comprendre le rollback.

🔗 Pour vous rafraîchir la mémoire : systemd, journalctl et permissions Linux · migrations de schéma · package.json et scripts npm · transactions SQL

Le déploiement manuel : chaque étape compte

Avant d'automatiser, exécutez tout à la main :

ssh serveur
cd /srv/app

git pull                          # 1. récupérer la version à déployer
npm ci                            # 2. dépendances exactes (lockfile)
npm run typecheck && npm test     # 3. vérifier AVANT de couper quoi que ce soit
npm run build                     # 4. produire dist/
npm run db:migrate                # 5. faire évoluer le schéma (transactionnel)
sudo systemctl restart todo       # 6. redémarrer le service

curl -f localhost:3000/api/health # 7. VÉRIFIER — sinon : rollback !

Chaque étape existe pour une raison : tester avant de redémarrer évite de couper un service cassé ; les migrations sont transactionnelles donc rejouables ; la vérification finale est ce qui transforme « je crois que c'est bon » en fait établi. Si l'étape 7 échoue :

git checkout v1.4.2 && npm ci && npm run build && systemctl restart todo

Le rollback est trivial précisément parce que les images/builds sont immuables et l'historique Git propre — toutes les briques posées depuis le début du cursus.

Le pipeline CI/CD

git push
   ↓
CI (GitHub Actions) :
   install → lint → typecheck → tests → build → image Docker → push registry
   ↓ si branche main et tout vert
DEPLOY :
   staging automatique → smoke tests → production (manuel ou auto)

Secrets et environnements

Les secrets vivent dans le gestionnaire de secrets de la CI
et dans le .env du serveur — JAMAIS dans le YAML du pipeline.
Staging et production ont des secrets DIFFÉRENTS.

Le pipeline n'écrit jamais de mot de passe : il référence des variables protégées. Et il ne connaît pas ADMIN_EMAILS ni DATABASE_URL de prod — le serveur les porte.

Exercice

1. Scriptez les 7 étapes en deploy.sh avec set -e (arrêt au premier échec).
2. Écrivez le workflow GitHub Actions qui lint+test+build à chaque push.
3. Ajoutez l'étape de déploiement staging conditionnée à la branche main.
4. Pourquoi les migrations doivent-elles être transactionnelles ?

Résumé

• Manuel d'abord : comprendre avant d'automatiser.
• Pipeline = vérifier, construire, livrer ; staging avant prod.
• Rollback facile grâce aux builds immuables + historique propre.