Schéma de développement

Branches

2 branches permanentes

• main : la prod. Ne peut être mis à jour que via une branche de release (et une validation produit). Elle est associée à une version fixe du modèle.
• preprod : notre environnement de dev sur lequel arrive toutes les PR (après code review) non recettées par notre PO. La recette fonctionnelle “rapide” se fait ici. Cette branche risque forcément de contenir des bugs vu que n’importe qui peut merger sans recette fonctionnelle. Elle est associée à latest du modèle.

Une branche temporaire

• release-X-Y-Z : Lorsque l’on est prêt à faire une release, on crée cette branche à partir de preprod. Plus aucune feature ne sera ajoutée à la release par la suite. Elle a les mêmes variables d’env que la prod (y compris la version du modèle). La recette fonctionnelle “approfondie” se fait ici. Les fix de bugs découverts pendant cette recette sont mergés directement dans cette branche. Cette branche est ensuite squash & merge dans main, puis merge dans preprod.

Process

Cycle de vie d’une feature/fix

1. Création d’une branche de travail à partir de preprod. Vous pouvez nommer cette branche comme vous le souhaitez (je prends personnellement le numéro de ticket Notion, mais “certains” ne sont pas fan).
2. Création d’une PR de cette branche vers preprod. La PR se nomme “[NGC-numero-notion]”. Demande de review lorsque l’on estime le travail fait et que les tests e2e passent.
3. Si validation de la PR, plus aucune feature ne doit être ajoutée à la branche (sauf petit fix à la marge demandé dans les commentaires de la review). Elle peut être mergée directement (essayons de ne pas trop trainer pour ne pas avoir 15 merge à faire ensuite)
4. Si demande de modifications revenir à l’étape 2.
5. Une fois que la PR est approuvée par un pair, l’auteur de la PR peut passer la carte Notion dans la colonne “Revue fonctionnelle” et le/la QA désignée peut recetter. Si aucun problème n’est remonté, la PR peut être fusionnée ; si un ou des problème(s) sont remontés, retour à l’étape 3.

Cycle de vie d’une release

1. Validation de notre PO ⇒ on met à jour le numéro de release dans package.json sur preprod puis on crée une branche de release. Cette branche se nomme release-X-Y-Z (et pas releaseX.Y.Z ou releaseXYZ)
2. On crée une PR de la branche de release vers main. On pense bien à fixer la version du modèle sur cette branche.
3. Notre PO fait une recette approfondie sur l’url de cette PR.
4. Chaque bug repéré par notre PO donne lieu à un fix (reprendre Cycle de vie d’une feature/fix en remplaçant preprod par release-X-Y-Z)