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:proceduremiseenligne:logeas-web [2026/09/28 17:14] – nicolascertif:procedure:develop:proceduremiseenligne:logeas-web [2026/09/30 10:33] (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:gestionversionpratique]]|
  
-====== Cycle de release LoGeAs Web ======+====== Proc#169 - Cycle de release LoGeAs Web ======
  
-===== 1. Objet et périmètre =====+===== Informations qualité =====
  
-Ce document décrit le dispositif technique de gestion des versions et de publication de LoGeAs Web, depuis l'intégration des développements jusqu'à la production des versions destinées aux utilisateurs.+^Suivi des modifications majeures^^^ 
 +^Date^Auteur^Modifications^ 
 +|3 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) : la livraison est faite par les scripts ''livrer-beta'' et ''livrer-release'' derrière les portes bloquantes, ajout de la qualification et de la recette, suppression de la release sans beta ; mise au format de la maîtrise documentaire| 
 + 
 +|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=169|Cartographie fonctionnelle – fiche de la procédure]]| 
 +|**Objet** |Décrire le dispositif technique de gestion des versions et de publication de LoGeAs Web, depuis l'intégration des développements jusqu'à la production des versions destinées aux utilisateurs, pour les dépôts ''logeas-web'' et, lorsque nécessaire, ''logeas-lib''.| 
 +|**Destinataires** |**- Validation des modifications :** Gérant \\ **- Approbation du document :** Équipe développement| 
 + 
 +\\ 
 + 
 +===== 1. Objet et périmètre =====
  
-Il constitue la référence technique du processus de release pour les dépôts ''logeas-web'' et, lorsque nécessaire, ''logeas-lib''.+Ce document décrit le dispositif technique de gestion des versions et de publication de LoGeAs Web : les scripts, les fichiers produits, le calcul des numéros de version et les éléments de preuve.
  
 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 et d'identification des versions. +  * [[certif:procedure:develop:gestionversion|Proc#145 - Procédure de gestion des versions]] : règles générales de versionnage et d'identification des versions. 
