Chaîne de qualification et de livraison

Cette page explique comment une version de LoGeAs Web passe du code fusionné à la livraison client : qualification par les tests, validation, beta, recette, release. Elle s'adresse à toute l'équipe : développeurs, et personne qui valide et recette.

Voir aussi : Lancer les tests E2E (détail du run complet) et la méthodologie des tests (logeas-cartographie/src/assets/methodologie-tests.html, section 8).

Avant, les tests et la livraison formaient deux circuits séparés :

• une beta pouvait partir sans rapport qualité validé ;
• entre deux betas, un run de tests était rangé sous la version de la dernière beta livrée, alors

qu'il testait la prochaine ;

• les tests unitaires étaient joués deux fois (run complet, puis rapport de release), sans garantie

que ce soit sur le même code.

Désormais, aucune version n'est livrée sans un rapport qualité validé qui porte sur son code exact, et deux portes bloquantes le vérifient automatiquement.

La même personne peut valider et recetter (équipe trop petite pour les « quatre yeux »).

But : produire le rapport qualité de la prochaine version, sur un code identifié sans ambiguïté.

Avant de lancer, pour logeas-web ET logeas-lib :

• être sur la branche de version (ex. 11.2.0) ;
• aucune modification locale non commitée ;
• branche à jour avec origin et poussée ;
• Angular arrêté (fermer sa fenêtre console) : sinon il continuerait de servir l'ancienne

bibliothèque après sa réinstallation. Le script vérifie tout cela lui-même et s'arrête en disant quoi corriger. Pour vérifier sans rien lancer : powershell -ExecutionPolicy Bypass -File scripts\qualifier-version.ps1 -VerifierSeulement (ou la commande Claude /qualifier-version).

Lancer : double-clic sur scripts\qualifier-version.bat. Le script :

1. affiche la version candidate : la prochaine beta (ex. 11.2.0.9), sous laquelle le rapport

sera rangé ;

1. reconstruit logeas-lib depuis son dernier commit et la réinstalle dans logeas-web

(quelques minutes) ;

1. demande la confirmation UAC du démarrage des serveurs : rester devant le poste jusque-là ;
2. enchaîne sans surveillance : tests unitaires des deux dépôts, tests d'interface, rapport qualité,

analyse par Claude, dépôt du rapport en brouillon sur le serveur Nono.

Pendant le run : ne rien commiter, ne rien pousser, ni dans logeas-web ni dans logeas-lib. Le rapport le détecterait (« code modifié pendant le run ») et la porte le refuserait.

Résultat : un rapport run-<version>-<AAAAMMJJ-HHMM>.html d'origine « Qualification », visible dans l'écran Rapports de version de la carto. Si on relance une qualification pour la même version, un nouveau rapport est créé ; les précédents restent consultables, marqués « Remplacé ».

Dans la carto, écran Rapports de version, connecté : relire le rapport (en particulier l'analyse rédigée par Claude), puis choisir une décision.

« Validé » et « Validé avec réserves » publient le rapport en même temps : il devient visible sans connexion et constitue la pièce qualité (dossier NF Logiciel) de la version.

Double-clic sur scripts\livrer-beta.bat. Le script :

1. passe la porte beta (voir plus bas) : s'il manque quelque chose, il s'arrête et l'explique ;
2. fait le bump de version (4ᵉ chiffre) et vérifie que c'est bien la version qualifiée ;
3. génère le rapport de release : les tests unitaires y sont repris de la qualification (plus

rejoués), avec un renvoi vers le rapport qualité ;

1. lance le build de production vers D:\Developpements\VersionPublic\LogeasWeb-Test\ ;
2. crée le commit « Preparation version X.Y.Z.W », le tag X.Y.Z.W_beta et, si besoin, le tag

web-X.Y.Z.W_beta dans logeas-lib ;

1. demande confirmation avant de pousser. Si on accepte : push, inscription de la beta dans la

trace du rapport qualité (indispensable pour la suite), reprise du rapport de release dans la carto. Si le rapport de release ou le build échoue, le bump est annulé : rien n'est commité ni tagué.

Reste à copier LogeasWeb-Test\browser\ sur le serveur de test (bureau à distance).

Une fois la beta déployée, dans la carto, écran Rapports de version, sur le rapport qualité de la version : la section Recette de la beta propose une liste de contrôle minimale.

• la version affichée dans « À propos » est celle de la beta livrée ;
• connexion et ouverture d'une base ;
• annuaire : recherche et ouverture d'une fiche ;
• comptabilité : saisie et enregistrement d'une écriture ;
• états : génération d'un état PDF ;
• sauvegarde / export d'une base ;
• chaque correctif et évolution annoncé dans le rapport de release a été vérifié.

Chaque point est Vérifié, ou Sans objet avec une justification. Le bouton Recette conforme n'est actif que si tous les points sont traités. Recette non conforme exige un commentaire.

Seule une recette conforme ouvre la release client. Une recette non conforme impose une correction, donc une nouvelle qualification et une nouvelle beta.

Double-clic sur scripts\livrer-release.bat. Même déroulé que la beta, derrière la porte release : bump en version à 3 chiffres, build vers D:\Developpements\VersionPublic\LogeasWeb\, commit, tag X.Y.Z_release, confirmation, push, inscription de la release dans la trace du rapport. Reste à copier LogeasWeb\browser\ sur le serveur client.

Le rapport qualité, déjà publié lors de sa validation, est la pièce qualité de la release.

Les portes lisent le manifeste des rapports et leurs décisions sur le serveur Nono de production, et comparent au code présent sur le poste. Elles sont bloquantes. Pour les vérifier sans rien modifier : powershell -ExecutionPolicy Bypass -File scripts\livrer-version.ps1 -Nature beta -VerifierSeulement (ou -Nature release).

Porte beta :

• les deux dépôts sont sur leur branche de version, propres, à jour et poussés ;
• un rapport d'origine « Qualification » de la version candidate porte exactement le dernier

commit des deux dépôts (le plus récent, s'il y en a plusieurs) ;

• ce run n'a eu ni modification locale, ni changement de code en cours de route, et les paquets

logeas-lib installés sont toujours ceux du run ;

• sa décision est « Validé » ou « Validé avec réserves ».

Porte release :

• package.json porte une beta, et le tag de cette beta est le dernier commit de logeas-web

(aucun commit depuis la beta) ;

• logeas-lib est toujours au commit qualifié, avec les mêmes paquets installés ;
• entre le code qualifié et la beta, seul le commit « Preparation version » (dans package.json,

seul le numéro de version a pu changer) ;

• le rapport qualité est toujours validé, et la recette de cette beta est « Conforme ».

Messages fréquents :

Règle stricte : tout commit après une beta, même un correctif d'une ligne, impose une nouvelle qualification et une nouvelle beta (X.Y.Z.W+1). Une qualification tourne sans surveillance (environ 15 minutes après la confirmation UAC) : le coût est faible, et une exception affaiblirait toute la chaîne.

Un build hors chaîne reste possible (npm run build). Son rapport de release affiche alors « Version non qualifiée » (tests unitaires rejoués au moment du build, aucun test d'interface vérifié), et l'écran À propos > Logiciel de LoGeAs Web affiche « Version non qualifiée ». À réserver aux urgences, et à régulariser par une qualification dès que possible.

Les commandes Claude /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 ces scripts.