Workflow Git & MEP

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 conventional commits et gitmoji : {type}(optional scope): {EMOJI} {description}. Scope = module/fonctionnalité concernée.

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

Recommandé si VSCode : cette extension

Scopes inspire-v2 ici

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. Si j'ai créé des migrations, je MAJ le fichier docs/db-changelog.md
4. Ouverture de deux MR depuis la branche :
5. Nomenclature de nommage {PROJET_JIRA}-US {DESCRIPTION_FEATURE} (ex: INSP-688 ✨ [EE Incomplets] Envoi d'email aux EE quand leur profil passe en 'caché')
6. Une vers main, nom de la MR préfixé de [MAIN]
7. Une vers staging
8. Lien vers la MR staging envoyé sur Slack
9. Retours de review en commentaires directement sur la MR GitLab, correctifs poussés sur la branche
10. Merge de la MR staging → déploiement automatique en environnement staging
11. Ticket passé au statut Jira "To test in demo"
12. Recette fonctionnelle par les PO
13. 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. Bien vérifier que le fichier docs/db-changelog.md est à jour par rapport aux migrations ajoutées
6. Merge de la MR
7. Création d'un tag git avec le numéro de version → déclenche le déploiement automatique en production
8. Création d'une release GitLab avec le numéro de version, release notes identiques au CR de la MR
9. Envoi du lien de la release note sur le slack concerné (#dema1n-dev ou #inspire-v2-dev)
10. 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.

Annexes

Gestion des conflits

TLDR : en cas de conflit, on préfère toujours (1) un rebase de la branche source à un merge de la branche cible, (2) une résolution en local → push force sur la branche source.

Cas typique : feature/add-conflicts (basée sur main) a un conflit sur staging. Options :

1. ✅ À faire dans tous les cas en premier lieu :

• Vérifier si on a pas des tickets qu'on peut merger sur main
• Rebase sur origin/main — suffit parfois

2. ✅ Méthode recommandée: Nouvelle branche rebased sur staging

⚠️ Attention à ne pas oublier de répercuter les changements de la branche staging-based sur la branche main-based

Si le rebase sur main n'a pas pas suffi à résoudre les conflits

• git checkout -b feature/add-conflicts-st
• git pull --rebase origin staging

Puis

• Résolution de conflits
• Push + création de MR de feature/add-conflicts-st vers staging
• Fermer la MR de feature/add-conflitcts vers staging

3. ⚠️ Méthode alternative si conflits trop difficiles à résoudre: Nouvelle branche depuis staging + cherry-pick

⚠️ Attention à ne pas oublier de répercuter les changements de la branche staging-based sur la branche main-based

• git log et noter tous les hash de commits dans l'ordre
• git checkout origin/staging && git pull
• git checkout -b feature/add-conflicts-st

• git cherry-pick ${HASH} (un par un)

• Push + création de MR de feature/add-conflicts-st vers staging

• Fermer la MR de feature/add-conflitcts vers staging

4. ⚠️ Méthode à l'arrache, plus rapide et plus risquée pas recommandée : Rebase la branche sur staging

⚠️ Attention à ne pas oublier de rebase la branche sur main juste après avoir merge sur staging

⚠️ Risque non négligeable de récupérer des bouts de staging et de les mettre sur main

• git pull --rebase origin staging
• Push -f + création de MR de feature/add-conflicts-st vers staging
• Merge
• git pull --rebase origin main
• • Push -f + création de MR de feature/add-conflicts-st vers prod

• Push + création de MR de feature/add-conflicts-st vers staging

• Merger la MR de feature/add-conflitcts vers staging

5. ❌ [Non recommandé] Merge staging dans la branche de travail

• L'avantage c'est qu'on résout les conflits en une fois, mais on perd les bénéfice rerere
• après il faudra push staging, ce qui n'est pas une bonne pratique, surtout si nous sommes plusieurs en parallèle
• il nous faudra également gérer la situation sur main

Gestion des conflits merge back main vers staging

• git checkout main && git pull
• git checkout staging && git pull
• git merge main
• Resolve conflit
• git commit
• git checkout feature/merge-main-into-staging

Puis * Push + création de MR de feature/merge-main-into-staging vers staging * Merger la MR de feature/merge-main-into-staging vers staging (normalement merge automatiquement la MR back de main vers staging)

Ajout des changements

git add -p obligatoire pour relire les changements avant de les stager. git add . est à bannir.

Nommage des MR

([MAIN] - ) [{Domaine métier}] - {User story}

Pas de règle stricte, mais mentionner si possible : numéro de ticket, bloc fonctionnel concerné, URL du ticket Jira en description.

Exemple : INSP-559 - Sur la page Profil EE - L'ID de la formation est affichée au lieu du nom