Discussion :

[sekaijin]

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

[lunatix]

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)

[sekaijin]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Dev -> Qualif +-> Recette
                    |
                    + -> Preprod +-> Prod
                                        |
                                        +-> Audit
                                        |
                                        +-> Formation

A+JYT

[sekaijin]

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

[lunatix]

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)

[sekaijin]

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