Skip to main content

​
Le pipeline partagé

Auto-deploy, deploy manuel et rollback appellent tous deploy-stack.yml. Le déploiement est écrit une seule fois.
  • Les images sont taguées avec le SHA7 court, immuable. Aucun build ne pousse staging-latest.
  • Les migrations Prisma tournent dans le job migrate, avant l’update d’image.
  • Le health gate sonde https://api.<audience>.staging.kare-app.fr/health/ready et https://<sub>.staging.kare-app.fr/health. Un target mutant dont le gate n’a résolu aucune URL est considéré comme non gardé et échoue.
  • promote déplace staging-latest seulement pour les composants réellement sur le tag de ce run : un run dépassé ou un déploiement API partiel laisse l’alias en place au lieu de le reculer.
Aucun rollback automatique, ni d’image ni de schéma. Une migration destructive ne peut pas être défaite sans risque — c’est pour cela que la règle expand/contract est obligatoire, voir Migrations. La reprise est rollback.yml, manuelle.

​
Auto-deploy au merge

cd-staging.yml part sur chaque push de main, détecte les composants touchés (dorny/paths-filter) et appelle le stack une fois par composant affecté.
Il ne mute staging que si la variable de repo STAGING_AUTO_DEPLOY_ENABLED vaut exactement true. Sinon le run affiche disabled et réussit sans rien construire ni changer. Garde-la à false pendant un cutover d’infra ou tant qu’un container cible n’existe pas.
Les filtres de chemins incluent les manifestes racine (package.json, yarn.lock, .yarnrc.yml) : les Dockerfiles copient la racine du repo et font l’install dans l’image, donc un bump de lockfile change ce qui est livré.

​
Deploy manuel

Actions → Deploy (manual) → Run workflow. Staging uniquement.

​
Les targets

api fait un seul build, un seul qa-api et une seule migration, puis fan-out des audiences dans la matrice interne — c’est ce que cd-staging utilise pour un changement API.

​
Les targets seed-*

Un seed-* sert à ajouter un front à un stage déjà opérationnel :
1

Seed

Lancer deploy.yml avec target=seed-kare : QA, build, push et création de l’alias staging-latest s’il est absent (il ne déplace jamais un alias existant).
2

Créer le container

tofu apply revu dans infrastructure/ — le container est créé sur staging-latest.
3

Déployer normalement

Ensuite seulement, utiliser front-kare ou pair-kare.
Pour reconstruire un stage entier, c’est le runbook infra qui s’applique, pas seed-* : voir Infrastructure.

​
Rollback

Actions → Rollback → Run workflow. Staging uniquement (le stage est codé en dur dans le workflow). Séquence : parse → preflight (vérifie que toutes les images sélectionnées existent, avant toute mutation) → rollout par composant → sonde HTTP → staging-latest déplacé seulement si le résultat est sain.
Le rollback ne touche pas la base. Ne choisis une image ancienne que si elle est compatible avec le schéma actuel.
Les tags disponibles se lisent dans le registry Scaleway, ou dans le résumé du run de déploiement qui les a poussés.

​
Concurrency

Pas de concurrency au niveau du run de cd-staging : un groupe unique ferait annuler par GitHub le run en attente lors de merges rapprochés, en abandonnant ses déploiements. La sérialisation vit au niveau job sur les jobs mutants (deploy-api-mutate-staging-<audience>, deploy-frontend-mutate-staging-<app>) — c’est ce qui empêche un run cd-staging et un deploy.yml manuel de se courir dessus.