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:gestionversion [2026/08/01 18:16] – [Dépot] nicolascertif:procedure:develop:gestionversion [2026/09/30 09:50] (Version actuelle) – [Proc#145 - Procédure de Gestion des Versions] nicolas
Ligne 1: Ligne 1:
 |{{:undo-2.svg?30|}} [[certif:do#procedures|Retour au Dossier Organisationnel]]|| |{{:undo-2.svg?30|}} [[certif:do#procedures|Retour au Dossier Organisationnel]]||
-|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[:certif:procedure:develop:gestionsvn]]\\ [[:certif:procedure:develop:gestionprojeqtor|]] \\ [[:certif:procedure:develop:gestionsdepotgit]] \\ [[:certif:procedure:develop:proceduremiseaucoffredescodes]]|+|{{:connexe.jpg?40|}} **Sujets connexes**|[[https://cartographie-fonctionnelle.logeas-web.fr/|Cartographie fonctionnelle de LoGeAs]]\\ [[certif:procedure:develop:gestionversionpratique]]\\ [[certif:procedure:develop:chainequalificationlivraison]]| 
 +====== Proc#145 : Procédure de Gestion des Versions ======
  
-====== Procédure de gestion des versions de LoGeAs (procédure #06) ====== 
  
  
 ===== Informations qualité ===== ===== Informations qualité =====
 +^Suivi des modifications majeures^^^
 +^Date^Auteur^Modifications^
 +|5 mars 2015|Nicolas MARCHAND|Création du document|
 +|1 décembre 2015|Nicolas MARCHAND|Modification par rapport aux tests à passer suivant le niveau des mises à jour|
 +|14 décembre 2015|Guillaume NATALI|Modification des règles de numérotation|
 +|2 août 2017|Nicolas MARCHAND|Portage sur DokuWiki et évolutions|
 +|28 août 2020|Nicolas MARCHAND|Évolution des raisons de changement de version|
 +|Janvier 2026|Nicolas MARCHAND|Refonte suite à l'automatisation (Galaxie LoGeAs, version globale, schéma du processus de mise en ligne)|
 +|11 août 2026|Nicolas MARCHAND|Fusion de toutes les pages relatives à la gestion de version en un seul document (procédures #30 et #09, « Gestion du dépôt Git », doublon ''questionnaire:procedure:develop:gestionversion'') ; nouveau mécanisme de signalement des versions beta (4ᵉ chiffre porteur de la version visée, remplace le signal Y=99) ; alignement du client lourd et des serveurs sur cette même règle|
  
-|**Suivi des modifications majeures** |5 mars 2015 - Nicolas Marchand - Création du document \\ 1 décembre 2015 - Nicolas Marchand - Modification par rapport aux tests à passer suivant le niveau des mises à jour \\ 14 décembre 2015 - Guillaume Natali - Modification des règles de numérotation\\ 02 aout 2017 - Nicolas Marchand - Portage sur DoKuWiKi & Evolutions\\ 28 août 2020 - Nicolas Marchand - Evolution raisons changement de version\\ Janvier 2026 - Nicolas Marchand - Refonte du document suite à l'automatisation du versionning globale| +|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/UniversProcedure?id=145|Cartographie fonctionnelle – fiche de la procédure]]| 
-|**Suivi des approbations** |[[https://cartographie-fonctionnelle.logeas-web.fr/Explication|Cartographie fonctionnelle]]| +|**Objet** |Définir les types de versions mises à disposition, leurs différences, les actions à faire lors de la sortie d'une nouvelle version, les modalités d'intégration du code dans le dépôt Git, et le dépôt légal des codes sources, pour l'ensemble des composants de la Galaxie LoGeAs.| 
-|**Objet** |L'objet de ce document est de définir les différents types des versions mises à disposition, les différences entre elles, et les actions à faire lors de la sortie d'une nouvelle version.| +|**Destinataires** |**- Validation des modifications :** Gérant, ou la personne qu'il désigne \\ **- Approbation du document :** Équipe développement et équipe assistance| 
-|**Destinataires** |**- Validation des modifications : ** Gérant \\  **- Approbation du document** : Equipe dev & Equipe Ass|+|**Origine** |Ce document correspond à l'ancien élément ProjeQtOr Document #06 « Gestion des versions de LoGeAs » (PROC-NFlog-5).|
  
-\\+===== Objectif du Versionnage =====
  
 +Le versionnage constitue le mécanisme qui consiste à conserver la version d'une entité logicielle quelconque, de façon à pouvoir la retrouver facilement.
  
-===== Objectif du versionnage =====+===== Système de Numérotation =====
  
-Selon le [[http://fr.wikipedia.org/wiki/Grand_dictionnaire_terminologique|Grand dictionnaire terminologique]], le versionnage (équivalent francophone de l'anglais //versioning//) est le mécanisme qui consiste à conserver la version d'une entité logicielle quelconque, de façon à pouvoir la retrouver facilement, même après l'apparition et la mise en place de versions plus récentes [[https://fr.wikipedia.org/wiki/Version_d'un_logiciel|Wikipedia]]+Une version LoGeAs représente un état donné d'un produit fourni aux clients. Le numéro comporte 3 chiffres pour une version publiée, 4 pendant sa phase de test beta — ex. ''11.0.3.1''.
  
-===== Définition des types des versions de LoGeAs =====+^ Segment ^ Nom ^ Description ^ 
 +| 1er | Majeur (X) | Numéro « marketing » et technique ; migration technologique majeure | 
 +| 2e | Mineur (Y) | Nouvelles fonctionnalités ou changements de structure de base de données, changement de réglementation, nouvelle certification | 
 +| 3e | Release (Z) | Change à chaque publication du logiciel (obligatoire) ; ne réutilise jamais un numéro déjà publié | 
 +| 4e | Build (W) | Uniquement pendant une phase beta : numéro d'itération de la beta en cours de test. N'apparaît jamais sur une version publiée |
  
-Pour LoGeAs, une **version du logiciel** correspond à un état donné de l'évolution du produit mis à disposition des clients à jour de leur contrat. Contrairement à certains éditeurs qui différencient le numéro de version de développement de celui de commercialisation (Microsoft par exemple), Logeas Informatique utilise une numérotation unique+==== Règles fondamentales ====
  
-La numérotation utilisée est une série de 4 chiffres séparés de points (LoGeAs v11.0.3.1). Pour permettre une meilleure compréhension, nous nommerons cette suite de chiffres de la manière suivante.+  - **Immuabilité** : une version publiée ne peut jamais être modifiée ; toute correction, même mineure, nécessite une nouvelle version. 
 +  - **Cascade** : quand le Majeur change, Mineur/Release/Build reviennent à 0. Quand le Mineur change, Release/Build reviennent à 0.
  
-|**11**|**Majeur**|Logeas Informatique considère le numéro "Majeur" plus comme un numéro "marketing" que "technique", bien que parfois les deux coïncident.\\ __Par exemple :__ \\ * la version 5.0 a vu la migration de la base de données du logiciel de BDE (propriétaire Borland) vers un système multi-base compatible SQL (par exemple SQLite ou Postgress)\\ * la version 6.0 est une simple évolution de la version 5.0, sans changement majeur, mais a été mise en place pour les raisons précédentes après 2 ans et demi de bons services de la V5….\\ * la version 11.0 à vu le début de l'interface full web| +==== Signalement d'une version beta (X.Y.Z.W) ====
-|**0**|**Mineur**|Le numéro de version « Mineure » est changé quand la version met en place de nouvelles fonctionnalités et/ou des changements sont réalisés dans la structure de la base de données (ajout d'un champ par exemple).\\ Quand il y a des changements de règlementation pris en compte ou une nouvelle certification| +
-|**3**|**Release**|Le numéro de version « Release » est changé à chaque évolution du logiciel (plus exactement à chaque évolution d'une composante du logiciel (voir plus loin).| +
-|**0**|**Build**|Le numéro de version «Build» est utilisé en interne pour le suivi des exécutables, des bugs et des tests.|+
  
-**__Règles__** +Une version en cours de test beta porte directement le numéro **X.Y.Z que cette beta vise à publier**, suivi d'un 4ᵉ chiffre **W** qui numérote les itérations successives de cette beta (1, 2, 3…), remis à 1 à chaque nouveau cycle.
-  - Une fois qu'une version est publiée, le contenu de sa version NE DOIT PAS être modifié. Toute modification DOIT être publiée dans une nouvelle version. +
-  - Quand le segment Majeur est changé, les "Mineur", "Release" et "Build" sont remis à 0.\\ De même quand le segment "Mineur" est changé, les "Release" et "Build" sont remis à 0\\ et ainsi de suite.+
  
 +**Exemple concret :**
 +  * Dernière version publiée : ''11.0.25''
 +  * Un correctif est en préparation, sans nouvelle fonctionnalité → il vise ''11.0.26''. Sa 1ʳᵉ beta est numérotée ''11.0.26.1'', un correctif suite à retour de test donne ''11.0.26.2'', etc.
 +  * Une fois validée, la beta ''11.0.26.2'' devient la release ''11.0.26'' (le 4ᵉ chiffre est retiré, le X.Y.Z ne change pas — cohérent avec la règle de cascade : seul un changement de Majeur ou Mineur remet Release/Build à 0).
 +  * Une évolution plus importante (nouvelles fonctionnalités) viserait ''11.1.0'' au lieu de ''11.0.26'' (cascade : Mineur incrémenté, Release repart à 0) — ses betas seraient ''11.1.0.1'', ''11.1.0.2'', etc.
  
 +**Pourquoi ce mécanisme plutôt que l'ancien signal ''Y=99''** (utilisé auparavant, y compris dans le code du client lourd) : avec un flag générique, deux cycles beta consécutifs qui ne changent pas le mineur — le cas le plus fréquent — produisent le même numéro de beta, sans moyen de savoir à quelle version future chacun correspond. En faisant porter directement le numéro visé, l'ambiguïté disparaît et la progression reste strictement croissante, sans trou ni collision possible.
  
 +==== Critères de Changement de Version ====
  
 +**Majeur (X)** : évolutions substantielles ou migrations technologiques (ex. changement de base de données).
  
 +**Mineur (Y)** : nouvelles fonctionnalités, modifications de structure de données (ajout de champs), changements de réglementation pris en compte, ou nouvelle certification.
  
 +**Release (Z)** : à chaque publication du logiciel (publication obligatoire) — correctifs, corrections de bugs, ajustements sans changement fonctionnel structurant.
  
 +**Build (W)** : uniquement pendant une phase beta, itération de test au sein d'un même cycle.
  
-==== Allons un peu plus loin ==== +----
-LoGeAs n'est pas un logiciel monolitique en ce sens qu'il s'appuie sur une série de "sous-logiciel" qui constitue la **galaxie LoGeAs**.\\ +
-Si on va plus long la galaxie se compose de  +
-|Serveurs|LogeasWeb|C'est le serveur qui donne accès aux base de nos clients. Il s'agit principalement d'un exécutable windows, écrit en Delphi| +
-|:::|PGI|C'est le serveur qui gère la base de données de nos utilisateurs. Il s'agit aussi d'un exécutable Windows, écrit en Delphi| +
-|:::|Nono|C'est un serveur annexe qui gère une série de base de données anonymisées, a usage technique. Il s'agit d'un exécutable Windows, écrit en Lazarus| +
-|Interfaces|LoGeAs (ou client lourd)|Il s'agit de l'interface "historique" qui est actuellement en cours de portage vers angular. Elle est écrite en Delphi et génère un exécutable windows qui est installé chez le client| +
-|:::|LoGeAs.fr (ou client full-web)|Il s'agit de l'interface utilisateurs, qui remplacera à terme le "client lourd". Elle est écrite en Angular, et est utilisable via un navigateur Internet| +
-|:::|Test.LoGeAs.fr|Il s'agit de l'interface de test final de l'interface précédente| +
-|:::|Assistance|Il s'agit de l'interface utilisé uniquement par l'assistance pour la gestion, les ticketing... Elle est aussi écrite en Angular| +
-|:::|Cartographie fonctionnelle|Il s'agit d'une interface dédié à la gestion de la qualité au service de nos certifications NF. Ecrite en Angular| +
-|:::|Stat-Union|Il s'agit d'une interface dédié à l'ensemble de nos client EPUdF est qui dédié à la consolidation des comptes à vison statistique|+
  
-  * Chaque sous ensemble de la galaxie à **son propre numéro de version** qui évolue en fonction des évolutions, chaque numéros respecte les règles énoncées plus haut +===== La Galaxie LoGeAs =====
-  * Les **digits Majeur et Mineur** sont commun à toutes les interfaces. Si un élément de la galaxie doit changer un de ces digits, la prochaine mise à jour des autres éléments doit le prendre en compte +
-  * Le versionning de chaque élément est géré dans son outil de développement et repris au niveau de GIT.\\ **Git ne travaille qu'avec ces numéros.**+
  
-==== Définition et évolution de la version globale ==== +Le système LoGeAs s'appuie sur plusieurs composants, chacun avec un versioning indépendant, mais suivant tous la même règle de numérotation ci-dessus.
-Dans ce contexte, il est nécessaire de définir une **version "globale"** du logiciel, afin de pouvoir savoir dans le suivi qualité sur quelle version on travail, on test... et surtout qu'elle réalité cela recoupe.\\ +
-=== Règle d'évolution de la version globale === +
-Afin de respecter globalement les règles de gestion des numéros de version, les règles suivantes sont appliqué pour "calculer" le numéro de version globales. +
-|Majeur|Le numéro "majeur" est aligné sur le numéro majeur le plus élevé des sous composants.\\ Si le numéro majeur est incrémenté par rapport à la version précédente alors les autres digit sont remis à zéro| +
-|Mineur|Le numéro "mineur" est aligné sur le numéro mineur le plus élevé des sous composants.\\ Si le numéro mineur est incrémenté par rapport à la version précédente alors les autres sous-digit sont remis à zéro| +
-|Release|Le numéro "release" est incrémenté à chaque fois qu'une modification est faite dans un sous composant| +
-|Build|Non utilisé à ce stade| +
-  * C'est la version globale qui est utilisé dans la partie qualité, assistance...+
  
 +==== Serveurs ====
 +  * **LogeasWeb** — exécutable Windows (Delphi) donnant accès aux bases clients
 +  * **PGI** — serveur gérant la base de données utilisateurs (Delphi)
 +  * **Nono** — serveur annexe gérant les bases anonymisées (Lazarus)
 +
 +==== Interfaces ====
 +  * **LoGeAs (client lourd)** — interface historique, en cours de portage vers Angular (Delphi)
 +  * **LoGeAs.fr (client full-web)** — interface utilisateur remplaçante, **dépôt ''logeas-web''** (Angular)
 +  * **Test.LoGeAs.fr** — interface de test (Angular)
 +  * **Assistance** — interface pour l'équipe support (Angular)
 +  * **Cartographie fonctionnelle** — interface de gestion qualité/certifications NF (Angular)
 +  * **Stat-Union** — interface clients EPUdF pour consolidation comptable
 +
 +==== Principes de gestion ====
 +  * Chaque sous-ensemble possède son propre numéro de version et son propre rythme de publication.
 +  * Les chiffres Majeur et Mineur sont, en pratique, communs à la plupart des composants (alignés historiquement sur la même ligne 11.x), à l'exception notable du serveur PGI qui suit sa propre ligne (9.x).
 +  * Git gère les numéros de version de chaque composant indépendamment ; aucune synchronisation automatique n'est imposée entre dépôts.
 +
 +===== Version Globale =====
 +
 +Une version « globale » synthétise l'état général du logiciel à des fins de qualité et d'assistance :
 +
 +  * **Majeur** : aligné sur le numéro Majeur le plus élevé parmi les sous-composants ; s'il est incrémenté, les autres chiffres reviennent à zéro.
 +  * **Mineur** : aligné sur le numéro Mineur le plus élevé parmi les sous-composants ; s'il est incrémenté, les sous-chiffres reviennent à zéro.
 +  * **Release** : incrémenté à chaque modification d'un sous-composant, quel qu'il soit.
 +  * **Build** : non utilisé actuellement.
 +
 +**Note pratique :** en l'état actuel de la Galaxie, LoGeAs Web est le composant le plus avancé et le plus fréquemment publié — la version globale calculée suit donc, dans les faits, de très près la version de LoGeAs Web, qui sert de repère de référence au quotidien pour l'équipe.
 +
 +
 +
 +===== Processus de mise en ligne d'une version =====
 +
 +{{:certif:procedure:develop:processus_livraison_version.svg?700|Processus de mise en ligne d'une version — commun aux versions Majeure, Mineure et Release}}
 +
 +Le processus est commun aux 3 niveaux de version (Majeure, Mineure, Release) — seules la portée des tests et de la documentation varient selon le niveau :
 +
 +  - **Développement et intégration** : travail sur branche personnelle (poste développeur, pas de nommage imposé), intégrée vers la branche de version (nommée Majeur.Mineur.Release) via ''/fusion-dev'' — voir section « Intégration du code » ci-dessous.
 +  - **Tests** : portée selon le niveau (fonctionnalités impactées pour une Release, campagne complète pour une Majeure/Mineure). Compilation, tests automatiques et style vérifiés automatiquement par ''/fusion-dev'' à l'intégration, puis à nouveau lors de la génération beta/release.
 +  - **Documentation** : évolution et archivage de la documentation technique (et utilisateur si Majeure/Mineure).
 +  - **Tag Git = numéro de version** : l'empreinte (hash SHA) du commit tagué constitue la preuve d'authenticité de la version. Posé automatiquement par ''/release-beta'' ou ''/release-client'' — voir « Gestion des tags Git » ci-dessous.
 +  - **Mise en ligne** : déploiement sur les serveurs applicatifs, mise à jour de l'URL de mise à jour si Majeure. **Reste manuel** pour LoGeAs Web (copie des dossiers ''LogeasWeb''/''LogeasWeb-Test'' vers le serveur, accessible uniquement en bureau à distance).
 +  - **Communication** : publication du changelog (à partir de l'historique Git) et envoi d'un mail aux utilisateurs concernés. **Non outillé actuellement** côté LoGeAs Web.
 +
 +Une fois publiée, une version n'est jamais modifiée : toute évolution repart sur une nouvelle branche / un nouveau numéro de version.
 +
 +----
 +
 +===== Intégration du code (dépôt Git) =====
 +
 +Cette section fusionne l'ancienne procédure « gestion du dépôt Git » (novembre 2025). Sa version originale décrivait un flux par ticket GitLab et relecture systématique par un second développeur — ce flux n'a jamais correspondu à la pratique réelle et n'est plus d'actualité (confirmé en 2026-08, suite au départ de Kevin Kopinski) : pas de ticket, pas de merge request, travail réalisé directement sur le poste du développeur.
 +
 +  - **Travail sur branche personnelle** : chacun développe sur sa propre branche, créée depuis la branche de version en cours (ex. ''11.0.25''). Pas de ticket GitLab ni de merge request requis.
 +  - **Sauvegarde régulière** : commit et push de la branche personnelle au fil de l'eau, sans vérification imposée à ce stade (procédure manuelle).
 +  - **Intégration = validation** : la validation d'une fonction se fait au moment de son intégration dans la branche de version courante, via la procédure outillée ''/fusion-dev'' (assistant Claude Code, dépôt logeas-web), qui :
 +    * met à jour la branche de version depuis le dépôt distant
 +    * fusionne la branche personnelle avec un commit de fusion portant le log complet des commits intégrés
 +    * vérifie compilation, tests automatiques et style après fusion — c'est ce contrôle technique qui fait office de validation, il n'y a pas de relecture séparée par un second développeur
 +    * publie le résultat vers le dépôt distant
 +
 +Une version rassemble l'ensemble des changements intégrés sur la branche de version depuis la dernière publication.
 +
 +----
 +
 +===== Gestion des tags Git =====
 +
 +==== Format des tags ====
 +
 +  * Beta : ''X.Y.Z.W_beta'' (ex. ''11.0.26.1_beta'')
 +  * Release : ''X.Y.Z_release'' (ex. ''11.0.26_release'')
 +
 +Ce format s'applique au dépôt LoGeAs Web (''logeas-web''). Les dépôts du client lourd et des serveurs (groupe Delphi) utilisent une convention de tag distincte, héritée de leur propre historique (ex. ''NonoVersion11.0.1.0'', ''LoGeAsVersion11.0.2.3Pré-release'') — non harmonisée avec le format ci-dessus pour l'instant.
 +
 +Dans tous les cas, l'empreinte (hash SHA) du commit tagué constitue la preuve d'authenticité de la version, et peut être communiquée directement aux organismes certificateurs sans dépôt auprès de tiers.
 +
 +==== Étapes d'exécution — LoGeAs Web ====
 +
 +Outillées via les commandes ''/release-beta'' et ''/release-client'' (assistant Claude Code, dépôt logeas-web) :
 +
 +  - **Vérification de branche** : la branche de version est propre et à jour avec le dépôt distant
 +  - **Génération du build** : compilation, incrémentation automatique du numéro (4ᵉ chiffre pour une beta, 3ᵉ chiffre pour une release)
 +  - **Commit dédié** : le changement de numéro de version est commité séparément du contenu fonctionnel
 +  - **Étiquetage** : tag Git annoté créé sur ce commit
 +  - **Publication** : push du commit et du tag vers le dépôt distant
 +  - **Relevé d'empreinte** : le hash de commit court est embarqué automatiquement dans ''src/assets/version.ts'', consultable directement dans le logiciel livré
 +  - **Archivage** : conservation de la référence du tag dans le suivi de version (cartographie fonctionnelle)
 +
 +==== Cas d'un tag posé manuellement ====
 +
 +Respecter impérativement le format défini ci-dessus et ne jamais réutiliser un numéro X.Y.Z déjà présent dans un tag ''_release'' existant.
 +
 +----
 +
 +===== Dépôt légal des codes sources (coffre-fort numérique) =====
 +
 +Cette section fusionne l'ancienne procédure #09 « Dépôt des Codes Sources ». Le dépôt légal intervient **après** la pose du tag ''_release'' (donc après exécution de ''/release-client''), à chaque publication d'une version.
 +
 +Les codes sont historisés via GitLab, répartis en plusieurs groupes :
 +  * **Logeas Informatique / Divers** : AutoVideo, Composants, SFTPLogeasSync
 +  * **Logeas Informatique / Logeas-projets-obsoletes** : BibliothequeAngular, logeas-lib, maj-serveurapp, NewInterfaces
 +  * **Logeas Informatique / Logeas-web** : Logeas-projet-IA, logeas-web.fr, Site internet
 +  * **NewInterfaces-group** : exemples, logeas-assistance, logeas-cartographie, logeas-lib, logeas-statunion, logeas-taches, logeas-web, questionnaire, script
 +
 +**Historique :** avant 2024, le dépôt légal se faisait sur e-coffrefort.fr (fermé à l'automne 2024). Depuis, les dépôts se font directement sur GitLab.
 +
 +----
  
-===== Changement de version et actions à faire ===== 
-Le processus de mise en ligne est commun aux trois niveaux de version (Majeure, Mineure, Release) ; seule la portée des tests et de la documentation varie selon le niveau, ainsi que deux étapes spécifiques (voir schéma). 
-{{ :certif:processus_livraison_version.svg }} 
-NB : SVG stocké sur le wiki éditable par exemple avec Inkscape 
-==== Dépot ==== 
-Le dépôt des sources est réalisé de façon systématique sur **chaque version** publiée, directement via **GitLab**.  
-Lors de la mise en ligne, un tag Git correspondant au numéro de version (Majeur.Mineur.Release.Build) est créé sur la branche concernée.  
-L'empreinte cryptographique (hash SHA) de ce commit tagué fige de façon incontestable l'état exact des sources, des paramétrages et des modèles associés à cette version.  
-Cette empreinte, conservée dans l'historique Git, constitue la preuve d'authenticité de la version auditée et peut être communiquée à l'organisme certificateur pour vérification, sans dépôt auprès d'un tiers.