Skip to main content

​
L’état réel aujourd’hui

Un seul stage est vivant : staging. Les scripts partagés (.github/scripts/_common.sh) n’acceptent que SUPPORTED_STAGES="staging" et infrastructure/ ne contient qu’une seule racine OpenTofu (envs/staging). Les workflows release.yml / hotfix.yml visent prod et définissent le contrat de livraison, mais prod n’existe pas encore : ils échoueront tant que le stage n’a pas été cloné (state, credentials, domaines, secrets).

​
Une image API, quatre audiences

APP_AUDIENCE est lu au démarrage et n’a aucune valeur par défaut : absente ou inconnue, le process crashe immédiatement. La variable est posée par OpenTofu sur chaque container, et par les scripts yarn dev:<audience> en local.

​
Les paires front / audience

Chaque front ne parle qu’à son audience. Un target pair-* déploie les deux ensemble. API : https://api.<audience>.staging.kare-app.fr, sonde de santé /health/ready. Fronts : sonde /health.
pr, kare et provider n’existent que sur staging. Le jour où prod est créée, le target all de prod exclura ces trois composants jusqu’à leur clonage.

​
Qui possède quoi

La frontière est explicite : les ressources container OpenTofu portent lifecycle { ignore_changes = [image] }. Un déploiement de code ne fait jamais de tofu apply, et un tofu apply ne remet jamais une vieille image.

​
Le pipeline unique

Tout déploiement avant (auto ou manuel) passe par deploy-stack.yml : Points non négociables :
  • les migrations Prisma tournent avant le flip d’image ;
  • staging-latest ne bouge qu’après un health gate vert — c’est l’image que OpenTofu utilise à la création d’un container, donc elle doit toujours signifier « dernière image saine » ;
  • aucun rollback automatique : la reprise est rollback.yml, manuel et explicite.

​
Pour aller plus loin

Dev local

Compose, audiences, ports

CI sur les PR

Les gates et le seul check bloquant

Déployer

Auto-staging, deploy manuel, rollback

Infrastructure

OpenTofu, plan revu, bootstrap