Bonjour.
Je reviens sur cette discussion, car nous avons mis en place quelque chose qui fonctionne.
En premier lieu nous avons défini un repository par phase.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| phase de dev pour les développeurs et les tests
snapshot
release
phase de qualif vérif de la conformité aux spec
qualif test de charge des composants
--------------------------------------------------------------------------------
phase intégration test en environnement technique cible
integration vérifie que les éléments vont fonctionner dans leur environnement
phase de recette test fonctionnel en environnement cible
recette
phase de preprod préparation à la mise en prod
preprod test de charge de la plateforme complète.
phase de prod production et formation.
prod |
Tout cela peut paraître beaucoup, mais ce que nous livrons sont des modules qui, individuellement, ne font que très peux de choses, mais interagissent beaucoup avec une très grande variété d'applications dans le SI. Il est donc très important avant de mobiliser des équipes de recette d'une 15ene d'application de vérifier que les modules livrés communiquent bien entre eux et avec lesdites applications. d'où la phase d'intégration technique. Mais celle-ci mobilise elle aussi des partenaires. Une équipe est donc chargée de qualifier le composant avant d'entrer dans le processus de livraison. En gros, les équipes de dev après avoir fait leur boulot et testé comme tout développeur (ou fournisseur externe) donnent le bébé à l'équipe de qualif qui vérifie que le composant est conforme aux spécifications. Un peut comme une release candidate. Sinon il refuse la release.
Pourquoi ne par tester en snapshot pour cette phase. la raison est le manque de confiance envers certains partenaires (de grands noms de l'informatique se sont montré par le passé très peu fiable, voire de vrais filous qui grugaient les procédures de qualité)
Nous n'avons donc plus de recompilation (snapshot -> release). Nous ne manipulons que des versions release. Les jar , zip, exe passent d'une phase à l'autre sans possibilité de modification. on est donc sur ainsi qu'un composant testé est bien celui qui va en prod et non une "reconstruction hasardeuse"
Retour à Maven. La première phase fut donc de créer un repo par phase.
Chaque repos est sécurisé et les manipulations sont restreintes.
Chaque environnement (un ou plusieurs par phase) possède une configuration mvn qui ne lui permet de lire ou d'écrire que dans les repos qui le concerne.
Par exemple la recette ne peut lire que le repo recette et écrire dans le repo preprod.
Chaque profil maven possède une commande livrer. Qui fonctionne ainsi
livrer -g group -a artifact -v version [-c qualifier] [-t type]
cette commande copie le composant du repo nexus correspondant au profil dans le repos de la phase suivante.
Ainsi chaque acteur dans chaque phase peut transmettre le composant à la phase suivante quand sa propre phase est validée.
Chaque plateforme ne voit que les composants mis à dispo par la phase précédente.
À moins de hacker le système et de modifier les droits d'un profil, les utilisateurs ne peuvent récupérer des composants qui ne sont pas disponibles pour leur phase. Les composants installés ont tous obligatoirement passé toutes les phases précédentes. Et le composant installé sur une plateforme est bien celui qui a passé la qualif.
Pour les produits java nos plateformes embarquent directement un deploy manager qui gère maven et vont donc chercher sur nexus les jar nécessaires. Les opérateurs n'ont jamais les jars en main.
Même s'ils les téléchargent, ils ne peuvent déployer le jar qu'ils ont sur leur poste. La plateforme prend celui qui est sur nexus.
Tout cela n'est pas parfait, mais fonctionne.
Nous avons depuis mon dernier post quelques centaines de composants dans de nombreuses versions dans le tuyau.
À tout moment nous pouvons via nexus savoir quelles versions sont disponibles dans chaque phase.
Je réfléchis maintenant à coupler ça avec l'outil de suivi. Une fiche de livraison est créée dans l'outil dès qu'on passe de qualif à intégration. À chaque validation ou invalidation d'une phase, la fiche est mise à jour, voire close.
A+JYT
Process de livraison
Répondre avec citation
Partager