Différences

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

--- certif:procedure:develop:gestionversionpratique [2026/08/11 17:57] – [Vue d'ensemble] nicolas
+++ certif:procedure:develop:gestionversionpratique [2026/09/30 10:38] (Version actuelle) – nicolas
@@ Ligne 1: / Ligne 1: @@
-====== Guide pratique — Cycle de release, étape par étape ======
+|{{: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]]\\ [[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]]|
-//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.//
+====== Proc#170 - Guide pratique — Gestion des versions LoGeAs Web ======
-===== Où se lancent ces commandes =====
+===== Informations qualité =====
-''/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 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|
-  * **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).
+|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=170|Cartographie fonctionnelle – fiche de la procédure]]|
-  * **Dossier de travail :** toujours la racine du dépôt ``logeas-web`` (ou ``logeas-cartographie`` pour la dernière étape de ''/release-client'').
+|**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.|
-  * **Branche active au moment de lancer la commande :**
+|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement|
-    * ''/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. Objet =====
-| 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).
+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.
-----
+Il complète les documents suivants :
-===== Vue d'ensemble =====
+  * [[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.
-{{:certif:procedure:develop:cycle-release-schema.svg?1200|Vue d'ensemble du cycle de release}}
+**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à.
-^ Étape ^ Décision ^ Où ^ Commande ^
+===== 2. Environnement de travail =====
-| 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'' |
-----
+==== 2.1 Outils ====
-===== Étape 1 — Travail personnel (manuel) =====
+Les opérations sont réalisées depuis le poste de développement, avec :
-**Déclencheur :** en continu, dès qu'on commence à développer quelque chose.
+  * 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.
-**Qui :** le développeur, seul.
+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.
-**Où :** son poste, terminal ou client Git, dans ``logeas-web``, sur sa branche personnelle.
+==== 2.2 Répertoires ====
-**Ce qu'on fait, à la main :**
+^ 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 |
-  - ''git checkout -b <nom-de-branche>'' depuis la branche de version en cours (ex. ''11.0.25'') — pas de convention de nom imposée.
+Les commandes Claude Code et les scripts se lancent depuis la racine du dépôt ''logeas-web''.
-  - 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é.
+===== 3. Vue d'ensemble =====
-**À vérifier soi-même avant de committer :**
+^ Étape ^ Commande ou opération ^ Qui ^ Décrit dans ^
-  * Rien de sensible n'est ajouté (secrets, fichiers de config locale, ''dist/'', ''coverage/'').
+| 1. Travail personnel | Git, commits et sauvegardes | Développeur | ce guide, section 4 |
-  * Si le changement touche en réalité un comportement partagé (``DGService``, composants génériques), le code doit vivre dans ``logeas-lib``, pas ici.
+| 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 |
-----
+===== 4. Étape 1 — Travail personnel =====
-===== Étape 2 — Intégration (''/fusion-dev'') =====
+==== 4.1 Création de la branche ====
-**Déclencheur :** le travail sur la branche personnelle est prêt à rejoindre le tronc commun.
+Dans le dépôt ''logeas-web'', créer une branche personnelle à partir de la branche de version en cours.
-**Qui :** le développeur qui a fait le travail (ou toute personne de l'équipe).
+Exemple :
-**Où :** Claude Code, dans ``logeas-web``.
+<code bash>
+git checkout 11.2.0
+git pull
+git checkout -b feature/nom-fonctionnalite
+</code>
-**Ce que la commande fait, dans l'ordre :**
+Le nom de la branche doit permettre d'identifier le travail effectué.
-  - ''git fetch''
+==== 4.2 Développement et sauvegarde ====
-  - ''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 :**
+Le développeur réalise ses modifications et les sauvegarde régulièrement.
-  * 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.
+Exemple :
-----
+<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>
-===== Étape 3 — Beta (''/release-beta'') =====
+Avant chaque commit, vérifier les fichiers sélectionnés.
-**Déclencheur :** la branche de version est jugée stable, prête pour un tour de validation interne.
+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.
-**Qui décide :** chef de projet ou développeur senior. **Qui exécute :** développeur ou chef de projet.
+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.
-**Où :** Claude Code, dans ``logeas-web``, **sur la branche de version** (pas sur une branche perso).
+==== 4.3 Fin du travail personnel ====
-**Ce que la commande fait, dans l'ordre :**
+Lorsque le travail est prêt à être intégré :
-  - ''git status'' — vérifie que la branche est propre et à jour avec ''origin''
+  * vérifier les modifications ;
-  - ''npm run build:beta'', qui enchaîne :
+  * sauvegarder les derniers commits ;
-    * ''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)
+  * s'assurer que la branche personnelle est disponible sur le dépôt distant ;
-    * régénération de la licence DevExtreme
+  * lancer l'intégration.
-    * ''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 :**
+La branche personnelle ne doit pas être fusionnée directement dans la branche commune en contournant la procédure d'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. Étape 2 — Intégration =====
-----
+==== 5.1 Préparation ====
-===== Étape 4 — Release client (''/release-client'') =====
+L'intégration est réalisée avec la commande :
-**Déclencheur :** la beta a été validée (ou directement si aucune beta n'est jugée nécessaire pour ce cycle).
+<code>
+/fusion-dev
+</code>
-**Qui décide :** **chef de projet** — c'est la décision de livrer au client. **Qui exécute :** développeur ou chef de projet.
+La commande se lance dans ''logeas-web''. Elle identifie la branche de version commune et réalise la fusion de la branche personnelle.
-**Où :** Claude Code, dans ``logeas-web`` (étapes 1 à 6), puis dans ``logeas-cartographie`` pour la relecture/le commit du rapport qualité (étape 7).
+Avant de poursuivre, vérifier que :
-**Ce que la commande fait, dans l'ordre :**
+  * 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.
-  - ''git status'' — branche propre et à jour
+==== 5.2 Contrôles ====
-  - 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 :**
+La procédure réalise les contrôles techniques après la fusion :
-  * 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 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).
+  * compilation ;
+  * tests unitaires ;
+  * lint.
-----
+Le développeur vérifie le résultat global, notamment les avertissements et les échecs.
-===== Aide-mémoire : qui fait quoi, sous le capot =====
+En cas de conflit concernant le fonctionnement métier, ne pas accepter une résolution automatique sans vérification.
-{{:certif:procedure:develop:guide-pratique-detail.svg?1200|Détail des commandes internes par étape}}
+En cas d'échec bloquant, la branche commune ne doit pas être publiée tant que le problème n'est pas traité.
-----
+==== 5.3 Résultat attendu ====
-===== Équivalences SourceTree des commandes Git =====
+L'intégration est terminée lorsque :
-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) :
+  * 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.
-^ Commande Git ^ Équivalent dans SourceTree ^
+Le commit de fusion permet de retrouver les changements intégrés.
-| ''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``).
+===== 6. De la qualification à la livraison =====
-----
+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 ».
-===== Erreurs fréquentes à connaître =====
+À retenir une fois l'intégration terminé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.
+  * la suite commence par ''scripts\qualifier-version.bat'', après avoir **poussé** les branches de version de ''logeas-web'' et de ''logeas-lib'' ;
-  * **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'').
+  * **ne rien commiter ni pousser pendant la qualification**, ni entre une beta et sa release ;
-  * **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.
+  * tout correctif après une beta repart d'une branche personnelle, de ''/fusion-dev'', puis d'une nouvelle qualification ;
-  * **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.
+  * il n'y a pas de release sans beta recettée conforme.
-  * **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.
-----
+===== 7. Cas particulier — Démarrer une nouvelle version =====
-//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.//
+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''.
+Exemple :
+<code bash>
+git checkout 11.2.0
+git pull
+git checkout -b 11.3.0
+git push -u origin 11.3.0
+</code>
+La branche doit être **poussée** : une branche sans branche amont est refusée par la qualification.
+L'ancienne branche est conservée avec son historique et ses tags. La nouvelle branche devient la cible des prochaines intégrations.
+Informer l'équipe de ce changement afin que les développements en cours soient correctement réorientés.
+La version candidate est tirée du nom de la branche : la première beta de ''11.3.0'' sera ''11.3.0.1''.
+===== 8. Cas particulier — Correctifs et évolutions en parallèle =====
+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>
+Les profils sont définis dans :
+<code>
+scripts/switch-lib-profiles.json
+</code>
+Exemples :
+<code powershell>
+.\scripts\switch-lib-version.ps1 -Profile hotfix
+</code>
+<code powershell>
+.\scripts\switch-lib-version.ps1 -Profile next
+</code>
+<code powershell>
+.\scripts\switch-lib-version.ps1 -LibBranch 11.3.0 -WebBranch 11.3.0
+</code>
+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 ».
+Elles ne doivent pas être utilisées pour une livraison normale. Leur usage en urgence est décrit dans Proc#168, cas 8.
+==== 9.3 Précautions générales ====
+Avant toute opération :
+  * 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.
+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.
+===== 10. Aide-mémoire Git et SourceTree =====
+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 |
+Un tag créé localement mais non publié ne constitue pas une preuve de publication partagée.
+===== 11. Révision du guide =====
+Ce guide doit être actualisé lorsque les commandes, les scripts, les branches de version ou les modalités de publication évoluent.
+Les modifications doivent rester cohérentes avec Proc#168 et Proc#169.

Outils

menus et recherche rapide

recherche rapide

statut du site

Outils de la page

meta données pour cette page

Différences