-  * [[certif:procedure:develop:chainequalificationlivraison|Chaîne de qualification et de livraison]] : processus qualité, responsabilités, qualification et validation.+  * [[certif:procedure:develop:chainequalificationlivraison|Proc#168 - Chaîne de qualification et de livraison]] : déroulé pas à pas, responsabilités, qualification, validation, recette et portes bloquantes.
   * [[certif:procedure:develop:gestionversionpratique|Guide pratique de gestion des versions]] : mode opératoire destiné aux développeurs.   * [[certif:procedure:develop:gestionversionpratique|Guide pratique de gestion des versions]] : mode opératoire destiné aux développeurs.
  
-Le présent document décrit le fonctionnement technique du dispositif. Il ne remplace ni les décisions de validation ni les contrôles de qualification prévus dans la chaîne de livraison.+**En cas de divergence entre ce document et Proc#168 sur le déroulé d'une livraison, Proc#168 fait foi.** Le présent document explique comment le dispositif fonctionne ; il ne remplace ni les décisions de validation ni les contrôles de qualification.
  
 ===== 2. Objectifs ===== ===== 2. Objectifs =====
Ligne 24: Ligne 35:
   * **Reproductibilité** : exécuter les opérations techniques selon une procédure identifiée et maîtrisée.   * **Reproductibilité** : exécuter les opérations techniques selon une procédure identifiée et maîtrisée.
   * **Traçabilité** : relier chaque version publiée à son code source, à ses commits et aux résultats des contrôles.   * **Traçabilité** : relier chaque version publiée à son code source, à ses commits et aux résultats des contrôles.
-  * **Sécurisation** : empêcher la production d'une livraison lorsque les contrôles techniques obligatoires échouent.+  * **Sécurisation** : empêcher la production d'une livraison lorsque les contrôles obligatoires ne sont pas satisfaits.
   * **Séparation des environnements** : distinguer les versions de test des versions destinées aux utilisateurs.   * **Séparation des environnements** : distinguer les versions de test des versions destinées aux utilisateurs.
   * **Maîtrise du versionnage** : éviter les collisions, les incohérences et les versions non identifiables.   * **Maîtrise du versionnage** : éviter les collisions, les incohérences et les versions non identifiables.
Ligne 31: Ligne 42:
 ===== 3. Architecture générale du cycle ===== ===== 3. Architecture générale du cycle =====
  
-Le cycle de publication repose sur quatre étapes :+Le cycle de publication suit les huit étapes de la chaîne de qualification et de livraison (Proc#168) :
  
-^ Étape ^ Opération ^ Résultat ^ +^ Étape ^ Opération ^ Outil ^ Résultat ^ 
-| 1 | Travail personnel | Développements enregistrés dans une branche individuelle | +| 1 | Travail personnel puis intégration | ''/fusion-dev'' | Code intégré et contrôlé sur la branche de version | 
-| 2 | Intégration (''/fusion-dev'') | Code intégré et contrôlé sur la branche commune | +| 2 | Qualification | ''scripts\qualifier-version.bat'' | Rapport qualité de la version candidate, en brouillon | 
-| 3 | Publication beta (''/release-beta'') | Version de test, taguée et accompagnée de son rapport | +| 3 | Validation du rapport qualité | carto, écran « Rapports de version » | Rapport validé (avec ou sans réserves) et publié | 
-| 4 | Publication client (''/release-client'') | Version de production, taguée et accompagnée de ses éléments de traçabilité |+| 4 | Beta | ''scripts\livrer-beta.bat'' | Version de test construite, taguée, avec son rapport de release | 
 +| 5 | Déploiement sur le serveur de test | copie manuelle | Beta disponible pour la recette | 
 +| 6 | Recette de la beta | carto, écran « Rapports de version » | Recette conforme ou non conforme | 
 +| 7 | Release client | ''scripts\livrer-release.bat'' | Version de production construite et taguée | 
 +| 8 | Déploiement client | copie manuelle | Version en ligne |
  
-Les étapes 2 à 4 sont assistées par des commandes dédiées de Claude Code.+Deux **portes bloquantes** encadrent les livraisons : la porte beta (avant l'étape 4) et la porte release (avant l'étape 7). Elles sont décrites dans Proc#168.
  
 Le passage d'une étape à l'autre reste une décision humaine. L'automatisation réalise les opérations et les contrôles prévus, mais ne décide pas de la pertinence fonctionnelle d'une livraison. Le passage d'une étape à l'autre reste une décision humaine. L'automatisation réalise les opérations et les contrôles prévus, mais ne décide pas de la pertinence fonctionnelle d'une livraison.
  
-Une publication client peut exceptionnellement être réalisée sans beta préalable lorsque le contexte le justifie. Les contrôles techniques applicables à la release restent alors obligatoires.+**Rôle des commandes de l'assistant Claude Code.** ''/fusion-dev'' réalise l'intégration. ''/qualifier-version'', ''/release-beta'' et ''/release-client'' **ne livrent rien elles-mêmes** : elles vérifient les préconditions ou la porte, expliquent ce qui bloque, puis renvoient vers les scripts ci-dessus, lancés par le développeur. 
 + 
 +**Il n'y a pas de release client sans beta recettée** : la porte release l'exige. La seule exception est la procédure d'urgence (Proc#168, cas 8), qui produit une version affichée « Version non qualifiée » et doit être régularisée.
  
 ===== 4. Organisation des dépôts et des environnements ===== ===== 4. Organisation des dépôts et des environnements =====
Ligne 52: Ligne 69:
  
 ^ Dépôt ^ Rôle ^ ^ Dépôt ^ Rôle ^
-| ''logeas-web'' | Interface Angular LoGeAs Web et scripts de génération des versions |+| ''logeas-web'' | Interface Angular LoGeAs Web et scripts de qualification et de livraison |
 | ''logeas-lib'' | Bibliothèques Angular partagées utilisées par les interfaces | | ''logeas-lib'' | Bibliothèques Angular partagées utilisées par les interfaces |
-| ''logeas-cartographie'' | Conservation et publication des éléments de cartographie et des rapports qualité |+| ''logeas-cartographie'' | Cartographie fonctionnelle : écran « Rapports de version » (validation des rapports qualité, recette) |
  
-Les bibliothèques de ''logeas-lib'' sont utilisées par ''logeas-web'' sous forme de paquets construits. Le changement de branche ne suffit donc pas à garantir la cohérence des dépendances : les paquets doivent correspondre aux versions de bibliothèques prévues pour le cycle concerné.+Les bibliothèques de ''logeas-lib'' sont utilisées par ''logeas-web'' sous forme de paquets construits. Le changement de branche ne suffit donc pas à garantir la cohérence des dépendances : les paquets installés doivent correspondre au code de la bibliothèque. C'est pourquoi la qualification reconstruit et réinstalle ''logeas-lib'', et pourquoi les portes vérifient que les paquets installés sont toujours ceux du run qualifié.
  
 ==== 4.2 Environnements de génération ==== ==== 4.2 Environnements de génération ====
Ligne 79: Ligne 96:
 Le transfert vers les serveurs de test et de production est réalisé manuellement, par une personne disposant des accès nécessaires au bureau à distance. Le transfert vers les serveurs de test et de production est réalisé manuellement, par une personne disposant des accès nécessaires au bureau à distance.
  
-Les commandes de release ne réalisent pas elles-mêmes ce transfert.+Les scripts de livraison ne réalisent pas eux-mêmes ce transfert.
  
 ===== 5. Description technique des étapes ===== ===== 5. Description technique des étapes =====
Ligne 121: Ligne 138:
 **Résultat attendu :** une branche de version intégrée, contrôlée et accompagnée d'un historique de fusion exploitable. **Résultat attendu :** une branche de version intégrée, contrôlée et accompagnée d'un historique de fusion exploitable.
  
-==== 5.3 Publication beta : /release-beta ====+==== 5.3 Qualification : qualifier-version ====
  
-La commande ''/release-beta'' produit une version destinée à la validation interne.+Le script ''scripts\qualifier-version.bat'' produit le rapport qualité de la prochaine version, sur un code identifié sans ambiguïté.
  
-Elle est exécutée depuis la branche de version commune, préalablement intégrée et mise à jour.+Il réalise les opérations suivantes :
  
-Les opérations techniques sont les suivantes :+  * vérification des préconditions sur ''logeas-web'' et ''logeas-lib'' : branche de version, aucune modification locale, branche à jour et poussée ; 
 +  * calcul et affichage de la **version candidate** (la prochaine beta) ; 
 +  * reconstruction de ''logeas-lib'' depuis son dernier commit et réinstallation dans ''logeas-web'' ; 
 +  * démarrage des serveurs locaux (confirmation UAC) ; 
 +  * tests unitaires des deux dépôts, puis tests d'interface (Playwright) ; 
 +  * génération du rapport qualité et de son analyse ; 
 +  * dépôt du rapport, en brouillon, sur le serveur Nono.
  
-  * vérification de l'état du dépôt et de la branche ; +Le rapport est nommé ''run-<version>-<AAAAMMJJ-HHMM>.html'' et porte la clé du code testé (commits des deux dépôts, empreinte des paquets ''logeas-lib'').
-  * calcul du numéro de version beta ; +
-  * mise à jour des informations de version ; +
-  * régénération des éléments nécessaires à la compilation ; +
-  * compilation en configuration de production beta ; +
-  * génération du rapport de release ; +
-  * enregistrement des éléments de version dans un commit dédié ; +
-  * création d'un tag Git annoté ; +
-  * publication du commit et du tag sur le dépôt distant.+
  
-La génération utilise la commande :+Le rapport est ensuite validé, validé avec réserves ou refusé dans la carto (Proc#168, « Validation du rapport qualité »).
  
-<code bash> +==== 5.4 Beta : livrer-beta ====
-npm run build:beta +
-</code>+
  
-Le script de version est exécuté en mode ''beta'' et le build Angular utilise la configuration ''production,beta''.+Le script ''scripts\livrer-beta.bat'' produit la version destinée à la recette. Il s'arrête au premier échec.
  
-Le résultat est déposé dans le répertoire de test :+Les opérations techniques sont les suivantes :
  
-<code> +  - **porte beta** (''scripts/porte-livraison.js beta'') : les deux dépôts sont propres, à jour et poussés, et un rapport de qualification de la version candidate, validé, porte exactement le dernier commit des deux dépôts et les mêmes paquets ''logeas-lib'' ; 
-D:\Developpements\VersionPublic\LogeasWeb-Test\browser\ +  - mise à jour du numéro de version, 4ᵉ chiffre (''npm run prebuild:beta'', qui exécute ''scripts/version.js beta'') ; 
-</code>+  - génération du rapport de release (''scripts/release-report.js beta --qualification'') : les tests unitaires et le résumé des tests d'interface y sont **repris** de la qualification, rien n'est rejoué ; 
 +  - compilation : ''ng build --configuration production,beta'', vers ''D:\Developpements\VersionPublic\LogeasWeb-Test\'' ; 
 +  - commit dédié « Preparation version X.Y.Z.W », tag annoté ''X.Y.Z.W_beta'' et, si besoin, tag ''web-X.Y.Z.W_beta'' dans ''logeas-lib'' ; 
 +  - après confirmation : publication du commit et du tag, **inscription de la beta dans la trace du rapport qualité** (indispensable à la porte release), reprise du rapport de release dans la carto.
  
-Le rapport de release est généré par le script ''scripts/release-report.js''.+Si le rapport de release ou le build échoue, la mise à jour du numéro de version est annulée : rien n'est commité ni tagué.
  
-Il comprend notamment :+La beta ne vaut pas validation fonctionnelle : elle fournit l'artefact et les éléments de traçabilité destinés à la recette.
  
-  * les changements identifiés dans l'historique Git depuis la dernière release ; +==== 5.5 Release client : livrer-release ====
-  * les informations de version ; +
-  * les résultats des tests disponibles et leur couverture ; +
-  * les versions des composants de la Galaxie LoGeAs identifiées à partir des exécutables disponibles.+
  
-Le rapport HTML est enregistré dans ''src/assets/releases/'' et référencé dans ''manifest.json''.+Le script ''scripts\livrer-release.bat'' produit la version destinée aux utilisateurs. Son déroulé est le même que celui de la beta, derrière la porte release.
  
-Le tag beta suit la convention :+  - **porte release** (''scripts/porte-livraison.js release'') : le tag de la beta est le dernier commit de ''logeas-web'' (**aucun commit depuis la beta**), ''logeas-lib'' est toujours au commit qualifié, le rapport qualité est toujours validé et la **recette de cette beta est « Conforme »** ; 
 +  - mise à jour du numéro de version à 3 chiffres (''npm run prebuild'', qui exécute ''scripts/version.js release'') ; 
 +  - génération du rapport de release ; 
 +  - compilation : ''ng build --configuration production'', vers ''D:\Developpements\VersionPublic\LogeasWeb\'' ; 
 +  - commit dédié, tag annoté ''X.Y.Z_release'' ; 
 +  - après confirmation : publication, inscription de la release dans la trace du rapport qualité.
  
-<code> +Le rapport qualité, publié lors de sa validation, est la pièce qualité de la release.
-X.Y.Z.W_beta +
-</code>+
  
-La publication beta ne vaut pas validation fonctionnelle. Elle fournit un artefact et des éléments de traçabilité destinés à la phase de test. +**Tout correctif après une beta impose une nouvelle qualification et une nouvelle beta** (Proc#168, cas 3) : aucune modification n'est admise entre la beta recettée et la release.
- +
-==== 5.4 Publication client : /release-client ==== +
- +
-La commande ''/release-client'' produit la version destinée aux utilisateurs. +
- +
-Elle est exécutée sur la branche de version concernée. +
- +
-Lorsque la release fait suite à une beta, les changements intervenus depuis cette beta sont examinés. Si des évolutions fonctionnelles importantes ont été intégrées, une nouvelle beta peut être nécessaire. +
- +
-La génération utilise : +
- +
-<code bash> +
-npm run build +
-</code> +
- +
-Le script de version est exécuté en mode ''release'', puis Angular compile l'application avec la configuration ''production''. +
- +
-Les opérations comprennent : +
- +
-  * la vérification de l'état du dépôt ; +
-  * le contrôle de la cohérence avec la beta, lorsqu'elle existe ; +
-  * le calcul du numéro de release ; +
-  * la génération du build de production ; +
-  * la génération du rapport de release ; +
-  * la création du commit de préparation de version ; +
-  * la création du tag Git annoté ; +
-  * la publication du commit et du tag ; +
-  * la mise à jour du rapport qualité NF dans le dépôt ''logeas-cartographie''. +
- +
-Le build est généré dans : +
- +
-<code> +
-D:\Developpements\VersionPublic\LogeasWeb\browser\ +
-</code> +
- +
-Le tag de publication suit la convention : +
- +
-<code> +
-X.Y.Z_release +
-</code>+
  
-Le rapport qualité NF est généré à partir des résultats réels des tests de ''logeas-web'' et ''logeas-lib''. Il doit être relu avant son intégration dans le dépôt de cartographie.+==== 5.6 Build hors chaîne ====
  
-Le déploiement sur le serveur de production reste une opération distincte, réalisée manuellement après validation de la livraison.+Les commandes ''npm run build:beta'' et ''npm run build'' restent utilisables, mais elles produisent une version **hors chaîne**, affichée « Version non qualifiée » dans « À propos > Logiciel » et dans son rapport de release. Elles ne doivent pas être utilisées pour une livraison normale ; leur usage en urgence est décrit dans Proc#168, cas 8.
  
 ===== 6. Gestion des versions ===== ===== 6. Gestion des versions =====
Ligne 249: Ligne 225:
 Pour une beta, le quatrième chiffre est incrémenté à chaque nouvelle génération du même cycle. Pour une beta, le quatrième chiffre est incrémenté à chaque nouvelle génération du même cycle.
  
-Lorsqu'une nouvelle branche numérotée correspond à un cycle ultérieur, le script peut utiliser son numéro comme nouvelle base de version.+Lorsqu'une nouvelle branche numérotée correspond à un cycle ultérieur, le script utilise son numéro comme nouvelle base de version.
  
 Pour une release, le quatrième chiffre est supprimé. Le numéro ''X.Y.Z'' utilisé par les betas est repris s'il n'a pas déjà été publié. Si une release portant ce numéro existe déjà, le script avance vers un nouveau numéro conformément à la règle implémentée. Pour une release, le quatrième chiffre est supprimé. Le numéro ''X.Y.Z'' utilisé par les betas est repris s'il n'a pas déjà été publié. Si une release portant ce numéro existe déjà, le script avance vers un nouveau numéro conformément à la règle implémentée.
 +
 +La commande ''node scripts/version.js beta --simuler'' affiche la version candidate sans rien modifier.
  
 ==== 6.3 Traçabilité de la version ==== ==== 6.3 Traçabilité de la version ====
Ligne 267: Ligne 245:
 ==== 6.4 Cas particuliers ==== ==== 6.4 Cas particuliers ====
  
-Les cas de changement de version mineure, de correction urgente et de travail parallèle sur plusieurs versions sont décrits dans le [[certif:procedure:develop:gestionversionpratique|guide pratique]].+Les cas de changement de version mineure, de correction d'une version déjà livrée et de travail parallèle sur plusieurs versions sont décrits dans Proc#168 (cas 6 et 7) et dans le [[certif:procedure:develop:gestionversionpratique|guide pratique]].
  
 Ils ne doivent pas conduire à réécrire l'historique d'une version déjà publiée. Ils ne doivent pas conduire à réécrire l'historique d'une version déjà publiée.
Ligne 276: Ligne 254:
  
 ^ Contrôle ^ Étape concernée ^ Objectif ^ ^ Contrôle ^ Étape concernée ^ Objectif ^
-| Vérification de l'état du dépôt | Intégration, beta, release | Éviter de publier à partir d'un état local non maîtrisé | +| État des dépôts (propres, à jour, poussés) | Intégration, qualification, beta, release | Éviter de publier à partir d'un état local non maîtrisé | 
-| Vérification de la branche | Toutes les étapes outillées | Garantir que l'opération concerne la branche attendue | +| Branche de version | Toutes les étapes outillées | Garantir que l'opération concerne la branche attendue | 
-| Compilation | Intégration, beta, release | Détecter les erreurs de compilation | +| Compilation, tests unitaires, lint | Intégration | Détecter les erreurs avant l'intégration | 
-| Tests unitaires | Intégration et processus de qualification | Vérifier le comportement du code | +| Tests unitaires et tests d'interface | Qualification | Produire le rapport qualité de la version candidate | 
-| Contrôle du numéro de version | Beta et release | Éviter les incohérences de versionnage | +| Porte beta | Beta | N'ouvrir une beta que sur un code qualifié, avec un rapport validé | 
-| Vérification des tags | Beta et release | Éviter les collisions et préserver la traçabilité | +| Porte release | Release | N'ouvrir une release que sur la beta recettée conforme, sans commit depuis | 
-| Séparation des répertoires de sortie | Beta et release | Empêcher la confusion entre test et production | +| Paquets ''logeas-lib'' installés | Beta, release | Garantir que la bibliothèque livrée est celle qui a été qualifiée | 
-| Vérification des commits intégrés | Intégration | Conserver la traçabilité des changements | +| Numéro de version et tags | Beta, release | Éviter les collisions et préserver la traçabilité | 
-| Rapport de release | Beta et release | Documenter les changements et les résultats disponibles |+| Séparation des répertoires de sortie | Beta, release | Empêcher la confusion entre test et production | 
 +| Liste des commits intégrés | Intégration | Conserver la traçabilité des changements | 
 +| Rapport de release | Beta, release | Documenter les changements et renvoyer au rapport qualité |
  
-En cas d'échec d'un contrôle bloquant, la procédure doit s'arrêter et signaler l'anomalie.+En cas d'échec d'un contrôle bloquant, la procédure s'arrête et signale l'anomalie. **Une porte ne se contourne jamais** : si le blocage est injustifié, c'est un défaut des scripts, à signaler et corriger.
  
 Aucune procédure ne doit résoudre silencieusement un conflit métier ou écraser des modifications non validées. Aucune procédure ne doit résoudre silencieusement un conflit métier ou écraser des modifications non validées.
  
-Les opérations de publication ne doivent pas utiliser ''push --force'' ni supprimer automatiquement des branches ou des tags.+Les opérations de publication n'utilisent pas ''push --force'' et ne suppriment pas automatiquement des branches ou des tags.
  
-Les éventuels échecs de tests préexistants doivent être identifiés et distingués des régressions introduites par le changement en cours.+Les échecs de tests déjà connus doivent être identifiés et distingués des régressions introduites par le changement en cours : c'est l'objet de la décision « Validé avec réserves » (Proc#168).
  
 ===== 8. Rapports et éléments de preuve ===== ===== 8. Rapports et éléments de preuve =====
Ligne 300: Ligne 280:
   * l'historique Git de la branche concernée ;   * l'historique Git de la branche concernée ;
   * le commit de fusion et la liste des commits intégrés ;   * le commit de fusion et la liste des commits intégrés ;
-  * le commit de préparation de version ; +  * le commit « Preparation version » ; 
-  * le tag annoté de beta ou de release ;+  * le tag annoté de beta ou de release (et le tag ''web-*'' de ''logeas-lib'') ;
   * les informations intégrées dans ''version.ts'' ;   * les informations intégrées dans ''version.ts'' ;
-  * le rapport de release HTML ; +  * le **rapport qualité** de la version (''run-<version>-<date>.html''), sa décision de validation et la recette de la beta ; 
-  * le rapport qualité NF correspondant, lorsqu'il est applicable ; +  * le **rapport de release** HTML, enregistré dans ''src/assets/releases/'' et référencé dans ''manifest.json''.
-  * les résultats des tests et de la qualification ; +
-  * les éléments attestant de la validation et du déploiement.+
  
-Les rapports de version publiés sont consultables dans l'application, notamment depuis l'écran « Rapports de release ».+^ Élément ^ Où le consulter ^ 
 +| Rapports qualité, décisions, recettes, rapports de release | carto, écran « Rapports de version » ([[https://cartographie-fonctionnelle.logeas-web.fr/RapportsVersion]]) | 
 +| Historique d'un rapport (validation, publication, beta, recette, release) | table ''ApprobDoc'' du serveur Nono, trace du rapport | 
 +| Qualification d'une version livrée | son rapport de release et « À propos > Logiciel » |
  
-Le suivi des versions et des tests est également accessible depuis la cartographie fonctionnelle et les outils de suivi associés. +Les modalités de validation et de conservation de ces preuves relèvent de la [[certif:procedure:develop:chainequalificationlivraison|chaîne de qualification et de livraison]].
- +
-Les modalités de conservation et de validation des preuves relèvent de la [[certif:procedure:develop:chainequalificationlivraison|chaîne de qualification et de livraison]].+
  
 ===== 9. Opérations restant manuelles ===== ===== 9. Opérations restant manuelles =====
Ligne 319: Ligne 298:
  
   * le choix du moment de l'intégration ;   * le choix du moment de l'intégration ;
-  * la décision de créer une beta ; +  * le lancement de la qualification ; 
-  * la validation fonctionnelle de la beta ; +  * la relecture et la validation du rapport qualité ; 
-  * la décision de livrer une release ; +  * le lancement de la beta ; 
-  * la relecture et la validation des rapports ;+  * la recette de la beta ; 
 +  * le lancement de la release ;
   * le transfert des fichiers générés vers les serveurs ;   * le transfert des fichiers générés vers les serveurs ;
   * la vérification du déploiement sur l'environnement cible.   * la vérification du déploiement sur l'environnement cible.
Ligne 339: Ligne 319:
   * la reproductibilité des générations ;   * la reproductibilité des générations ;
   * la séparation des environnements ;   * la séparation des environnements ;
-  * la fiabilité des contrôles ;+  * la fiabilité des contrôles et des portes ;
   * la conservation des preuves nécessaires à la certification.   * la conservation des preuves nécessaires à la certification.
  
 La présente procédure doit être révisée lorsque le fonctionnement effectif du cycle de release évolue. La présente procédure doit être révisée lorsque le fonctionnement effectif du cycle de release évolue.
 +