Architecture de déploiement — Monorepo DDD_Module¶

Projet : gestionFichePaie — Session 20260515

Structure du monorepo¶

DDD_Module/
├── shared-kernel/        ← lib TypeScript partagée (CJS, dist/ committé dans git)
├── BackEnd/              ← Express 5 + Prisma + BullMQ
│   └── Dockerfile        ← contexte racine (inclut shared-kernel)
├── FrontEnd/             ← React + Vite
│   └── Dockerfile        ← contexte racine
├── scripts/
│   └── deploy.sh         ← script de déploiement VPS (versionné dans git)
└── .github/workflows/
    └── deploy.yml        ← GitHub Actions → SSH → deploy.sh

Principe du build Docker (contexte racine)¶

Les deux Dockerfiles sont buildés depuis la racine du monorepo pour accéder à shared-kernel/.

# Depuis deploy.sh
docker build -t gestionfichepaie-backend:latest -f "$PROJECT_DIR/BackEnd/Dockerfile" "$PROJECT_DIR"
#                                                                                      ^^^^^^^^^^^^
#                                                                          contexte = racine du monorepo

shared-kernel : dist/ committé, pas reconstruit dans Docker¶

Le shared-kernel/dist/ est committé dans git (.gitignore contient !dist/ dans shared-kernel/).

Pourquoi : éviter de rebuilder shared-kernel dans chaque Dockerfile (complexité, dépendances croisées). Le dist/ est source de vérité pour BackEnd et FrontEnd.

Conséquence : après toute modification de shared-kernel, rebuilder localement (npm run build dans shared-kernel/) et committer le dist/.

Réseaux Docker¶

Réseau	Rôle
`shared_infra`	Postgres + Redis partagés entre tous les projets du VPS
`gestionfichepaie_default`	Communication interne backend ↔ frontend

Le backend est connecté aux deux réseaux.

Ports¶

Service	Port externe	Port interne
Backend	3902	3000
Frontend	8902	80

deploy.sh — dans le repo, pas dans /opt/¶

scripts/deploy.sh est versionné dans git.

Le workflow GitHub Actions l'appelle après git pull :

su - kanmaber -c "git -C ~/projets/gestionFichePaie pull origin main"
bash /home/kanmaber/projets/gestionFichePaie/scripts/deploy.sh $TARGET

Avantage : toute modification de deploy.sh est déployée en même temps que le code, sans intervention manuelle sur le VPS.

Auto-discovery des routes en production¶

ConfigurationModulaire.ts adapte la découverte selon l'environnement :

modulesBasePath: process.env.NODE_ENV === 'production' ? 'dist' : 'src',
filePattern: process.env.NODE_ENV === 'production' ? '*.module.routes.js' : '*.module.routes.ts',
excludePatterns: [
  'node_modules',
  ...(process.env.NODE_ENV !== 'production' ? ['dist'] : []),  // exclure dist en dev
  // ...
]

En production : cherche *.module.routes.js dans dist/. En développement : cherche *.module.routes.ts dans src/.

Variables d'environnement backend requises¶

Variable	Valeur type	Remarque
`NODE_ENV`	`production`	active le mode prod
`CORS_ORIGIN`	`*` ou domaine	obligatoire — bloque tout si absent
`DATABASE_URL`	`postgresql://fichepaie_user:...`	user en minuscules (PostgreSQL normalize)
`REDIS_HOST`	`shared-redis`	nom du container dans shared_infra
`REDIS_PORT`	`6379`
`REDIS_URL`	`redis://shared-redis:6379`