Process de livraison

Bonjour

je ne maitrise pas Maven mais une question me tourne dans la tête depuis que je regarde son fonctionnement.

de tout ce que j'ai vu (pas grand chose) Maven gère le cycle de vie du projet à partir du pon.xml de celui-ci
Dev, build, test, install, .. deploy

du coup je ne comprends pas comment on garanti que l'exécutable qu'on a produit au build et qu'on a testé est bien celui qui par en prod.

je me dit que si je descends dans un workspace mon projet qui a déjà passé les phase de tests et d'intégrations je peux alors que je n'ai pas sur ma machine les binaires testé faire un deploy du coup maven fait un build et toutes les étapes necessaire jusqu'au déploy c'est dinc un nouveau binaire qui est déployé et non celui qui a été testé.

dans mon processus le développeur développe et passe les test unitaire. il livre alors un exécutable à l'équipe d'intégration.
cette équipe qualifie l'exécutable et le passe à l'équipe de recette.
qui fait une recette fonctionnelle.
l'exécutable passe alors en preprod
pour finir en prod.

à aucun moment les équipes n'ont accès au source du projet.
à une étape donné l'utilisateur ne peut prendre que ce qui a été mis à sa disposition faire son travail et le passer au suivant.

je me demande comment on peut gérer ce cycle avec maven.
comment organiser un tel processus

j'ai imaginé que le projet de dev déploy vers l'intégration en déposant dans un "repository" dédier à cela.
l'équipe d'intégration à alors un autre projet (d'intégration) qui prends dans ce reprository fait les tests et déploy vers le repositiory de la recette
et ainsi de suite.

mais je ne sais pas si c'est la bonne approche.
j'aimerais votre avis avant de tenter de mettre en place quelque chose.

merci à vous
A+JYT

en fait, en complement de maven, il y a une notion de repository : un endroit ou tu stockes tes binaires versionnés (comme maven central)

quand tu utilises une release maven (mvn release:clean release:prepare release:perform ) : tu passes ton snaphot (par exemple 1.0-SNAPSHOT) en 1.1-SNAPSHOT) et en même temps : tu publies sur ce repository ton jar/war/ear en version 1.0
cette version n'est plus modifiable (sans faire de manipulation qu'on ne devrait presque jamais faire)

quand tu deploies en prod : tu le fais a partir de ce répository : donc version stable et non modifiable

(en parallele : le plugin release peut te faire un commit de tag sur svn)

Ok
merci
je vais fouiller plus avant
pour mettre en place mon process

Code:

---

1 2 3 4 5 6 7 8

Dev -> Qualif +-> Recette | + -> Preprod +-> Prod | +-> Audit | +-> Formation

---

A+JYT

Je crois que j'ai beaucoup de question à résoudre

pour faire ce que je veux dans l'esprit de Maven
je fais un POM pour mon projet de dev associé à SVN et Mantis

il me faut un repository pour ma boite pour livrer les versions

ce repository peut-il être un simple dossier sous unix accessible par scp/ssh ?
Que dois-je mettre dans ce dossier au départ ?

Ensuite je ne vois pas comment faire pour que d'autres utilisateur qui ne sont pas développeurs et n'ont pas accès au svn puissient récupérer le pom donc j'imagine qu'il me faut faire un autre pom pour gérer le livraisons successives sur les différentes plate-forme.

Que dois-je mettre dans ce pom pour qu'il ne gère que les phase de déploiement ?

j'espérais pouvoir faire des chose comme
équipe de développement :
compile test install
équipe de déploiement
install-qualif -Version=1.1
install-preprod -Version=1.1
install-prod -Version=1.0
install-formation -Version=1.0
install-audit -Version=1.0

j'ai comme l'impression que ce n'est pas un processus standard pour maven pourtant il est très courant en entreprise

A+JYT

