meta données pour cette page
  •  

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Prochaine révision		Révision précédente
certif:procedure:develop:gestionversionpratique [2026/08/11 17:45] – créée nicolascertif:procedure:develop:gestionversionpratique [2026/08/12 13:38] (Version actuelle) – nicolas
Ligne 1: Ligne 1:
 +|{{:undo-2.svg?30|}} [[certif:do#procedures|Retour au Dossier Organisationnel]]||
 +|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[certif:procedure:develop:gestionversion]]\\ [[https://interface.logeas-web.fr/RapportsRelease|Informations sur la version en cours]]|
 +
 ====== Guide pratique — Cycle de release, étape par étape ====== ====== Guide pratique — Cycle de release, étape par étape ======
  
-//Document complémentaire à [[certif:procedure:develop:gestionversion|Procédure de Gestion des Versions]] — celui-ci répond à la question « qu'est-ce que je fais, concrètement, à chaque étape ? ». Destiné au développeur et au chef de projet, pas à un usage certification.//+//Document complémentaire à [[certif:procedure:develop:gestionversion|Procédure de Gestion des Versions]] — celui-ci répond à la question « qu'est-ce que je fais, concrètement, à chaque étape, qui le fait, et où ? ». Destiné au développeur et au chef de projet, pas à un usage certification.// 
 + 
 +===== Où se lancent ces commandes ===== 
 + 
 +''/fusion-dev'', ''/release-beta'', ''/release-client'' et ''/rapport-tests-qualite'' sont des **commandes Claude Code** (l'assistant IA installé sur le poste de développement), pas des commandes shell classiques. Elles se tapent directement dans l'interface Claude Code (CLI ou extension), pas dans un terminal Git Bash / PowerShell nu. 
 + 
 +  * **Poste concerné :** celui qui a un checkout local de ''logeas-web'' **et** accès au dossier ''D:\Developpements\VersionPublic\ExecutablesWindows\'' (pour les versions des composants Galaxie LoGeAs dans le rapport de release). 
 +  * **Dossier de travail :** toujours la racine du dépôt ''logeas-web'' (ou ''logeas-cartographie'' pour la dernière étape de ''/release-client''). 
 +  * **Branche active au moment de lancer la commande :** 
 +    * ''/fusion-dev'' : peu importe la branche de départ, la commande fait elle-même le ''checkout'' vers la branche de version. 
 +    * ''/release-beta'' et ''/release-client'' : doivent être lancées **sur la branche de version** (ex. ''11.0.25''), pas sur une branche personnelle. 
 + 
 +===== Qui fait quoi ===== 
 + 
 +^ Étape ^ Qui décide de lancer ^ Qui exécute ^ 
 +| 1. Travail personnel | Développeur (son propre rythme) | Développeur | 
 +| 2. ''/fusion-dev'' | Développeur (son travail est prêt) | Développeur | 
 +| 3. ''/release-beta'' | Chef de projet ou développeur senior (juge la branche stable) | Développeur ou chef de projet — l'un ou l'autre peut techniquement lancer la commande | 
 +| 4. ''/release-client'' | **Chef de projet** (validation métier que la beta est bonne à livrer) | Développeur ou chef de projet | 
 +| Copie manuelle vers le serveur (test ou client) | — | Personne ayant accès au bureau à distance du serveur concerné | 
 + 
 +**En résumé :** le développeur porte les étapes 1 et 2 seul. À partir de l'étape 3, c'est une décision d'équipe/de chef de projet de passer à l'étape suivante — l'exécution technique de la commande peut rester déléguée au développeur, mais le feu vert est côté chef de projet, en particulier pour l'étape 4 (on livre au client). 
 + 
 +----
  
 ===== Vue d'ensemble ===== ===== Vue d'ensemble =====
  
-{{:certif:procedure:develop:cycle-release-schema.svg?900|Vue d'ensemble du cycle de release}}+{{:certif:procedure:develop:cycle-release-schema.svg?1200|Vue d'ensemble du cycle de release}}
  
-^ Étape ^ Qui / quoi ^ Commande ^ +^ Étape ^ Décision ^ Où ^ Commande ^ 
-| 1. Travail personnel | Développeur, à la main | (aucune — voir détail plus bas) | +| 1. Travail personnel | Développeur | Poste dev, branche perso | (aucune — voir détail plus bas) | 
-| 2. Intégration | Développeur | ''/fusion-dev'' | +| 2. Intégration | Développeur | Claude Code, ''logeas-web'' | ''/fusion-dev'' | 
-| 3. Beta | Développeur ou chef de projet | ''/release-beta'' | +| 3. Beta | Chef de projet | Claude Code, ''logeas-web'', branche de version | ''/release-beta'' | 
-| 4. Release client | Chef de projet (validation finale) | ''/release-client'' |+| 4. Release client | Chef de projet | Claude Code, ''logeas-web'' puis ''logeas-cartographie'' | ''/release-client'' |
  
 +==== Autres commandes "utiles" ====
 +^Contexte^Commande^Explication^
 +|logeas-Web.fr\\ "D:\Developpements\Sources\NewInterfaces\logeas-web"|<code>ng build --configuration "production,beta"</code>|Génère une version de test de l'interface dans "D:\Developpements\VersionPublic\LogeasWeb-Test\browser" sans passer par les test, la publication, les tags... sauvage quoi !!|
 +|logeas-Web.fr\\ "D:\Developpements\Sources\NewInterfaces\logeas-web"| <code>ng build --configuration production</code>|Génère une version de l'interface release dans "D:\Developpements\VersionPublic\LogeasWeb\browser"\\ Ne bump pas la version (package.json reste à la version courante)\\ Ne régénère pas version.ts (donc l'écran "info version" affichera des infos obsolètes/incohérentes)\\ Ne tague pas la branche git (donc aucune traçabilité de ce qui a été déployé)\\ Écrase directement ce que voient les vrais utilisateurs de production|
 ---- ----
  
Ligne 18: Ligne 48:
  
 **Déclencheur :** en continu, dès qu'on commence à développer quelque chose. **Déclencheur :** en continu, dès qu'on commence à développer quelque chose.
 +
 +**Qui :** le développeur, seul.
 +
 +**Où :** son poste, terminal ou client Git, dans ''logeas-web'', sur sa branche personnelle.
  
 **Ce qu'on fait, à la main :** **Ce qu'on fait, à la main :**
Ligne 31: Ligne 65:
 **À vérifier soi-même avant de committer :** **À vérifier soi-même avant de committer :**
   * Rien de sensible n'est ajouté (secrets, fichiers de config locale, ''dist/'', ''coverage/'').   * Rien de sensible n'est ajouté (secrets, fichiers de config locale, ''dist/'', ''coverage/'').
-  * Si le changement touche en réalité un comportement partagé (``DGService``, composants génériques), le code doit vivre dans ``logeas-lib``, pas ici.+  * Si le changement touche en réalité un comportement partagé (''DGService'', composants génériques), le code doit vivre dans ''logeas-lib'', pas ici.
  
 ---- ----
Ligne 38: Ligne 72:
  
 **Déclencheur :** le travail sur la branche personnelle est prêt à rejoindre le tronc commun. **Déclencheur :** le travail sur la branche personnelle est prêt à rejoindre le tronc commun.
 +
 +**Qui :** le développeur qui a fait le travail (ou toute personne de l'équipe).
 +
 +**Où :** Claude Code, dans ''logeas-web''.
  
 **Ce que la commande fait, dans l'ordre :** **Ce que la commande fait, dans l'ordre :**
Ligne 62: Ligne 100:
  
 **Déclencheur :** la branche de version est jugée stable, prête pour un tour de validation interne. **Déclencheur :** la branche de version est jugée stable, prête pour un tour de validation interne.
 +
 +**Qui décide :** chef de projet ou développeur senior. **Qui exécute :** développeur ou chef de projet.
 +
 +**Où :** Claude Code, dans ''logeas-web'', **sur la branche de version** (pas sur une branche perso).
  
 **Ce que la commande fait, dans l'ordre :** **Ce que la commande fait, dans l'ordre :**
Ligne 75: Ligne 117:
     * lit la version des 4 composants de la Galaxie LoGeAs directement sur les exécutables compilés (''D:\Developpements\VersionPublic\ExecutablesWindows\'')     * lit la version des 4 composants de la Galaxie LoGeAs directement sur les exécutables compilés (''D:\Developpements\VersionPublic\ExecutablesWindows\'')
     * écrit ''src/assets/releases/X.Y.Z.W.html'' + met à jour ''manifest.json''     * écrit ''src/assets/releases/X.Y.Z.W.html'' + met à jour ''manifest.json''
-  - Commit dédié « Preparation version X.Y.Z.W » (``package.json`` + ``version.ts`` + le rapport généré)+  - Commit dédié « Preparation version X.Y.Z.W » (''package.json'' + ''version.ts'' + le rapport généré)
   - ''git tag -a X.Y.Z.W_beta''   - ''git tag -a X.Y.Z.W_beta''
   - ''git push'' + ''git push origin <tag>''   - ''git push'' + ''git push origin <tag>''
Ligne 92: Ligne 134:
  
 **Déclencheur :** la beta a été validée (ou directement si aucune beta n'est jugée nécessaire pour ce cycle). **Déclencheur :** la beta a été validée (ou directement si aucune beta n'est jugée nécessaire pour ce cycle).
 +
 +**Qui décide :** **chef de projet** — c'est la décision de livrer au client. **Qui exécute :** développeur ou chef de projet.
 +
 +**Où :** Claude Code, dans ''logeas-web'' (étapes 1 à 6), puis dans ''logeas-cartographie'' pour la relecture/le commit du rapport qualité (étape 7).
  
 **Ce que la commande fait, dans l'ordre :** **Ce que la commande fait, dans l'ordre :**
Ligne 101: Ligne 147:
     * ''ng build --configuration production'' — sortie vers ''LogeasWeb''     * ''ng build --configuration production'' — sortie vers ''LogeasWeb''
   - ''node scripts/release-report.js release'' — même mécanique qu'en beta   - ''node scripts/release-report.js release'' — même mécanique qu'en beta
-  - Commit dédié « Preparation version X.Y.Z » (``package.json`` + ``version.ts`` + le rapport)+  - Commit dédié « Preparation version X.Y.Z » (''package.json'' + ''version.ts'' + le rapport)
   - ''git tag -a X.Y.Z_release''   - ''git tag -a X.Y.Z_release''
   - ''git push'' + push du tag   - ''git push'' + push du tag
-  - **''/rapport-tests-qualite''** — uniquement à cette étape, jamais en beta : régénère le rapport qualité NF dans ``logeas-cartographie`` (dépôt frère, pas ``logeas-web``), à partir d'une exécution réelle des tests de ``logeas-web`` **et** ``logeas-lib``+  - **''/rapport-tests-qualite''** — uniquement à cette étape, jamais en beta : régénère le rapport qualité NF dans ''logeas-cartographie'' (dépôt frère, pas ''logeas-web''), à partir d'une exécution réelle des tests de ''logeas-web'' **et** ''logeas-lib''
  
 **À vérifier après coup :** **À vérifier après coup :**
   * Le build est bien présent dans ''D:\Developpements\VersionPublic\LogeasWeb\browser\''.   * Le build est bien présent dans ''D:\Developpements\VersionPublic\LogeasWeb\browser\''.
   * Le tag ne rentre pas en collision avec un tag ''_release'' déjà existant.   * Le tag ne rentre pas en collision avec un tag ''_release'' déjà existant.
-  * Le rapport qualité NF (``logeas-cartographie``) a bien été régénéré, relu, et **proposé au commit** — jamais commité automatiquement, dans aucun des deux dépôts.+  * Le rapport qualité NF (''logeas-cartographie'') a bien été régénéré, relu, et **proposé au commit** — jamais commité automatiquement, dans aucun des deux dépôts.
  
 **Ce qui reste manuel :** copie vers le serveur client (bureau à distance). **Ce qui reste manuel :** copie vers le serveur client (bureau à distance).
 +
 +----
 +
 +===== Cas particulier — Basculer vers une version mineure en cours de cycle =====
 +
 +**Quand :** la branche de version en cours (ex. ''11.0.25'') a accumulé plus que de simples correctifs — nouvelles fonctionnalités, évolution de structure de base, ou tout ce qui correspond à la définition du chiffre **Minor** dans la [[certif:procedure:develop:gestionversion|procédure de référence]]. On veut alors que la prochaine version publiée porte un numéro mineur (''X.Y+1.0'') plutôt qu'un simple correctif (''X.Y.Z+1'').
 +
 +**Aucun script à modifier :** ''scripts/version.js'' détermine le numéro cible en comparant le **nom de la branche** au ''X.Y.Z'' actuel de ''package.json'' — peu importe si c'est le 2ᵉ ou le 3ᵉ chiffre qui change, dès que le nom de branche est « supérieur », c'est traité comme un nouveau cycle et le saut est automatique.
 +
 +**Procédure :**
 +
 +  - Se mettre à jour sur la branche de version en cours :
 +    <code>
 +git checkout 11.0.25 && git pull
 +</code>
 +  - Créer la nouvelle branche mineure **depuis sa pointe** (conserve tout le travail déjà accumulé, betas comprises) :
 +    <code>
 +git checkout -b 11.1.0
 +git push -u origin 11.1.0
 +</code>
 +  - **Ne pas supprimer ni réécrire l'ancienne branche** (''11.0.25'') : elle garde son historique et ses tags beta déjà publiés (ex. ''11.0.25.1_beta''). C'est une exception volontaire à la règle « pas de ''X.Y.Z'' orphelin » de la procédure de référence — cette branche ne débouchera jamais sur un tag ''_release'', ce qui vaut la peine d'être noté quelque part pour ne pas s'interroger plus tard.
 +  - **Prévenir l'équipe** : à partir de maintenant, ''/fusion-dev'' cible ''11.1.0'', pas ''11.0.25''. Quiconque a encore du travail en cours vers l'ancienne branche doit basculer dessus.
 +  - Rien à changer côté ''package.json'' : au prochain ''/release-beta'' sur ''11.1.0'', le script constate que ''package.json'' est encore à l'ancien numéro (ex. ''11.0.25.1'') et que la branche ''11.1.0'' lui est supérieure → nouveau cycle détecté automatiquement → saut direct à ''11.1.0.1''.
  
 ---- ----
Ligne 117: Ligne 186:
 ===== Aide-mémoire : qui fait quoi, sous le capot ===== ===== Aide-mémoire : qui fait quoi, sous le capot =====
  
-{{:certif:procedure:develop:guide-pratique-detail.svg?900|Détail des commandes internes par étape}}+{{:certif:procedure:develop:guide-pratique-detail.svg?1200|Détail des commandes internes par étape}} 
 + 
 +---- 
 + 
 +===== Équivalences SourceTree des commandes Git ===== 
 + 
 +Toutes les commandes Git listées ci-dessus sont exécutées automatiquement par les commandes Claude Code — vous n'avez normalement rien à taper à la main. Ce tableau sert pour les cas où on doit reproduire une étape manuellement (dépannage, vérification, ou si on préfère l'interface graphique) : 
 + 
 +^ Commande Git ^ Équivalent dans SourceTree ^ 
 +| ''git fetch'' | Bouton **Fetch** (barre d'outils du haut) | 
 +| ''git checkout <branche>'' | Onglet **Branches** (panneau de gauche) → double-clic sur la branche | 
 +| ''git pull'' | Bouton **Pull** | 
 +| ''git status'' | Onglet **File status** — visible en permanence, pas besoin de le lancer | 
 +| ''git add <fichiers>'' | Onglet **File status** → cocher les fichiers à inclure dans le prochain commit | 
 +| ''git commit -m "..."'' | Bouton **Commit** → saisir le message dans la zone de texte | 
 +| ''git merge --no-ff <branche>'' | Clic droit sur la branche à fusionner (dans le graphe ou l'onglet Branches) → **Merge [branche] into [branche courante]** → cocher « Create a commit even if merge resolved via fast-forward » | 
 +| ''git tag -a X.Y.Z_release -m "..."'' | Clic droit sur le commit dans le graphe → **Tag...** → cocher **Annotated tag**, saisir le nom et le message | 
 +| ''git push'' | Bouton **Push** → dans la boîte de dialogue, cocher aussi les **tags** à pousser (case « Push all tags » ou sélection du tag spécifique) — sinon le tag reste local | 
 +| ''git log <a>..<b>'' | Sélectionner la branche dans le graphe et lire l'historique visuellement ; le format exact utilisé par ''/fusion-dev'' (un séparateur technique par commit) est interne au script, pas à reproduire à la main | 
 + 
 +**Point d'attention SourceTree spécifique aux tags :** SourceTree ne pousse pas les tags automatiquement avec un ''push'' classique — il faut explicitement cocher le tag dans la fenêtre de push, ou faire un push dédié sur le tag après coup. C'est une source d'erreur fréquente (tag créé localement mais jamais visible sur ''origin'').
  
 ---- ----
Ligne 124: Ligne 213:
  
   * **Confondre « beta » et « alpha »** : il n'y a que deux étapes outillées de génération, beta et release. Pas de troisième étape intermédiaire.   * **Confondre « beta » et « alpha »** : il n'y a que deux étapes outillées de génération, beta et release. Pas de troisième étape intermédiaire.
-  * **Lancer ''npm run build'' à la main pour un simple test de compilation** : ça déclenche le bump de version (``prebuild``). Pour juste vérifier que ça compile sans effet de bord, utiliser ''ng build'' directement (c'est ce que fait ''/fusion-dev'').+  * **Lancer ''npm run build'' à la main pour un simple test de compilation** : ça déclenche le bump de version (''prebuild''). Pour juste vérifier que ça compile sans effet de bord, utiliser ''ng build'' directement (c'est ce que fait ''/fusion-dev'').
   * **Oublier que le rapport qualité NF ne se met à jour qu'en release**, pas en beta — si besoin d'un état des lieux ponctuel entre deux releases, relancer ''/rapport-tests-qualite'' manuellement.   * **Oublier que le rapport qualité NF ne se met à jour qu'en release**, pas en beta — si besoin d'un état des lieux ponctuel entre deux releases, relancer ''/rapport-tests-qualite'' manuellement.
   * **Croire que le déploiement est automatique** : à aucune étape le contenu n'est copié sur un vrai serveur — c'est toujours une action manuelle, via bureau à distance.   * **Croire que le déploiement est automatique** : à aucune étape le contenu n'est copié sur un vrai serveur — c'est toujours une action manuelle, via bureau à distance.
 +  * **Pousser un commit sans pousser le tag associé (SourceTree)** : voir l'encadré ci-dessus — un tag local qui n'existe pas sur ''origin'' ne sert à rien pour l'équipe.
  
 ---- ----
  
-//Document généré le 11 août 2026, à mettre à jour si le contenu des commandes ''/fusion-dev'', ''/release-beta'', ''/release-client'' ou ''/rapport-tests-qualite'' évolue.//+//Document généré le 11 août 2026, mis à jour le 12 août 2026 (ajout du cas particulier de bascule vers une version mineure) — à mettre à jour si le contenu des commandes ''/fusion-dev'', ''/release-beta'', ''/release-client'' ou ''/rapport-tests-qualite'' évolue.//