Aller au contenu principal

Déploiement

LeBoard dispose d'un CI/CD complètement automatisé. Tout push vers la branche master déclenche une chaîne de quality gates et de déploiement via GitHub Actions.

CI/CD GitHub Actions​

Le workflow est défini dans .github/workflows/deploy.yml.

Déclencheur​

  • Branche : master uniquement
  • Événement : push

Étapes du pipeline​

Job quality (bloquant)​

S'exécute en premier. En cas d'échec, le déploiement est interdit.

1. Checkout code
2. Setup Node 24 + cache npm
3. npm ci
4. npx prisma generate (client Prisma 7 dans generated/)
5. npx tsc --noEmit
6. npm test (jest)

Node 24 est la version sur laquelle les tests sont vérifiés, comme chez LeHub ; le runtime de production reste node:22-alpine.

Erreurs bloquantes :

  • Échec typecheck → build échoue.
  • Échec linter → build échoue.
  • Échec test → build échoue.

Job deploy (dépend de quality)​

S'exécute après quality seulement si succès. SSH sur le VPS et redéploie.

1. Checkout code (repo local CI)
2. SSH vers VPS (credentials: host, user, key)
3. set -e  (toute commande en échec arrête le script)
4. cd [LeBoard-repo-dir] && git pull origin master
5. docker compose build --no-cache app
6. Récupère l'IP et le mot de passe Postgres depuis le .env de LeHub (base partagée)
7. npx prisma@7.10.1 migrate deploy
8. docker compose up -d --no-deps app
9. docker image prune -f
Le délai de l'action SSH

Le build --no-cache dépasse régulièrement les 10 minutes accordées par défaut à l'action SSH : un run a déjà échoué en « Run Command Timeout » après le build mais avant le redémarrage du conteneur, laissant l'ancienne image en service. Le délai est désormais porté à 30 minutes.

Les chemins exacts et les commandes serveur sont dans LeRunbook.

Après déploiement réussi :

  • Conteneur app tourne avec la dernière version.
  • Nginx reverse proxy (host) envoie les requêtes vers le conteneur app.

Vérifier que le déploiement est passé​

  1. Commit deployé : push vers master → regarder GitHub Actions, onglet « Workflows » → chercher le workflow Deploy pour ce commit.
  2. Status : ✅ all checks passed = succès ; ❌ = échec (consulter les logs du workflow GitHub).
  3. Logs applicatifs : en cas d'échec ou pour diagnostic, les accès au serveur et les commandes de consultation des logs se trouvent dans LeRunbook.
  4. Page à recharger : la version new est active dès la fin du step 8 du deploy. Attention : les assets CSS/JS en cache navigateur peuvent être obsolètes. Force-reload : Ctrl+Shift+R (Chrome/Firefox).

Architecture déploiement​

┌─────────────────────────────────────────────────┐
│  GitHub (repo fresquesystemique/LeBoard, master)│
└──────────────────────┬──────────────────────────┘
                       │ push
                       ▼
        ┌──────────────────────────────┐
        │   GitHub Actions (workflow)  │
        │  1. Quality (typecheck, lint)│
        │  2. Deploy (SSH VPS)         │
        └──────────────┬───────────────┘
                       │ git pull + build
                       ▼
    ┌───────────────────────────────────────────┐
    │   VPS (board.fresquesystemique.org)      │
    │  ├─ Docker container: app (Next.js)      │
    │  ├─ PostgreSQL (shared with LeHub)       │
    │  ├─ Nginx (reverse proxy, host)          │
    │  └─ Socket.io (custom server)            │
    └───────────────────────────────────────────┘

Dockerfile​

Le Dockerfile utilise :

  • Image de base : Node.js (version pinée en repo)
  • Next.js standalone output : compilation self-contained (pas de serveur Next externe)
  • Prisma engine : linux-musl-openssl-3.0.x (pinné dans schema.prisma)
  • Custom server : server.ts lance Next.js + Socket.io sur le même port

Output : image prête à run npm run start (lance le serveur custom).

Docker Compose​

Le fichier docker-compose.yml définit :

  • Service app : conteneur Next.js + Socket.io
  • Port : écoute locale, reverse proxy externe gère le TLS
  • Network : hub_network (partagé avec LeHub pour accès DB)
  • Labels maintenant.* : routing et certificats TLS gérés automatiquement

Commandes serveur (LeRunbook)​

Les commandes manuelles (SSH, docker compose, systemctl, etc.) appartiennent à LeRunbook (repo privé) :

  • SSH vers VPS
  • Logs Docker (docker compose logs app)
  • Redémarrage manual app
  • Nettoyage Docker
  • Certificat Let's Encrypt renouvellement
  • Accès à la base PostgreSQL