alors pour le répo : même si en général on utilise un logiciel pour le faire (nexus, archiva etc...), il me semble qu'on peut utiliser n'importe quel repertoire accessible (voir http://maven.apache.org/guides/intro...ositories.html section Internal Repositories

pour le pom : pas bien compris la question.
il est mis a disposition sur le répo (de la meme maniere que le war/jar/ear)
http://search.maven.org/#search%7Cga....code.guice%22 par exemple


enfin : tu ne peux avoir q'un artefact par pom. donc pas possible d'envisager un pom qui donne un jar de preprod, un jar de prod etc...
pour cela : soit tu geres les differences dans de la conf, soit tu fais des poms differents (des modules peut etre), et dans ce cas, tu pourra deployer un appli-preprod.jar et un appli-prod.jar en version 1.0 (mais tu noteras que c'est rarement le choix fait dans les differents repos publiques)

Pour le repository merci. Je continue de lire

pour la livraison elle-même
Je dois absolument garantir que c'est le même jar (et non un jar reconstruit à l'identique) qui pas par les phases
qualif, recette, preprod, prod

mais il arrive que deux versions successives soient déployées sur des environnements différents en même temps

par exemple mes plateformes on le jar toto en version 1.0
Un correctif arrive la version 1.0.1 passe en qualif puis en recette puis en preprod.
à ce moment-là une evol arrive à son tour et doit passer en qualif
j'ai donc la version 1.0.1 qui doit passer de preprod à prod pendant que la version
1.1.0 elle passe de dev à qualif

C’est sur ce genre de comportement que je n'arrive pas à comprendre comment marche Maven. Je n'arrive pas à déterminer s'il peut ou ne peut pas le faire ni comment il peut le faire.

Ensuite se greffe un problème de droit.
Si je fais un pom lors de ma phase de dev qui contient tout le cycle comment cloisonner les étapes ?

une équipe fait
conception, réalisation, tests unitaires, intégration (logicielle), test d'intégration.

une autre fait
spécification (puis passe la main au dev), qualification (jusque-là le soft est isolé du SI)

encore une autre fait
intégration (Systeme d'Information), recette fonctionnelle

encore une autre fait
tests de charge, stress, reprise, test des procédures, de la chaîne de soutient, de la supervision (preprod)

et enfin une dernière
exploitation

Dans cette organisation l'équipe de dev livre à l'équipe de qualif mais n'a pas le droit ni la connaissance des autres plates-formes. (ils connaissent leurs existences, mais pas le détail)

l'équipe de qualif déploie sur la plateforme de qualif et lorsque c'est OK livre à l'équipe de préprod
Elle n'a pas accès aux autres plateformes.

L’équipe de preprod s'occupe de tous les autres déploiements. elle déploie en premier en intégration SI et en preprod
pendant que l'équipe d'intégration teste elle vérifie les procédures la chaine de soutient, etc.
Lorsque l'intégration est OK, l'équipe de préprod déploie en recette et pendant la recette passe la version aux tests de charge et de stress sur la plateforme de preprod.

Lorsque le GO est donné pour la version. Elle est livrée à la prod qui la déploie en formation, prod et audit.

Du coup je ne vois pas comment un seul et unique pom permet de cloisonner ces étapes.
Il y a au moins 4 groupes d'acteurs qui ont des prérogatives très différentes.

J’espérais pouvoir inclure dans tout ça l'automatisation d'une grande partie des tests. C’est évident pour les tests unitaires, relativement simples pour l'intégration logicielle.
à la rigueur, les tests de qualifications peuvent être inclus dans le même pom même si l'équipe de dev n'aura pas les moyens de les faire passer
Mais les tests de charges, de stress, etc., certain test intégrations SI ...

Bref j'ai du mal à envisager un seul pom pour tout le cycle.

Je me trompe peut être, mais plus je lis, moins je suis pense que Maven est l'outil dont j'ai besoin.

A+JYT

alors : maven, par defaut n'est qu'un outils de build.

il te permet de builder et de releaser des versions dans un repo
tu peux donc releaser une version 1.0
bosser sur une 1.1-SNAPSHOT
checkouter la version 1.0 et patcher et rereleaser en 1.0.1

Tu es donc garanti, quand tu vas prendre le jar 1.0 : de toujours avoir le même.


Ensuite : pour gerer des campagnes de tests. maven par défaut est limité. que des tests unitaires.

par contre, tu as des plugins qui peuvent éventuellement aider a adapter :
maven-surefire etc...

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.

Code:

---

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

Code:

---

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