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
certif:procedure:develop:gestionversionpratique [2026/09/29 07:45] – [Informations qualité] 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]]|| |{{: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://interface.logeas-web.fr/RapportsRelease|Informations sur la version en cours]] [[certif:procedure:develop:gestionversion]]\\ [[certif:procedure:develop:chainequalificationlivraison]]\\ [[certif:procedure:develop:proceduremiseenligne]]\\ [[certif:procedure:develop:proceduremiseenligne:logeas-web]]\\ [[certif:procedure:develop:gestionversionpratique]] |+|{{: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]]|
  
 +====== Proc#170 - Guide pratique — Gestion des versions LoGeAs Web ======
  
-====== Guide pratique — Gestion des versions LoGeAs Web ====== 
 ===== Informations qualité ===== ===== Informations qualité =====
-|**Suivi des modifications majeures** |septembre 2026 - Nicolas Marchand - Création du document| + 
-|**Suivi des approbations** |https://cartographie-fonctionnelle.logeas-web.fr/UniversDoc|+^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| 
 + 
 +|**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.| |**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** : Equipe dev| +|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement|
-===== 1. 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.+\\ 
 + 
 +===== 1. Objet =====
  
-Il s'adresse principalement aux développeurs et aux personnes chargées de préparer les publications.+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 : Il complète les documents suivants :
  
-  * [[certif:procedure:develop:gestionversion|Procédure de gestion des versions]] : règles générales de versionnage. +  * [[certif:procedure:develop:gestionversion|Proc#145 - Procédure de gestion des versions]] : règles générales de versionnage. 
-  * [[certif:procedure:develop:chainequalificationlivraison|Chaîne de qualification et de livraison]] : responsabilités, contrôles et validations. +  * [[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|Cycle de release LoGeAs Web]] : fonctionnement technique des procédures automatisées.+  * [[certif:procedure:develop:proceduremiseenligne:logeas-web|Proc#169 - Cycle de release LoGeAs Web]] : fonctionnement technique des scripts.
  
-Ce guide décrit les opérations pratiques. En cas de différence entre une commande et le fonctionnement réel du script, le script et la procédure technique doivent être vérifiés avant toute publication.+**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à.
  
 ===== 2. Environnement de travail ===== ===== 2. Environnement de travail =====
Ligne 27: Ligne 33:
 ==== 2.1 Outils ==== ==== 2.1 Outils ====
  
-Les opérations de release sont réalisées depuis le poste de développement, avec :+Les opérations sont réalisées depuis le poste de développement, avec :
  
   * Git et l'accès aux dépôts distants ;   * Git et l'accès aux dépôts distants ;
   * Node.js et npm ;   * Node.js et npm ;
   * Angular CLI ;   * Angular CLI ;
-  * Claude Code, pour les commandes automatisées du cycle ; +  * Claude Code, pour les commandes d'assistance du cycle ; 
-  * les accès aux dépôts ''logeas-web'', ''logeas-lib'' et, pour le rapport qualité, ''logeas-cartographie''.+  * 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.
  
-Les commandes ''/fusion-dev'', ''/release-beta'', ''/release-client'' et ''/rapport-tests-qualite'' sont des commandes Claude Code. Elles ne doivent pas être saisies comme des commandes shell classiques.+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.
  
 ==== 2.2 Répertoires ==== ==== 2.2 Répertoires ====
  
 ^ Répertoire ^ Usage ^ ^ Répertoire ^ Usage ^
-| ''D:\Developpements\Sources\NewInterfaces\logeas-web'' | Dépôt principal de l'interface |+| ''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-lib'' | Dépôt des bibliothèques partagées |
-| ''D:\Developpements\Sources\NewInterfaces\logeas-cartographie'' | Dépôt des rapports et de la cartographie |+| ''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-Test\browser'' | Résultat du build beta |
 | ''D:\Developpements\VersionPublic\LogeasWeb\browser'' | Résultat du build de production | | ''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 | | ''D:\Developpements\VersionPublic\ExecutablesWindows'' | Exécutables des composants utilisés pour les rapports de release |
  
-Les commandes Claude Code doivent être lancées depuis la racine du dépôt concerné.+Les commandes Claude Code et les scripts se lancent depuis la racine du dépôt ''logeas-web''.
  
 ===== 3. Vue d'ensemble ===== ===== 3. Vue d'ensemble =====
  
-^ Étape ^ Commande ou opération ^ Responsable de la décision ^ +^ Étape ^ Commande ou opération ^ Qui ^ Décrit dans ^ 
-| 1. Travail personnel | Git, commits et sauvegardes | Développeur | +| 1. Travail personnel | Git, commits et sauvegardes | Développeur | ce guide, section 4 | 
-| 2. Intégration | ''/fusion-dev'' | Développeur | +| 2. Intégration | ''/fusion-dev'' | Développeur | ce guide, section 5 | 
-| 3. Publication beta | ''/release-beta'' | Chef de projet ou développeur senior | +| 3. Qualification | ''scripts\qualifier-version.bat'' | Développeur | Proc#168 | 
-| 4. Validation beta | Tests et recette | Responsable de la validation | +| 4. Validation du rapport qualité | carto, écran « Rapports de version » | Valideur | Proc#168 | 
-| 5. Publication client | ''/release-client'' | Chef de projet | +| 5. Beta | ''scripts\livrer-beta.bat'' | Développeur | Proc#168 | 
-| 6. Déploiement | Copie vers le serveur | Personne habilitée | +| 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 | 
-Une release directe, sans beta préalable, est possible lorsqu'elle est justifiée et que les contrôles applicables sont réalisés.+| 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 ===== ===== 4. Étape 1 — Travail personnel =====
Ligne 70: Ligne 78:
  
 <code bash> <code bash>
-git checkout 11.0.25+git checkout 11.2.0
 git pull git pull
 git checkout -b feature/nom-fonctionnalite git checkout -b feature/nom-fonctionnalite
Ligne 98: Ligne 106:
 ==== 4.3 Fin du travail personnel ==== ==== 4.3 Fin du travail personnel ====
  
-Lorsque le travail est suffisamment avancé et prêt à être intégré :+Lorsque le travail est prêt à être intégré :
  
   * vérifier les modifications ;   * vérifier les modifications ;
   * sauvegarder les derniers commits ;   * sauvegarder les derniers commits ;
   * s'assurer que la branche personnelle est disponible sur le dépôt distant ;   * s'assurer que la branche personnelle est disponible sur le dépôt distant ;
-  * demander ou lancer l'intégration.+  * lancer l'intégration.
  
 La branche personnelle ne doit pas être fusionnée directement dans la branche commune en contournant la procédure d'intégration. La branche personnelle ne doit pas être fusionnée directement dans la branche commune en contournant la procédure d'intégration.
Ligne 117: Ligne 125:
 </code> </code>
  
-La commande doit être lancée dans ''logeas-web''. +La commande se lance dans ''logeas-web''. Elle identifie la branche de version commune et réalise la fusion de la branche personnelle.
- +
-Elle identifie la branche de version commune et réalise la fusion de la branche personnelle.+
  
 Avant de poursuivre, vérifier que : Avant de poursuivre, vérifier que :
Ligne 136: Ligne 142:
   * lint.   * lint.
  
-Le développeur doit vérifier le résultat global et notamment les éventuels avertissements ou échecs.+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. En cas de conflit concernant le fonctionnement métier, ne pas accepter une résolution automatique sans vérification.
Ligne 148: Ligne 154:
   * la fusion est effectuée ;   * la fusion est effectuée ;
   * les contrôles prévus ont été réalisés ;   * les contrôles prévus ont été réalisés ;
-  * les éventuels problèmes ont été résolus ou traités selon la procédure applicable ;+  * les éventuels problèmes ont été résolus ;
   * la branche commune a été publiée sur le dépôt distant.   * la branche commune a été publiée sur le dépôt distant.
  
 Le commit de fusion permet de retrouver les changements intégrés. Le commit de fusion permet de retrouver les changements intégrés.
  
-===== 6. Étape 3 — Publication d'une beta =====+===== 6. De la qualification à la livraison =====
  
-==== 6.1 Conditions préalables ====+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 ».
  
-La publication beta est décidée lorsque la branche de version est considérée comme suffisamment stable pour être testée.+À retenir une fois l'intégration terminée :
  
-Avant de lancer la procédure, vérifier :+  * la suite commence par ''scripts\qualifier-version.bat'', après avoir **poussé** les branches de version de ''logeas-web'' et de ''logeas-lib'' ; 
 +  * **ne rien commiter ni pousser pendant la qualification**, ni entre une beta et sa release ; 
 +  * 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.
  
-  * que les développements à intégrer sont bien présents ; +===== 7. Cas particulier — Démarrer une nouvelle version =====
-  * que les intégrations nécessaires ont été réalisées ; +
-  * que la branche commune est propre et à jour ; +
-  * que les contrôles d'intégration sont satisfaisants.+
  
-==== 6.2 Génération ==== +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''.
- +
-Dans ''logeas-web'', sur la branche de version, lancer : +
- +
-<code> +
-/release-beta +
-</code> +
- +
-La commande réalise automatiquement les opérations prévues dans la procédure technique, notamment : +
- +
-  * vérification du dépôt ; +
-  * calcul du numéro beta ; +
-  * génération des informations de version ; +
-  * compilation de l'application ; +
-  * génération du rapport de release ; +
-  * création du commit de préparation ; +
-  * création et publication du tag Git. +
- +
-Le build est produit dans : +
- +
-<code> +
-D:\Developpements\VersionPublic\LogeasWeb-Test\browser\ +
-</code> +
- +
-==== 6.3 Vérifications après génération ==== +
- +
-Après l'exécution, vérifier : +
- +
-  * que la commande s'est terminée sans erreur bloquante ; +
-  * que le numéro beta correspond au cycle attendu ; +
-  * que le tag beta a été créé et publié ; +
-  * que le build existe dans le répertoire de test ; +
-  * que le rapport de release est accessible ; +
-  * que les éventuelles anomalies signalées sont prises en compte. +
- +
-Le numéro beta utilise le format ''X.Y.Z.W_beta''. +
- +
-==== 6.4 Déploiement sur le serveur de test ==== +
- +
-Le transfert du build vers le serveur de test reste manuel. +
- +
-La personne habilitée doit : +
- +
-  * récupérer le contenu du répertoire de génération beta ; +
-  * le transférer vers le serveur de test par le moyen d'accès autorisé ; +
-  * vérifier que les fichiers ont été copiés dans le répertoire prévu ; +
-  * vérifier le fonctionnement de la version déployée. +
- +
-La beta peut alors être soumise aux tests et à la recette prévus par la chaîne de qualification et de livraison. +
- +
-===== 7. Étape 4 — Validation de la beta ===== +
- +
-La validation de la beta est une étape distincte de sa génération. +
- +
-Le responsable de la validation vérifie les fonctionnalités concernées et les résultats des tests prévus. +
- +
-Les anomalies constatées doivent être enregistrées et traitées. +
- +
-Lorsque des corrections sont nécessaires : +
- +
-  * le développeur réalise les modifications sur une branche personnelle ; +
-  * les corrections sont intégrées par ''/fusion-dev'' ; +
-  * une nouvelle beta peut être générée avec ''/release-beta'' ; +
-  * les tests nécessaires sont renouvelés. +
- +
-Une beta ne doit pas être considérée comme validée uniquement parce que sa compilation a réussi. +
- +
-La décision de poursuivre vers une release client est prise par le responsable habilité, conformément à la chaîne de qualification et de livraison. +
- +
-===== 8. Étape 5 — Publication client ===== +
- +
-==== 8.1 Conditions préalables ==== +
- +
-Avant la publication client, vérifier : +
- +
-  * que la version à livrer est identifiée ; +
-  * que les validations requises sont réalisées ; +
-  * que les anomalies bloquantes sont traitées ; +
-  * que la branche de version est propre et à jour ; +
-  * que les modifications apportées depuis la dernière beta ont été examinées, lorsqu'une beta existe. +
- +
-Si des changements fonctionnels importants ont été ajoutés après la beta, une nouvelle phase de validation peut être nécessaire. +
- +
-==== 8.2 Génération ==== +
- +
-Dans ''logeas-web'', sur la branche de version, lancer : +
- +
-<code> +
-/release-client +
-</code> +
- +
-La commande réalise les opérations de préparation de la release : +
- +
-  * vérification du dépôt ; +
-  * calcul du numéro de release ; +
-  * génération du build de production ; +
-  * génération du rapport de release ; +
-  * création du commit de préparation ; +
-  * création et publication du tag de release ; +
-  * préparation du rapport qualité NF dans le dépôt de cartographie. +
- +
-Le build est généré dans : +
- +
-<code> +
-D:\Developpements\VersionPublic\LogeasWeb\browser\ +
-</code> +
- +
-Le numéro de release utilise le format ''X.Y.Z_release'' pour le tag. +
- +
-==== 8.3 Vérifications après génération ==== +
- +
-Après l'exécution, vérifier : +
- +
-  * que la génération s'est terminée sans erreur bloquante ; +
-  * que le numéro de version est cohérent avec le cycle ; +
-  * que le tag de release est correct ; +
-  * que le build de production est présent dans le répertoire attendu ; +
-  * que le rapport de release est disponible ; +
-  * que le rapport qualité NF a été régénéré et peut être relu. +
- +
-Le rapport qualité NF doit être relu avant son intégration dans ''logeas-cartographie''. Sa validation et son commit ne doivent pas être considérés comme automatiques. +
- +
-==== 8.4 Release sans beta préalable ==== +
- +
-Une release peut exceptionnellement être générée sans beta préalable. +
- +
-Cette possibilité ne dispense pas des contrôles techniques et de la validation nécessaires à la livraison. +
- +
-La décision et sa justification doivent être conservées dans les éléments de suivi de la livraison, selon les modalités prévues par la chaîne de qualification. +
- +
-===== 9. Étape 6 — Déploiement en production ===== +
- +
-Le déploiement est réalisé après la décision de livraison. +
- +
-Il reste manuel et nécessite l'accès au serveur de production. +
- +
-La personne habilitée doit : +
- +
-  * récupérer le contenu du répertoire de production ; +
-  * transférer les fichiers vers le serveur concerné ; +
-  * vérifier la bonne copie des fichiers ; +
-  * contrôler l'accès à l'application après déploiement ; +
-  * signaler toute anomalie constatée. +
- +
-Le tag Git et le rapport de release permettent d'identifier la version source du déploiement. +
- +
-Les opérations de déploiement et les éventuels contrôles complémentaires sont documentés dans les procédures d'exploitation applicables. +
- +
-===== 10. Cas particulier — Changement de version mineure ===== +
- +
-Lorsqu'une évolution nécessite de passer à une nouvelle version mineure en cours de cycle, une nouvelle branche de version peut être créée.+
  
 Exemple : Exemple :
  
 <code bash> <code bash>
-git checkout 11.0.25+git checkout 11.2.0
 git pull git pull
-git checkout -b 11.1.0 +git checkout -b 11.3.0 
-git push -u origin 11.1.0+git push -u origin 11.3.0
 </code> </code>
  
-L'ancienne branche est conservée avec son historique et ses tags.+La branche doit être **poussée** : une branche sans branche amont est refusée par la qualification.
  
-La nouvelle branche devient la cible des prochaines intégrations.+L'ancienne branche est conservée avec son historique et ses tags. La nouvelle branche devient la cible des prochaines intégrations.
  
-Il faut informer l'équipe de ce changement afin que les développements en cours soient correctement réorientés.+Informer l'équipe de ce changement afin que les développements en cours soient correctement réorientés.
  
-Le calcul automatique de la version tient compte du numéro de la nouvelle branche lors de la prochaine génération beta.+La version candidate est tirée du nom de la branche : la première beta de ''11.3.0'' sera ''11.3.0.1''.
  
-Les règles détaillées de numérotation sont décrites dans la procédure technique du cycle de release. +===== 8. Cas particulier — Correctifs et évolutions en parallèle =====
- +
-===== 11. Cas particulier — Correctifs et évolutions en parallèle =====+
  
 Deux pistes de développement peuvent être maintenues simultanément : Deux pistes de développement peuvent être maintenues simultanément :
- 
-  * une piste de correctifs destinée à la version actuellement utilisée par les clients ; 
-  * une piste d'évolution destinée à une prochaine version. 
- 
-Exemple : 
  
 ^ Piste ^ Usage ^ ^ Piste ^ Usage ^
-| Version en production | Correctifs urgents et corrections nécessaires |+| Version en production | Correctifs de la version utilisée par les clients |
 | Version suivante | Nouvelles fonctionnalités et évolutions | | 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. +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).
- +
-Il faut donc vérifier que les correctifs nécessaires sont également intégrés à la branche d'évolution. +
- +
-==== 11.1 Changement de version des bibliothèques ====+
  
-''logeas-web'' utilise les bibliothèques de ''logeas-lib'' sous forme de paquets construits.+==== 8.1 Bascule entre versions ====
  
-Un simple changement de branche Git ne suffit pas à garantir que les dépendances correspondent à la version souhaitée.+''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 permet d'automatiser le changement de configuration :+Le script suivant bascule le poste sur une paire de branches web / lib, reconstruit la bibliothèque et la réinstalle :
  
 <code> <code>
Ligne 372: Ligne 217:
 </code> </code>
  
-Exemples de commandes :+Exemples :
  
 <code powershell> <code powershell>
Ligne 382: Ligne 227:
 </code> </code>
  
-Les profils déterminent les branches à utiliser pour ''logeas-web'' et ''logeas-lib''.+<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 concernés ne contiennent pas de modifications locales non sauvegardées.+Avant d'utiliser cet outil, vérifier que les dépôts ne contiennent pas de modifications locales non sauvegardées.
  
-Le script peut également signaler des commits présents sur une piste et absents de l'autre. Il faut examiner ces écarts avant de poursuivre. +Le script signale les correctifs d'une version antérieure pas encore reportés sur l'autre piste. Examiner ces écarts avant de poursuivre.
- +
-Après un changement de version, vérifier que les paquets ont été reconstruits et que les dépendances installées correspondent à la branche sélectionnée.+
  
 Les profils doivent être actualisés lorsqu'une nouvelle organisation de branches est mise en place. Les profils doivent être actualisés lorsqu'une nouvelle organisation de branches est mise en place.
  
-===== 12. Commandes et précautions =====+===== 9. Commandes et précautions =====
  
-==== 12.1 Commandes de publication ====+==== 9.1 Commandes Claude Code ====
  
 ^ Commande ^ Utilisation ^ ^ Commande ^ Utilisation ^
-| ''/fusion-dev'' | Intégrer le travail personnel à la branche commune | +| ''/fusion-dev'' | Intégrer le travail personnel à la branche de version | 
-| ''/release-beta'' | Générer et publier une beta | +| ''/qualifier-version'' | Vérifier les préconditions de la qualification, puis renvoyer vers ''qualifier-version.bat'' | 
-| ''/release-client'' | Générer et publier une release client | +| ''/release-beta'' | Vérifier la porte beta, expliquer ce qui bloque, puis renvoyer vers ''livrer-beta.bat'' | 
-| ''/rapport-tests-qualite'' | Régénérer le rapport qualité NF |+| ''/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) |
  
-Ces commandes sont exécutées dans Claude Code, depuis le dépôt approprié.+Seule ''/fusion-dev'' modifie le dépôt. Les commandes ''/qualifier-version'', ''/release-beta'' et ''/release-client'' **ne livrent rien elles-mêmes**.
  
-==== 12.2 Génération manuelle d'un build ====+==== 9.2 Génération manuelle d'un build ====
  
-Les commandes Angular suivantes permettent de générer un build sans réaliser l'ensemble du processus de publication :+Les commandes suivantes génèrent un build **hors chaîne** :
  
 <code bash> <code bash>
Ligne 416: Ligne 262:
 </code> </code>
  
-Ces commandes ne remplacent pas les procédures de release. +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 réalisent pas nécessairement le calcul de version, la génération du rapport, la création des tags ou les autres opérations de traçabilité.+
  
-Elles ne doivent donc pas être utilisées pour produire directement une livraison officielle destinée aux utilisateurs.+Elles ne doivent pas être utilisées pour une livraison normale. Leur usage en urgence est décrit dans Proc#168, cas 8.
  
-==== 12.3 Précautions générales ====+==== 9.3 Précautions générales ====
  
 Avant toute opération : Avant toute opération :
Ligne 430: Ligne 274:
   * ne jamais utiliser ''git push --force'' sur une branche commune ;   * ne jamais utiliser ''git push --force'' sur une branche commune ;
   * ne pas supprimer ou réécrire les tags d'une version publiée ;   * ne pas supprimer ou réécrire les tags d'une version publiée ;
-  * ne pas contourner les contrôles bloquants ;+  * **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.   * 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. 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.
  
-===== 13. Aide-mémoire Git et SourceTree =====+===== 10. Aide-mémoire Git et SourceTree =====
  
-Les commandes de release exécutent automatiquement les opérations Git prévues. Le tableau ci-dessous sert principalement au dépannage et aux vérifications manuelles.+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 ^ ^ Commande Git ^ Équivalent SourceTree ^
Ligne 451: Ligne 295:
 | ''git log <a>..<b>'' | Consultation de l'historique entre deux références | | ''git log <a>..<b>'' | Consultation de l'historique entre deux références |
  
-Lors d'une publication manuelle, vérifier que le tag est bien envoyé au dépôt distant. Un tag créé localement mais non publié ne constitue pas une preuve de publication partagée.+Un tag créé localement mais non publié ne constitue pas une preuve de publication partagée.
  
-===== 14. Traçabilité et conservation =====+===== 11. Révision du guide =====
  
-Pour chaque version publiée, les éléments suivants doivent pouvoir être retrouvés :+Ce guide doit être actualisé lorsque les commandes, les scripts, les branches de version ou les modalités de publication évoluent.
  
-  * la branche de version concernée ; +Les modifications doivent rester cohérentes avec Proc#168 et Proc#169.
-  * les commits intégrés ; +
-  * le commit de préparation de version ; +
-  * le tag beta ou release ; +
-  * les informations de version embarquées ; +
-  * le rapport de release ; +
-  * les résultats de qualification et de recette ; +
-  * les éléments de validation et de déploiement applicables. +
- +
-Les rapports de release sont accessibles depuis l'application et les outils de suivi prévus à cet effet. +
- +
-Le suivi des versions, des tests et des validations est assuré par les outils de cartographie fonctionnelle et de certification. +
- +
-Les règles de conservation et d'archivage des preuves sont définies dans la chaîne de qualification et de livraison. +
- +
-===== 15. 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 la procédure technique de release et la chaîne de qualification et de livraison.