Aucune de ces commandes ne doit être documentée ici (données sensibles).

Ne pas déployer à la main

LeBoard dispose d'un CI/CD qui redéploie automatiquement sur push. Lancer en plus un déploiement manuel (SSH + docker compose) provoque une collision : deux processus tentent de modifier le conteneur en même temps, causant des erreurs ou un état incohérent.

Procédure correcte :

  1. Commit + push vers master (local).
  2. Attendre le workflow GitHub Actions (5–10 min).
  3. Vérifier les logs GitHub et les logs app (voir LeRunbook pour les commandes).
  4. Recharger page navigateur (F5 ou Ctrl+Shift+R).

Si le déploiement échoue : consulter les logs GitHub (job quality ou deploy) et LeRunbook pour les commandes de récupération.

Rollback​

En cas de problème post-déploiement :

  1. Revert sur GitHub : git revert HEAD + push vers master.
  2. Attendre le redéploiement : le workflow se déclenche avec la version précédente.
  3. Alternativement (immédiat mais non idéal) : procédure manuelle sur le serveur (voir LeRunbook pour l'accès et les commandes).

Environnements additionnels​

Il n'y en a plus : dev.board a été supprimé le 20 août 2026.

Ne pas déployer à la main, ni en même temps qu'un autre projet

LeBoard a un vrai CI/CD qui redéploie sur push vers master. Lancer en plus un déploiement manuel provoque une collision Docker (constaté le 18 juillet 2026). Et deux builds Docker concurrents sur le VPS, même pour deux projets différents, ont déjà verrouillé containerd : espacer les déploiements de LeBoard, LeHub et LeSite.

Pour un chantier qui touche LeHub et LeBoard, déployer le Hub d'abord : LeBoard lit ce que le Hub expose (versions de cartes, images de diapositives relayées).

Considérations performance​

  • Quality gates : ~2–3 min (tests, typecheck, lint).
  • Docker build : ~1 min (dépend du cache Docker).
  • Migration Prisma : quelques secondes (dépend du nombre de migrations + taille DB).
  • Redémarrage app : ~5 sec (Socket.io reinit, connexion HTTP probe).

Total temps déploiement : ~5–7 minutes du push au new code en prod.

Problèmes courants​

Migration Prisma échoue au déploiement​

  • Cause : schéma incompatible avec la base prod.
  • Solution : tester npx prisma migrate deploy localement avant de push.
  • Si déjà en prod : voir LeRunbook pour rollback DB.

Conteneur app reste exited après déploiement​

  • Vérifier les logs du conteneur (docker compose logs app).
  • Causes communes : variable d'env manquante, port déjà utilisé, erreur startup Node.
  • Solution : diagnostic via LeRunbook, corriger la cause, puis repush vers master pour retrigger le déploiement automatique.

Socket.io affiche GET /socket.io/?... 404​

  • Cause : Socket.io serveur n'écoute pas (serveur custom server.ts n'a pas démarré).
  • Vérifier : les logs du conteneur doivent afficher "Socket.io server listening on port 3000".
  • Solution : vérifier que npm run start démarre le serveur custom (pas next start).

Assets CSS/JS obsolètes après déploiement​

  • Cause : cache navigateur.
  • Solution : force-reload page (Ctrl+Shift+R ou Cmd+Shift+R sur Mac).

Nginx reverse proxy renvoie 502 Bad Gateway​

  • Cause : conteneur app inaccessible.
  • Diagnostic et solutions (commandes serveur, etc.) : voir LeRunbook.

Vérifications après déploiement​

Checklist pour vérifier qu'un déploiement est sain :

  1. Page board charge : https://board.fresquesystemique.org/b/[token] affiche le plateau.
  2. Socket.io connecté : Network tab du navigateur montre WebSocket actif (pas 404).
  3. Cartes se chargent : images WebP s'affichent (recto/verso).
  4. Tempo réel fonctionnel : drag une carte → apparaît chez autres participants dans < 200ms.
  5. Aucune erreur console : vérifier la console navigateur (F12 → Console).

Secrets et variables en production​

Les variables d'env de production sont stored dans le .env du VPS (fichier sensible) et passées au conteneur Docker via docker compose up. Aucune de ces valeurs ne doit figurer dans le repo (.env.example suffit pour documenter la structure).

Voir LeRunbook pour l'accès au fichier .env du VPS et la procédure de renouvellement des secrets.