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

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
certif:procedure:develop:gestionversionpratique [2026/09/28 12:54] – nicolascertif:procedure:develop:gestionversionpratique [2026/09/30 10:38] (Version actuelle) – nicolas
Ligne 1: Ligne 1:
-|{{:undo-2.svg?30|}} [[certif:dm#gestion_des_versions|Retour au dossier de maintenance]]\\ [[certif:gestionversion|Retour à la procédure]]|| +|{{:undo-2.svg?30|}} [[certif:dm#gestion_des_versions|Retour au dossier de maintenance]]|| 
-|{{: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]]|+|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[https://cartographie-fonctionnelle.logeas-web.fr/RapportsVersion|Informations sur la version en cours]]\\ [[certif:procedure:develop:gestionversion]]\\ [[certif:procedure:develop:chainequalificationlivraison]]\\ [[certif:procedure:develop:proceduremiseenligne]]\\ [[certif:procedure:develop:proceduremiseenligne:logeas-web]]|
  
-====== Guide pratique — Cycle de release, étape par étape ======+====== Proc#170 - Guide pratique — Gestion des versions LoGeAs Web ======
  
-//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.//+===== Informations qualité =====
  
-===== Où se lancent ces commandes =====+^Suivi des modifications majeures^^^ 
 +^Date^Auteur^Modifications^ 
 +|11 août 2026|Nicolas MARCHAND|Création du document| 
 +|30 septembre 2026|Nicolas MARCHAND|Alignement sur la chaîne de qualification et de livraison (Proc#168) : le guide se limite au travail personnel, à l'intégration et à la bascule entre versions, et renvoie à Proc#168 pour la qualification, la beta, la recette et la release (suppression des anciennes étapes de publication et de la release sans beta) ; mise au format de la maîtrise documentaire|
  
-''/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.+|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=170|Cartographie fonctionnelle – fiche de la procédure]]| 
 +|**Objet** |Ce guide décrit les opérations à effectuer pour gérer les versions de LoGeAs Web, depuis le développement individuel jusqu'à la publication d'une version destinée aux utilisateurs.| 
 +|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement|
  
-  * **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 =====+===== 1. Objet =====
  
-^ Étape ^ Qui décide de lancer ^ Qui exécute ^ +Ce guide décrit les opérations pratiques de gestion des versions de LoGeAs Web. Il s'adresse principalement aux développeurs et aux personnes chargées de préparer les publications.
-| 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).+Il complète les documents suivants :
  
-----+  * [[certif:procedure:develop:gestionversion|Proc#145 - Procédure de gestion des versions]] : règles générales de versionnage. 
 +  * [[certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]] : **déroulé pas à pas de la qualification, de la beta, de la recette et de la release**, portes bloquantes, cas particuliers. 
 +  * [[certif:procedure:develop:proceduremiseenligne:logeas-web|Proc#169 - Cycle de release LoGeAs Web]] : fonctionnement technique des scripts.
  
-===== Vue d'ensemble =====+**Répartition :** ce guide détaille le travail quotidien du développeur (branches, commits, intégration, bascule entre versions). Tout ce qui va de la qualification à la livraison est décrit dans Proc#168, et uniquement là.
  
-{{:certif:procedure:develop:cycle-release-schema.svg?1200|Vue d'ensemble du cycle de release}}+===== 2. Environnement de travail =====
  
-^ Étape ^ Décision ^ Où ^ Commande ^ +==== 2.1 Outils ====
-| 1. Travail personnel | Développeur | Poste dev, branche perso | (aucune — voir détail plus bas) | +
-| 2. Intégration | Développeur | Claude Code, ''logeas-web'' | ''/fusion-dev'' | +
-| 3. Beta | Chef de projet | Claude Code, ''logeas-web'', branche de version | ''/release-beta'' | +
-| 4. Release client | Chef de projet | Claude Code, ''logeas-web'' puis ''logeas-cartographie'' | ''/release-client'' |+
  
-==== Autres commandes "utiles" ==== +Les opérations sont réalisées depuis le poste de développement, avec :
-^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| +
-----+
  
-===== Étape 1 — Travail personnel (manuel) =====+  * Git et l'accès aux dépôts distants ; 
 +  * Node.js et npm ; 
 +  * Angular CLI ; 
 +  * Claude Code, pour les commandes d'assistance du cycle ; 
 +  * les accès aux dépôts ''logeas-web'', ''logeas-lib'' et ''logeas-cartographie'' ; 
 +  * un accès connecté à la cartographie fonctionnelle, pour valider les rapports qualité et faire la recette.
  
-**Déclencheur :** en continu, dès qu'on commence à développer quelque chose.+Les commandes ''/fusion-dev'', ''/qualifier-version'', ''/release-beta'', ''/release-client'' et ''/rapport-version-qualite'' sont des commandes Claude Code. Elles ne se saisissent pas comme des commandes shell.
  
-**Qui :** le développeur, seul.+==== 2.2 Répertoires ====
  
-**Où :** son poste, terminal ou client Git, dans ''logeas-web'', sur sa branche personnelle.+^ Répertoire ^ Usage ^ 
 +| ''D:\Developpements\Sources\NewInterfaces\logeas-web'' | Dépôt principal de l'interface et des scripts de livraison | 
 +| ''D:\Developpements\Sources\NewInterfaces\logeas-lib'' | Dépôt des bibliothèques partagées | 
 +| ''D:\Developpements\Sources\NewInterfaces\logeas-cartographie'' | Dépôt de la cartographie fonctionnelle (écran « Rapports de version ») | 
 +| ''D:\Developpements\VersionPublic\LogeasWeb-Test\browser'' | Résultat du build beta | 
 +| ''D:\Developpements\VersionPublic\LogeasWeb\browser'' | Résultat du build de production | 
 +| ''D:\Developpements\VersionPublic\ExecutablesWindows'' | Exécutables des composants utilisés pour les rapports de release |
  
-**Ce qu'on fait, à la main :**+Les commandes Claude Code et les scripts se lancent depuis la racine du dépôt ''logeas-web''.
  
-  - ''git checkout -b <nom-de-branche>'' depuis la branche de version en cours (ex. ''11.0.25'') — pas de convention de nom imposée. +===== 3. Vue d'ensemble =====
-  - On développe, on teste localement si besoin. +
-  - ''git add <fichiers>'' — **jamais** ''git add -A'' à l'aveugle, on relit ce qu'on ajoute. +
-  - ''git commit -m "..."'' — message en français, court, orienté fonctionnel. +
-  - ''git push -u origin <branche>'' — sauvegarde régulière, au fil de l'eau.+
  
-**Volontairement aucune vérification ici** (pas de build, pas de tests) : c'est une sauvegarde de travail potentiellement inachevé, pas encore un contrôle qualité.+^ Étape ^ Commande ou opération ^ Qui ^ Décrit dans ^ 
 +| 1. Travail personnel | Git, commits et sauvegardes | Développeur | ce guide, section 4 | 
 +| 2. Intégration | ''/fusion-dev'' | Développeur | ce guide, section 5 | 
 +| 3. Qualification | ''scripts\qualifier-version.bat'' | Développeur | Proc#168 | 
 +| 4. Validation du rapport qualité | carto, écran « Rapports de version » | Valideur | Proc#168 | 
 +| 5. Beta | ''scripts\livrer-beta.bat'' | Développeur | Proc#168 | 
 +| 6. Déploiement sur le serveur de test | copie manuelle | Personne habilitée | Proc#168 | 
 +| 7. Recette de la beta | carto, écran « Rapports de version » | Valideur | Proc#168 | 
 +| 8. Release client | ''scripts\livrer-release.bat'' | Développeur | Proc#168 | 
 +| 9. Déploiement en production | copie manuelle | Personne habilitée | Proc#168 |
  
-**À vérifier soi-même avant de committer :** +===== 4. Étape 1 — Travail personnel =====
-  * 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.+
  
-----+==== 4.1 Création de la branche ====
  
-===== Étape 2 — Intégration (''/fusion-dev'') =====+Dans le dépôt ''logeas-web'', créer une branche personnelle à partir de la branche de version en cours.
  
-**Déclencheur :** le travail sur la branche personnelle est prêt à rejoindre le tronc commun.+Exemple :
  
-**Qui :** le développeur qui a fait le travail (ou toute personne de l'équipe).+<code bash> 
 +git checkout 11.2.0 
 +git pull 
 +git checkout -b feature/nom-fonctionnalite 
 +</code>
  
-**Où :** Claude Code, dans ''logeas-web''.+Le nom de la branche doit permettre d'identifier le travail effectué.
  
-**Ce que la commande fait, dans l'ordre :**+==== 4.2 Développement et sauvegarde ====
  
-  - ''git fetch'' +Le développeur réalise ses modifications et les sauvegarde régulièrement.
-  - ''git checkout <branche-de-version>'' puis ''git pull'' +
-  - ''git log <branche-de-version>..<branche-perso> --pretty=...'' — récupère la liste complète des commits qui vont être intégrés +
-  - ''git merge --no-ff <branche-perso>'' — le message de fusion embarque cette liste de commits, pas juste un titre générique +
-  - ''ng build'' — vérifie que ça compile +
-  - ''npm test'' — tests unitaires (Jest) +
-  - ''npm run lint'' — seulement les **nouvelles** erreurs introduites par le diff comptent, pas la dette préexistante +
-  - Si tout est vert : ''git push'' de la branche de version+
  
-**À vérifier après coup :** +Exemple :
-  * Le commit de fusion contient bien la liste des commits intégrés (pas juste « Merge branch X into Y »). +
-  * Aucun conflit n'a été résolu à l'aveugle sur un point métier — en cas de doute, la procédure doit s'arrêter et demander plutôt que trancher seule. +
-  * Build/tests/lint sont bien passés **après** la fusion, pas seulement avant (l'intégration de plusieurs travaux peut casser des choses invisibles avant).+
  
-**Si ça échoue :** la procédure corrige sur place si c'est trivial, sinon elle s'arrête et explique — jamais de ''push --force'', jamais de fusion poussée avec des tests rouges.+<code bash> 
 +git status 
 +git add src/app/mon-composant 
 +git commit -m "Ajout de la fonctionnalité" 
 +git push -u origin feature/nom-fonctionnalite 
 +</code>
  
-----+Avant chaque commit, vérifier les fichiers sélectionnés.
  
-===== Étape 3 — Beta (''/release-beta'') =====+Ne pas ajouter de fichiers contenant des secrets, des paramètres locaux ou des fichiers de compilation qui ne sont pas destinés au dépôt.
  
-**Déclencheur :** la branche de version est jugée stable, prête pour un tour de validation interne.+Les tests peuvent être exécutés pendant le développement selon les besoins. Cette étape constitue une sauvegarde du travail personnel et non une validation de l'intégration.
  
-**Qui décide :** chef de projet ou développeur senior. **Qui exécute :** développeur ou chef de projet.+==== 4.3 Fin du travail personnel ====
  
-**Où :** Claude Code, dans ''logeas-web'', **sur la branche de version** (pas sur une branche perso).+Lorsque le travail est prêt à être intégré :
  
-**Ce que la commande fait, dans l'ordre :**+  * vérifier les modifications ; 
 +  * sauvegarder les derniers commits ; 
 +  * s'assurer que la branche personnelle est disponible sur le dépôt distant ; 
 +  * lancer l'intégration.
  
-  - ''git status'' — vérifie que la branche est propre et à jour avec ''origin'' +La branche personnelle ne doit pas être fusionnée directement dans la branche commune en contournant la procédure d'intégration.
-  - ''npm run build:beta'', qui enchaîne : +
-    * ''node scripts/version.js beta'' — calcule le numéro ''X.Y.Z.W'' (voir règle de numérotation dans la procédure de référence) +
-    * régénération de la licence DevExtreme +
-    * ''ng build --configuration production,beta'' — sortie vers ''LogeasWeb-Test'' +
-  - ''node scripts/release-report.js beta'', qui : +
-    * calcule le diff Git depuis le **dernier tag ''_release''** (jamais depuis le dernier beta — le rapport cumule tout le cycle) +
-    * relance ''npx jest --coverage --json'' pour un résumé de tests à jour (pass/fail, couverture) +
-    * 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'' +
-  - 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 push'' + ''git push origin <tag>''+
  
-**À vérifier après coup :** +===== 5. Étape 2 — Intégration =====
-  * Le numéro de version généré est bien celui attendu (cohérent avec le nom de la branche). +
-  * Le rapport de release ne signale pas d'échec de test bloquant — s'il y en a, décider **avec l'équipe** si on tague quand même. +
-  * Le build est bien présent dans ''D:\Developpements\VersionPublic\LogeasWeb-Test\browser\''. +
-  * Le rapport est consultable dans l'appli via l'écran « Rapports de release » (Administration, ou directement ''/RapportsRelease'', accessible sans connexion).+
  
-**Ce qui reste manuel :** copier ''LogeasWeb-Test\browser\'' vers le serveur de test — accessible uniquement en bureau à distance, aucune procédure ne le fait à votre place.+==== 5.1 Préparation ====
  
-----+L'intégration est réalisée avec la commande :
  
-===== Étape 4 — Release client (''/release-client'') =====+<code> 
 +/fusion-dev 
 +</code>
  
-**Déclencheur :** la beta a été validée (ou directement si aucune beta n'est jugée nécessaire pour ce cycle).+La commande se lance dans ''logeas-web''. Elle identifie la branche de version commune et réalise la fusion de la branche personnelle.
  
-**Qui décide :** **chef de projet** — c'est la décision de livrer au client. **Qui exécute :** développeur ou chef de projet.+Avant de poursuivre, vérifier que :
  
-**Où :** Claude Code, dans ''logeas-web'' (étapes 1 à 6), puis dans ''logeas-cartographie'' pour la relecture/le commit du rapport qualité (étape 7).+  * le travail est prêt à être intégré ; 
 +  * la branche personnelle a été sauvegardée ; 
 +  * les éventuels conflits ont été examinés ; 
 +  * la branche cible correspond bien à la version en cours.
  
-**Ce que la commande fait, dans l'ordre :**+==== 5.2 Contrôles ====
  
-  - ''git status'' — branche propre et à jour +La procédure réalise les contrôles techniques après la fusion :
-  - Si cette release fait suite à une beta : vérifie que rien d'autre que des correctifs ciblés n'a été ajouté depuis le tag beta (''git log <tag_beta>..HEAD'') — sinon ça mérite peut-être un nouveau tour de beta. +
-  - ''npm run build'', qui enchaîne : +
-    * ''node scripts/version.js release'' — repasse en 3 chiffres, **reprend le même X.Y.Z que les betas du cycle** (jamais de numéro « orphelin ») +
-    * ''ng build --configuration production'' — sortie vers ''LogeasWeb'' +
-  - ''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) +
-  - ''git tag -a X.Y.Z_release'' +
-  - ''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''+
  
-**À vérifier après coup :** +  * compilation ; 
-  * Le build est bien présent dans ''D:\Developpements\VersionPublic\LogeasWeb\browser\''. +  * tests unitaires ; 
-  * Le tag ne rentre pas en collision avec un tag ''_release'' déjà existant. +  * lint.
-  * 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).+Le développeur vérifie le résultat global, notamment les avertissements et les échecs.
  
-----+En cas de conflit concernant le fonctionnement métier, ne pas accepter une résolution automatique sans vérification.
  
-===== Cas particulier — Basculer vers une version mineure en cours de cycle =====+En cas d'échec bloquant, la branche commune ne doit pas être publiée tant que le problème n'est pas traité.
  
-**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'').+==== 5.3 Résultat attendu ====
  
-**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.+L'intégration est terminée lorsque :
  
-**Procédure :**+  * la fusion est effectuée ; 
 +  * les contrôles prévus ont été réalisés ; 
 +  * les éventuels problèmes ont été résolus ; 
 +  * la branche commune a été publiée sur le dépôt distant.
  
-  - Se mettre à jour sur la branche de version en cours : +Le commit de fusion permet de retrouver les changements intégrés.
-    <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''.+
  
-----+===== 6. De la qualification à la livraison =====
  
-===== Cas particulier — Travailler en parallèle sur deux versions (correctifs release en ligne / évolutions à venir) =====+La qualification, la validation du rapport qualité, la beta, la recette, la release et les déploiements ne sont pas décrits ici : ils le sont pas à pas dans [[certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]], sections « Cheminements pas à pas » et « Les étapes en détail ».
  
-**Quand :** en permanence, deux pistes de travail coexistent — corriger des bugs sur ce qui tourne déjà chez les clients, et développer les évolutions de la prochaine version. Ce cas concerne l'étape 1 (travail personnel), avant même d'arriver à ''/fusion-dev''.+À retenir une fois l'intégration terminée :
  
-^ Piste ^ Usage ^ Limite ^ Branche ''logeas-web'' ^ Branche ''logeas-lib'' ^ +  * la suite commence par ''scripts\qualifier-version.bat'', après avoir **poussé** les branches de version de ''logeas-web'' et de ''logeas-lib'' ; 
-| **Release en ligne** | Corriger des bugs sur ce qui tourne actuellement chez les clients. | Correctifs uniquement — pas de nouvelle fonctionnalité, pas de changement de structure de base. | 11.1.0 | 11.0.8 | +  * **ne rien commiter ni pousser pendant la qualification**, ni entre une beta et sa release ; 
-| **Prochaine version** | Développer les évolutions de la prochaine release. | Pas encore en production — rien d'urgent à y corriger pour un client. | 11.2.0 | 11.2.0 |+  * tout correctif après une beta repart d'une branche personnelle, de ''/fusion-dev'', puis d'une nouvelle qualification ; 
 +  * il n'y a pas de release sans beta recettée conforme.
  
-<code> +===== 7. Cas particulier — Démarrer une nouvelle version ===== 
-   PROD (clients) + 
-        | +Lorsqu'une évolution nécessite de passer à une nouvelle version (Proc#168, cas 6), créer la nouvelle branche de version dans ''logeas-web'' et, si la bibliothèque évolue aussi, dans ''logeas-lib''. 
-   [ web 11.1.0 / lib 11.0.8 ]  <- correctifs urgents + 
-        | +Exemple : 
-        |  a reporter manuellement (cherry-pick / fusion) + 
-        v +<code bash> 
-   [ web 11.2.0 / lib 11.2.0 ]  <- evolutions en cours +git checkout 11.2.0 
-        | +git pull 
-        v +git checkout -b 11.3.0 
-   future release+git push -u origin 11.3.0
 </code> </code>
  
-**Piège fréquent :** un correctif commité uniquement sur la branche « release en ligne » n'atterrit jamais tout seul sur la branche « prochaine version ». S'il n'est pas reporté à la main, il est perdu dès la sortie de la version suivante — le principe d'immutabilité d'une version publiée (voir la [[certif:procedure:develop:gestionversion|procédure de référence]]) empêche de le rattraper après coup.+La branche doit être **poussée** : une branche sans branche amont est refusée par la qualification.
  
-**Pourquoi ce n'est pas juste un ''git checkout'' :** ''logeas-web'' ne dépend pas du code source de ''logeas-lib'' mais d'un paquet **déjà compilé et empaqueté** (fichier ''.tgz'', référencé dans ''package.json'' avec le numéro de version en dur dans le chemin — ex. ''file:../logeas-lib/dist/ngx-logeasweb-ui/ngx-logeasweb-ui-11.0.8.tgz''), pour être sûr de tester exactement ce qui sera publié. ''dist/'' (les paquets construits côté ''logeas-lib'') et ''package-lock.json'' ne sont pas versionnés dans Git : un simple ''git checkout'' d'une autre branche ne restaure donc jamais cette chaîne — elle doit être rejouée intégralement (rebuild des 3 librairies, ''npm pack'' de chacune, déplacement du ''.tgz'', 3 lignes à éditer dans ''package.json'', ''npm install'').+L'ancienne branche est conservée avec son historique et ses tags. La nouvelle branche devient la cible des prochaines intégrations.
  
-**Outil : ''scripts/switch-lib-version.ps1''** (dans ''logeas-web'') — automatise cette chaîne. Piloté par des profils dans ''scripts/switch-lib-profiles.json'' :+Informer l'équipe de ce changement afin que les développements en cours soient correctement réorientés.
  
-<code json> +La version candidate est tirée du nom de la branche : la première beta de ''11.3.0'' sera ''11.3.0.1''. 
-{ + 
-  "hotfix": { "webBranch": "11.1.0", "libBranch": "11.0.8" }, +===== 8. Cas particulier — Correctifs et évolutions en parallèle ===== 
-  "next":   { "webBranch": "11.2.0", "libBranch": "11.2.0" } + 
-}+Deux pistes de développement peuvent être maintenues simultanément : 
 + 
 +^ Piste ^ Usage ^ 
 +| Version en production | Correctifs de la version utilisée par les clients | 
 +| Version suivante | Nouvelles fonctionnalités et évolutions | 
 + 
 +Les corrections apportées à la version de production ne sont pas automatiquement reportées sur la version suivante : il faut les y intégrer (Proc#168, cas 7). 
 + 
 +==== 8.1 Bascule entre versions ==== 
 + 
 +''logeas-web'' utilise les bibliothèques de ''logeas-lib'' sous forme de paquets construits. Un simple changement de branche Git ne suffit pas à garantir que les dépendances correspondent à la version souhaitée. 
 + 
 +Le script suivant bascule le poste sur une paire de branches web / lib, reconstruit la bibliothèque et la réinstalle : 
 + 
 +<code> 
 +scripts/switch-lib-version.ps1
 </code> </code>
 +
 +Les profils sont définis dans :
 +
 +<code>
 +scripts/switch-lib-profiles.json
 +</code>
 +
 +Exemples :
  
 <code powershell> <code powershell>
-# Basculer en mode correctifs (release en ligne) 
 .\scripts\switch-lib-version.ps1 -Profile hotfix .\scripts\switch-lib-version.ps1 -Profile hotfix
 +</code>
  
-# Basculer en mode évolutions (prochaine version)+<code powershell>
 .\scripts\switch-lib-version.ps1 -Profile next .\scripts\switch-lib-version.ps1 -Profile next
 </code> </code>
  
-Le script : +<code powershell> 
-  * refuse de démarrer si l'un des deux dépôts (''logeas-web'' ou ''logeas-lib'') a des modifications non commitées — rien n'est écrasé silencieusement ; +.\scripts\switch-lib-version.ps1 -LibBranch 11.3.0 -WebBranch 11.3.0 
-  * **compare l'historique des deux pistes et demande confirmation** si des commits existent sur une version antérieure et ne sont pas encore présents sur la cible — c'est le garde-fou contre le piège décrit plus haut ; +</code>
-  * checkout les branches, rebuild et repackage les 3 librairies ''logeas-lib'' (''ngx-logeascom-ui'', ''ngx-logeasweb-ui'', ''ngx-interface-ui'', dans cet ordre de dépendance), met à jour ''package.json'' de ''logeas-web'', relance ''npm install''.+
  
-**À faire à chaque nouvelle release :** quand une nouvelle branche mineure est créée (voir le cas particulier précédent), mettre à jour ''scripts/switch-lib-profiles.json'' avec les nouveaux noms de branche — aucune modification du script lui-même n'est nécessaire.+Avant d'utiliser cet outil, vérifier que les dépôts ne contiennent pas de modifications locales non sauvegardées. 
 + 
 +Le script signale les correctifs d'une version antérieure pas encore reportés sur l'autre piste. Examiner ces écarts avant de poursuivre. 
 + 
 +Les profils doivent être actualisés lorsqu'une nouvelle organisation de branches est mise en place. 
 + 
 +===== 9. Commandes et précautions ===== 
 + 
 +==== 9.1 Commandes Claude Code ==== 
 + 
 +^ Commande ^ Utilisation ^ 
 +| ''/fusion-dev'' | Intégrer le travail personnel à la branche de version | 
 +| ''/qualifier-version'' | Vérifier les préconditions de la qualification, puis renvoyer vers ''qualifier-version.bat'' | 
 +| ''/release-beta'' | Vérifier la porte beta, expliquer ce qui bloque, puis renvoyer vers ''livrer-beta.bat'' | 
 +| ''/release-client'' | Vérifier la porte release, expliquer ce qui bloque, puis renvoyer vers ''livrer-release.bat'' | 
 +| ''/rapport-version-qualite'' | Rédiger l'analyse du rapport qualité (appelée par la qualification) | 
 + 
 +Seule ''/fusion-dev'' modifie le dépôt. Les commandes ''/qualifier-version'', ''/release-beta'' et ''/release-client'' **ne livrent rien elles-mêmes**. 
 + 
 +==== 9.2 Génération manuelle d'un build ==== 
 + 
 +Les commandes suivantes génèrent un build **hors chaîne** : 
 + 
 +<code bash> 
 +ng build --configuration "production,beta" 
 +</code> 
 + 
 +<code bash> 
 +ng build --configuration production 
 +</code>
  
-----+Elles ne passent pas les portes et ne créent ni rapport, ni tag. ''npm run build'' et ''npm run build:beta'' refont en plus la mise à jour du numéro de version. Dans tous les cas, la version produite est affichée « Version non qualifiée ».
  
-===== Aide-mémoire : qui fait quoi, sous le capot =====+Elles ne doivent pas être utilisées pour une livraison normale. Leur usage en urgence est décrit dans Proc#168, cas 8.
  
-{{:certif:procedure:develop:guide-pratique-detail.svg?1200|Détail des commandes internes par étape}}+==== 9.3 Précautions générales ====
  
-----+Avant toute opération :
  
-===== Équivalences SourceTree des commandes Git =====+  * vérifier le dépôt et la branche active ; 
 +  * vérifier l'état des modifications locales ; 
 +  * ne jamais utiliser ''git push --force'' sur une branche commune ; 
 +  * ne pas supprimer ou réécrire les tags d'une version publiée ; 
 +  * **ne jamais contourner une porte** : si le blocage est injustifié, c'est un défaut des scripts, à signaler et corriger ; 
 +  * ne pas confondre génération d'un build et déploiement d'une version.
  
-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) :+En cas de doute sur la branche cible, le numéro de version ou la validité d'une publication, suspendre l'opération et demander une vérification.
  
-^ Commande Git ^ Équivalent dans SourceTree ^ +===== 10. Aide-mémoire Git et 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'').+Les scripts exécutent automatiquement les opérations Git prévues. Le tableau ci-dessous sert au dépannage et aux vérifications manuelles.
  
-----+^ Commande Git ^ Équivalent SourceTree ^ 
 +| ''git fetch'' | Bouton Fetch | 
 +| ''git checkout <branche>'' | Double-clic sur la branche | 
 +| ''git pull'' | Bouton Pull | 
 +| ''git status'' | Onglet File status | 
 +| ''git add <fichiers>'' | Sélection des fichiers dans File status | 
 +| ''git commit'' | Bouton Commit | 
 +| ''git merge --no-ff <branche>'' | Merge avec création d'un commit même en cas de fast-forward | 
 +| ''git tag -a'' | Création d'un tag annoté sur le commit | 
 +| ''git push'' | Bouton Push, avec sélection des tags à publier | 
 +| ''git log <a>..<b>'' | Consultation de l'historique entre deux références |
  
-===== Erreurs fréquentes à connaître =====+Un tag créé localement mais non publié ne constitue pas une preuve de publication partagée.
  
-  * **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. +===== 11. Révision du guide =====
-  * **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. +
-  * **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. +
-  * **Corriger un bug sur la branche « release en ligne » sans le reporter sur la branche d'évolutions** : le correctif est perdu dès que la version suivante sort, sans avertissement. Utiliser ''scripts/switch-lib-version.ps1'' pour basculer entre les deux pistes — il alerte si des commits d'une version antérieure ne sont pas encore reportés sur la cible.+
  
-----+Ce guide doit être actualisé lorsque les commandes, les scripts, les branches de version ou les modalités de publication évoluent.
  
-//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), mis à jour le 18 août 2026 (ajout du cas particulier de travail en parallèle sur deux versions et de l'outil ''switch-lib-version.ps1'') — à mettre à jour si le contenu des commandes ''/fusion-dev'', ''/release-beta'', ''/release-client'' ou ''/rapport-tests-qualite'' évolue.//+Les modifications doivent rester cohérentes avec Proc#168 et Proc#169.