Aller au contenu principal

0055 — Stack de dev reproductible + seeds modulaires

Date : 2026-06-19 Statut : Acté Supersède partiellement : convention « aucun docker-compose, conf DB manuelle » de getting-started.

Contexte​

La mise en route locale reposait sur des étapes manuelles non versionnées : créer à la main le rôle mombiz et la base mombiz_dev, copier le .env, lancer migrations puis seed une à une. Le devstack/init (scripts de création utilisateur/base) vivait hors du repo, sur la machine de dev — perdu au changement de poste. Le seed était un fichier monolithe (scripts/seed.ts, ~380 lignes) mêlant users, cours et inscriptions.

Le projet voisin sukulizi a un socle bien plus robuste : provisionnement DB versionné, npm run setup une-commande, scripts db:* à la racine, seeds modulaires orchestrés en ordre de dépendance, et un db:reset avec garde-fou anti-effacement distant. On aligne MomBiz sur ce modèle, adapté à Prisma (vs Drizzle/RLS côté sukulizi) et au Postgres dev mutualisé déjà en place.

Décision​

1. Provisionnement DB versionné (devstack/, mutualisé)​

On garde la convention « un seul Postgres + un seul Redis mutualisés entre projets » — pas de compose dédié. Mais on versionne le provisionnement spécifique à MomBiz :

devstack/
  init/01-create-users.sql      # rôle mombiz (LOGIN, CREATEDB) — idempotent
  init/02-create-databases.sql  # base mombiz_dev (owner mombiz) — idempotent
  provision.mjs                 # applique init/*.sql au conteneur partagé (Node)
  README.md

npm run db:provision applique ces scripts au conteneur partagé (devstack-postgres par défaut) de façon idempotente — utile car les scripts d'init Postgres ne tournent automatiquement qu'au premier démarrage (volume vide).

2. Setup une-commande​

npm run setup (scripts/setup.mjs, Node cross-platform) enchaîne : .env (+ génération JWT_SECRET), npm install, build des contrats, db:provision, db:deploy, db:generate, db:seed.

3. Scripts db:* à la racine​

ScriptRôle
db:provisionCrée rôle + base sur le Postgres partagé
db:migrateprisma migrate dev (crée/applique une migration)
db:deployprisma migrate deploy (applique sans créer)
db:generateRégénère le client Prisma
db:seedDonnées démo (seed modulaire)
db:resetDrop + migrations + seed, avec garde-fou
db:studioPrisma Studio

4. Seeds modulaires​

apps/api/scripts/seed/ remplace le monolithe :

seed/
  index.ts            # orchestrateur : wipe → users → courses → enrollments
  helpers.ts          # wipe(), hash mot de passe démo
  users.seed.ts       # 1 admin, 2 formatrices, 3 apprenantes (upsert idempotent)
  courses.seed.ts     # 3 cours PUBLISHED + hiérarchie complète + quiz
  enrollments.seed.ts # inscriptions, paiements stub, progression

Ajouter un domaine = un fichier *.seed.ts + une ligne dans index.ts.

5. Garde-fou db:reset​

scripts/db-reset.ts refuse une DATABASE_URL non-locale sauf ALLOW_RESET=1 explicite — évite d'effacer staging/prod par erreur. Reprend le garde-fou sukulizi.

Conséquences​

Positif

  • Mise en route en une commande, reproductible d'un poste à l'autre.
  • Provisionnement DB versionné (plus de scripts perdus hors repo).
  • Seeds extensibles, lisibles, testables par domaine.
  • db:reset sûr par défaut.

Négatif / limites

  • provision.mjs suppose Docker et un conteneur Postgres partagé nommé (surchageable via DEVSTACK_PG_CONTAINER). Provisionnement manuel possible sinon (cf. devstack/README.md).
  • On conserve le modèle mutualisé : pas d'isolation totale par projet (choix assumé, cf. §1). Une bascule vers un compose dédié resterait une future ADR.