Git workflow

Previous Next

Un ticket = une branche = deux MR (main + staging). Les MEP regroupent plusieurs tickets mergés dans main.

Nomenclature

Branches

  • Sous-projets liés à un ticket Jira (dema1n, inspire-v2, article1-connect) : {PROJET_JIRA}-{description-courte-en-kebab-case} (ex: INSP-688-email-profil-ee-cache-car-non-maj, DEM-1019-ajouter-bouton-de-renvoi-des-mails-de-mi)
  • Ce repo racine (infra, docs, config globale, sans ticket) : {type}/{description-courte}, types utilisés : feature, code-qual

Commits

Convention gitmoji : {EMOJI} [{Scope}] {Description}, description à l'infinitif ou au présent, Scope = module/fonctionnalité concernée.

Exemple : 🐛 [Migrations] Remove api_schema from mig # En Français ou en Anglais, pas de consigne

Développement d'un ticket

  1. Nouvelle branche créée depuis main, nommée d'après le ticket Jira
  2. Dev en local, commits, push
  3. Ouverture de deux MR depuis la branche :
  4. Nomenclature de nommage {PROJET_JIRA}-US {DESCRIPTION_FEATURE} (ex: INSP-688 ✨ [EE Incomplets] Envoi d'email aux EE quand leur profil passe en 'caché')
  5. Une vers main, nom de la MR préfixé de [MAIN]
  6. Une vers staging
  7. Lien vers la MR staging envoyé sur Slack
  8. Retours de review en commentaires directement sur la MR GitLab, correctifs poussés sur la branche
  9. Merge de la MR staging → déploiement automatique en environnement staging
  10. Ticket passé au statut Jira "To test in demo"
  11. Recette fonctionnelle par les PO
  12. Une fois la recette validée, merge de la MR [MAIN] vers main

MEP (mise en production)

Une MEP regroupe tous les tickets mergés dans main depuis la dernière mise en production.

  1. Définition de la date de MEP avec les PO (créneau dans l'agenda)
  2. Création d'une MR main → prod, nommée avec le numéro de version (nomenclature semver)
  3. Description de la MR : compte-rendu (CR) des tickets inclus, généré par une task Claude (/release-notes) à partir des messages de commit
  4. Relecture de la MR si possible (vérifier notamment les sujets conflits, migrations, infra, config globale)
  5. Merge de la MR
  6. Création d'un tag git avec le numéro de version → déclenche le déploiement automatique en production
  7. Création d'une release GitLab avec le numéro de version, release notes identiques au CR de la MR
  8. Merge back : prod → main, puis main → staging

Point d’attention : rabbitmq-defs.json

Si la MEP (ou un ticket inclus) modifie article1-connect/rabbitmq-defs.json (queues, exchanges, bindings) :

  • le tag / déploiement applicatif ne réplique pas ces defs sur le RabbitMQ K8s de prod ;
  • après le déploiement (ou en même temps que la MEP), appliquer manuellement les nouveaux bindings/queues sur le Management UI RabbitMQ prod (ou réimporter les defs sur le cluster) ;
  • le mentionner dans le CR de MEP / release notes.

Détail : rabbitmq-definitions.md.

Frontend Infra