Guide pratique — Gestion des versions LoGeAs Web

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.

Il s'adresse principalement aux développeurs et aux personnes chargées de préparer les publications.

Il complète les documents suivants :

• Procédure de gestion des versions : règles générales de versionnage.
• Chaîne de qualification et de livraison : responsabilités, contrôles et validations.
• Cycle de release LoGeAs Web : fonctionnement technique des procédures automatisées.

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.

Les opérations de release sont réalisées depuis le poste de développement, avec :

• Git et l'accès aux dépôts distants ;
• Node.js et npm ;
• Angular CLI ;
• Claude Code, pour les commandes automatisées du cycle ;
• les accès aux dépôts logeas-web, logeas-lib et, pour le rapport qualité, logeas-cartographie.

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 Claude Code doivent être lancées depuis la racine du dépôt concerné.

Une release directe, sans beta préalable, est possible lorsqu'elle est justifiée et que les contrôles applicables sont réalisés.

Dans le dépôt logeas-web, créer une branche personnelle à partir de la branche de version en cours.

Exemple :

git checkout 11.0.25
git pull
git checkout -b feature/nom-fonctionnalite

Le nom de la branche doit permettre d'identifier le travail effectué.

Le développeur réalise ses modifications et les sauvegarde régulièrement.

Exemple :

git status
git add src/app/mon-composant
git commit -m "Ajout de la fonctionnalité"
git push -u origin feature/nom-fonctionnalite

Avant chaque commit, vérifier les fichiers sélectionnés.

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.

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.

Lorsque le travail est suffisamment avancé et prêt à être intégré :

• vérifier les modifications ;
• sauvegarder les derniers commits ;
• s'assurer que la branche personnelle est disponible sur le dépôt distant ;
• demander ou 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.

L'intégration est réalisée avec la commande :

/fusion-dev

La commande doit être lancée dans logeas-web.

Elle identifie la branche de version commune et réalise la fusion de la branche personnelle.

Avant de poursuivre, vérifier que :

• 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.

La procédure réalise les contrôles techniques après la fusion :

• compilation ;
• tests unitaires ;
• lint.

Le développeur doit vérifier le résultat global et notamment les éventuels avertissements ou échecs.

En cas de conflit concernant le fonctionnement métier, ne pas accepter une résolution automatique sans vérification.

En cas d'échec bloquant, la branche commune ne doit pas être publiée tant que le problème n'est pas traité.

L'intégration est terminée lorsque :

• la fusion est effectuée ;
• 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 ;
• 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.

La publication beta est décidée lorsque la branche de version est considérée comme suffisamment stable pour être testée.

Avant de lancer la procédure, vérifier :

• que les développements à intégrer sont bien présents ;
• 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.

Dans logeas-web, sur la branche de version, lancer :

/release-beta

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 :

D:\Developpements\VersionPublic\LogeasWeb-Test\browser\

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.

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.

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.

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.

Dans logeas-web, sur la branche de version, lancer :

/release-client

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 :

D:\Developpements\VersionPublic\LogeasWeb\browser\

Le numéro de release utilise le format X.Y.Z_release pour le tag.

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.

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.

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.

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 :

git checkout 11.0.25
git pull
git checkout -b 11.1.0
git push -u origin 11.1.0

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.

Le calcul automatique de la version tient compte du numéro de la nouvelle branche lors de la prochaine génération beta.

Les règles détaillées de numérotation sont décrites dans la procédure technique du cycle de release.

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 :

Les corrections apportées à la version de production ne sont pas automatiquement reportées sur la version suivante.

Il faut donc vérifier que les correctifs nécessaires sont également intégrés à la branche d'évolution.

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 :

scripts/switch-lib-version.ps1

Les profils sont définis dans :

scripts/switch-lib-profiles.json

Exemples de commandes :

.\scripts\switch-lib-version.ps1 -Profile hotfix

.\scripts\switch-lib-version.ps1 -Profile next

Les profils déterminent les branches à utiliser pour logeas-web et logeas-lib.

Avant d'utiliser cet outil, vérifier que les dépôts concernés 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.

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.

Ces commandes sont exécutées dans Claude Code, depuis le dépôt approprié.

Les commandes Angular suivantes permettent de générer un build sans réaliser l'ensemble du processus de publication :

ng build --configuration "production,beta"

ng build --configuration production

Ces commandes ne remplacent pas les procédures de release.

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.

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 pas contourner les contrôles bloquants ;
• 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.

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.

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.

Pour chaque version publiée, les éléments suivants doivent pouvoir être retrouvés :

• la branche de version concernée ;
• 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.

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.