Discussion :

[vinzzzz]

Hello,

Je souhaiterai mettre en place un framework permettant de gérer quelques projets JAVA de la manière la plus simple et clean possible. Rapidement, il y a pour l'instant 3 développeurs (1 très actif, 2 occasionels), et 4 projets JAVA, dont 1 central dont dépendent les 3 autres. Chaque projet a certaines dépendances externes spécifiques, et ils ont également tous des dépendances partagées. La plupart d'entre eux génèrent des .jar que l'on souhaite ensuite déployer en environnement de test dans une application tierce.

Après quelques recherches, j'ai trouvé bon nombre d'outils permettant de gérer les divers aspects liés au développement et au déploiement de projets. J'ai notamment retenu les suivants:
- NetBeans (ou Eclipse) pour le développement
- Subversion pour le versionning
- Track pour les tickets, bugs, timelines etc..
- Maven pour mettre en place une organisation propre et (apparemment) simplifier le cycle de développement
- Hudson pour des builds automatiques, mais pas certain qu'on en ait vraiment besoin.

Je voulais connaitre vos avis et expériences sur ces différents outils (ou leurs équivalents) et leur combinaison. A première vue, il me semble que ca fait beaucoup d'outils, dont certains ne semblent pas forcément facile à prendre en main, e.g. Maven, et je voulais savoir si ca vaut vraiment le coup d'investir du temps pour les mettre en place.

Merci d'avance

[Robin56]

Je voulais connaitre vos avis et expériences sur ces différents outils (ou leurs équivalents) et leur combinaison. A première vue, il me semble que ca fait beaucoup d'outils, dont certains ne semblent pas forcément facile à prendre en main, e.g. Maven, et je voulais savoir si ca vaut vraiment le coup d'investir du temps pour les mettre en place.

Eh bien je dirais que tu viens de citer le minimum des outils utilisés au sein de tout les projets Java pro.

- NetBeans (ou Eclipse) pour le développement

Un IDE c'est le minimum syndical en Java. Avantage à Eclipse pour moi mais je n'ai jamais vraiment manipulé NetBeans.

- Subversion pour le versionning

Obligatoire pour du travail à plusieurs (plugin Subclipse d'Eclipse ou TortoiseSVN)

- Track pour les tickets, bugs, timelines etc..

Eh bien tu n'as pas précisé dans quel cadre tu as besoin de ça ? Si c'est en entreprise, tu en auras besoin pour gérer et tracer correctement les soucis, remontés de bugs, évolutions, ...

- Maven pour mettre en place une organisation propre et (apparemment) simplifier le cycle de développement

Facilite la gestion des dépendances externes, il peut paraître complexe au premier abord mais permet de gérer plus facilement l'ajout de jar.

- Hudson pour des builds automatiques, mais pas certain qu'on en ait vraiment besoin.

Si l'on veut assurer un processus de compilation automatisé et donc assurer son cycle de développement/test, c'est un outil bien intéressant.

Après comme je l'ai dis tout à l'heure, on ne sait pas dans quel cadre tu veux ces outils (perso ? pro ?). On ne sait pas le niveau de compétence des pratiquants sur ces outils ? Si tu pars de 0, il est évident qu'il ne faut pas intégrer tout ces outils d'un coup sous peine de se noyer et de ne jamais avoir quelque chose de stable : Eclipse/SVN étant le minimum.

[LittleBean]

Eh bien je dirais que tu viens de citer le minimum des outils utilisés au sein de tout les projets Java pro.

Tout à fait

Facilite la gestion des dépendances externes, il peut paraître complexe au premier abord mais permet de gérer plus facilement l'ajout de jar.

Maven est assez compliqué, si tu as un tout petit projet ant peut suffire.

Hudson pour des builds automatiques, mais pas certain qu'on en ait vraiment besoin.

Tu peux regarder aussi jenkins issu d'un fork (du "papa") de hudson. (A ma connaissance hudson est en incubation à la fondation eclipse... avenir incertain)

=> hudson prend tout son sens si tu le couple avec des tests automatiques
(ça permet d'avoir un indicateur crédible de l'avancement du projet)
Pour des projets simples junit peut suffire

Subversion pour le versionning

Si j'avais le choix j'opterais pour git, il est vrai que dans la plus part des organistations sont encore au svn . (J'ai pas encore pu tester git sur un vrai projet)

On ne sait pas le niveau de compétence des pratiquants sur ces outils ?

+1
Consulte les sur les outils qu'ils souhaitent, ils doivent bien avoir une idée de ce dont ils ont besoin. Ce sera d'autant plus facile de leur imposer ces outils ensuite.

Si tu pars de 0, il est évident qu'il ne faut pas intégrer tout ces outils d'un coup sous peine de se noyer et de ne jamais avoir quelque chose de stable : Eclipse/SVN étant le minimum

+1000

[vinzzzz]

Si j'avais le choix j'opterais pour git, il est vrai que dans la plus part des organistations sont encore au svn . (J'ai pas encore pu tester git sur un vrai projet)

J'ai regardé un peu GIT et Subversion, et pour le moment je n'ai pas parfaitement compris le réel avantage de l'architecture distribuée de GIT par rapport à celle centralisée de Subversion. Ce que j'en ai retenu c'est que pour un petit nombre de développeurs, Subversion convient très bien.

Consulte les sur les outils qu'ils souhaitent, ils doivent bien avoir une idée de ce dont ils ont besoin. Ce sera d'autant plus facile de leur imposer ces outils ensuite.

"Ils" c'est moi je suis en environnement pro.

Après comme je l'ai dis tout à l'heure, on ne sait pas dans quel cadre tu veux ces outils (perso ? pro ?). On ne sait pas le niveau de compétence des pratiquants sur ces outils ? Si tu pars de 0, il est évident qu'il ne faut pas intégrer tout ces outils d'un coup sous peine de se noyer et de ne jamais avoir quelque chose de stable : Eclipse/SVN étant le minimum.

Actuellement le framework se limite à Eclipse / Subversion / Trac et des builds.xml pour 4 projets de taille modéré.

J'explore toutes les options pour déterminer si une réorganisation est nécessaire, le but étant de repartir sur des bases saines, et obtenir un bon compromis entre évolutivité et temps nécessaire pour mettre en place la nouvelle architecture. Le but ultime bien sur c'est d'essayer de simplifier le cycle de développement (construction des jar, mise en place de ceux ci dans l'environnement de tests pour chaque développeur, ajouts de dépendances, création de JAR pour la production avec obfuscation etc..).

La grande question surtout, c'est Maven VS ant sachant qu'il y a 4 projets, que potentiellement d'autres viendront, que certains projets dépendent d'autres et qu'il y a pas mal de dépendances externes.

Exemple: Maven permet d'ajouter plus facilement des JAR.. J'immagine qu'il y a d'autres avantages par rapport à la situation décrite ?

[Robin56]

@LittleBean : Que reproches tu à SVN ?

Actuellement le framework se limite à Eclipse / Subversion / Trac et des builds.xml pour 4 projets de taille modéré.

Pourquoi parles tu de "framework" ? Ce n'est pas un terme à utiliser à toutes les sauces. Ce dont tu parles là c'est un environnement de développement, pas un framework.

J'explore toutes les options pour déterminer si une réorganisation est nécessaire, le but étant de repartir sur des bases saines, et obtenir un bon compromis entre évolutivité et temps nécessaire pour mettre en place la nouvelle architecture.

Quels sont concrètement les soucis actuels ? Avant d'incorporer un nouvel outil dans un projet, il est important de bien cerner les soucis et les buts recherchés.

La grande question surtout, c'est Maven VS ant sachant qu'il y a 4 projets, que potentiellement d'autres viendront, que certains projets dépendent d'autres et qu'il y a pas mal de dépendances externes.

Maven VS Ant ? Oulah c'est un gros débat, trop pointu pour moi. J'ai plus souvent utilisé Maven, je ne pourrais donc t'éclairer davantage. Moi ce que je peux en dire du peu que je connaisse c'est que la gestion des dépendances est centralisée au sein d'un "repository". Ceci à l'avantage de pouvoir centraliser les références pour utiliser avec plusieurs projets. Pour le reste, je laisse les connaisseurs s'exprimer.

[vinzzzz]

Pourquoi parles tu de "framework" ? Ce n'est pas un terme à utiliser à toutes les sauces. Ce dont tu parles là c'est un environnement de développement, pas un framework.

environnement de développement ~ cadre de développement, cadre ~ framework. Un racourcis / anglicisme facile certes, mais il me semble avoir été compris ce qui est le principal après tout

Quels sont concrètement les soucis actuels ? Avant d'incorporer un n
ouvel outil dans un projet, il est important de bien cerner les soucis et les buts recherchés.

Les soucis, il n'y en a pas particulièrement dans le sens où tout fonctionne de manière acceptable. Mais certaines choses peuvent bien sur être améliorées, et notamment la gestion des dépendances qui pour le moment se fait plus ou moins à la main.

Le but est donc de déterminer si utiliser Maven (ou autre) permettrait d'améliorer certains aspect du processus, de le rendre plus robuste et évolutif etc... La difficulté pour moi, c'est que j'ai peu utilisé ant et pas du tout Maven, donc c'est assez difficile de me faire une idée des avantages des uns et des autres, et notamment si c'est vraiment utile de passer sous Maven.

Je peux alors poser ma question autrement: si on suppose que je ne connais ni Maven, ni ant, et que je souhaite mettre en place un environnement de développement évolutif et le plus simple possible pour quelques projets en environnement pro, que choisir ? Après avoir parcouru un peu le site de Maven, celui-ci semble séduisant sur le papier, mais bon... D'où mon post

Merci en tout cas de vos réponses.

[LittleBean]

@LittleBean : Que reproches tu à SVN ?

Pas grand chose, sauf que la gestion des dossiers et des tags laisse parfois à désirer.

J'ai l'impression que git est mieux mais je ne l'ai pas testé dans un cas réel de projet pour l'instant.

J'ai regardé un peu GIT et Subversion, et pour le moment je n'ai pas parfaitement compris le réel avantage de l'architecture distribuée de GIT par rapport à celle centralisée de Subversion. Ce que j'en ai retenu c'est que pour un petit nombre de développeurs, Subversion convient très bien.

En fait ça dépend plus du niveau et de la confiance que tu accord aux développeurs. Comme dans tous système décentralisé, il faut que tout le monde joue le jeu (et soit compétant). Dans plusieurs cas de projets j'aurais déconseillé de passer sous git, car c'était déjà pas facile de faire que tous le monde se synchronise bien avec un gestionnaire centralisé. Le commit du gars qui attend 2 semaines, ça fait mal...

La grande question surtout, c'est Maven VS ant sachant qu'il y a 4 projets, que potentiellement d'autres viendront, que certains projets dépendent d'autres et qu'il y a pas mal de dépendances externes.

Si tu as des projets confié à des équipes distinctes et des dépendances partout... là il n'y a pas photo c'est maven.

"Ils" c'est moi je suis en environnement pro.

il y a pour l'instant 3 développeurs (1 très actif, 2 occasionels),

Euh vous êtes 3 non? Ou tu es tout seul ?


Personnellement, je ferais l’ordre suivant :
1- ide + svn : minimum syndical
2- hudson + ant : intégration continue => objectif pouvoir faire des packaging/livraison à la demande
3 - Remplacer ant par maven : mettre à disposition dans le repository les versions courantes/livrées
3 bis Mettre en place des tests unitaires : junit (ou autre)
4 Mettre en place le reporting de base sous hudson : mail si build cassé, graph sur l'amélioration des tests, du nombre de build
5 Cerise sur le gâteau : test de qualité de code checkstyle.....

Ah oui, j'en ai pas parlé mais tu peux regarder aussi du côté de mylyn qui peut te lier tes commits et ton gestionnaire de fiche/bug.
Et si tu n'as pas de gestionnaire de bug, ça vient en 1 ou 1.5 !!!

[Robin56]

1- ide + svn : minimum syndical
2- hudson + ant : intégration continue => objectif pouvoir faire des packaging/livraison à la demande
3 - Remplacer ant par maven : mettre à disposition dans le repository les versions courantes/livrées
3 bis Mettre en place des tests unitaires : junit (ou autre)
4 Mettre en place le reporting de base sous hudson : mail si build cassé, graph sur l'amélioration des tests, du nombre de build
5 Cerise sur le gâteau : test de qualité de code checkstyle.....

Je me permets de faire quelques remarques sur ton organisation. Premièrement, je placerais l'intégration d'Hudson bien plus loin. Tu ne sembles pas avoir une grosse équipe et un panel de projets très important. Je ne sais pas non plus si tu as de nombreuses correction et évolutions et la fréquence de commit de ton équipe. Pour toutes ces raisons, je trouve que l'intégration d'Hudson est prématurée.
Je mettrais en place les tests unitaires avant Hudson. Ceux-ci sont primordiales pour mettre en place une bonne organisation de développement.

environnement de développement ~ cadre de développement, cadre ~ framework. Un racourcis / anglicisme facile certes, mais il me semble avoir été compris ce qui est le principal après tout

M'ouai non je ne suis toujours pas d'accord. Désolé d'être hors sujet mais si tu parles framework à un développeur, il va penser Grails, .NET 3.5, Hibernate, ...

[vinzzzz]

Je pense en effet d'abord me pencher sur la mise en place éventuelle de Maven avant Hudson. Un truc pas mal sur lequel je viens de tomber par rapport à Maven, est qu'il semble pouvoir etre utilisé indépendament de l'IDE: par exemple, NetBeans peut ouvrir un projet maven standard sans aucune modification nécessaire. Du coup on pourrait centraliser le versioning de l'ensemble des fichiers de config sans se soucier de l'IDE que le développeur voudra utiliser (ce qui n'était pas le cas avec ant).

Pour les tests unitaires ils sont déjà utilisés. Et pour préciser, on est bien 3 développeurs, mais je suis en charge de définir les technologies à utiliser pour la gestion de projet (sauf l'IDE avec un peu de chance).

M'ouai non je ne suis toujours pas d'accord. Désolé d'être hors sujet mais si tu parles framework à un développeur, il va penser Grails, .NET 3.5, Hibernate, ...

Je note j'avoue ne pas trop m'être penché sur la terminologie exacte des différents aspects qui touchent au développement.

[Robin56]

Je pense en effet d'abord me pencher sur la mise en place éventuelle de Maven avant Hudson. Un truc pas mal sur lequel je viens de tomber par rapport à Maven, est qu'il semble pouvoir etre utilisé indépendament de l'IDE

Être indépendant de l'IDE peut paraître une solution sympa mais (et c'est mon avis), je ne le préconise pas. Pourquoi ? Eh bien en dehors des aspects de Maven, si l'ensemble des développeurs ne travaillent pas sur le même environnement, c'est toujours source à emmerde (problème d'encodage de fichier, intégration de plugin faisant la même chose mais pas tout à fais, plugin introuvable sur un IDE et pas sur l'autre, formatage automatique différent d'un envir à l'autre, etc etc). Je te conseillerais donc de figer à tout le monde un IDE commun customisé comme il faut pour pallier à tout les développements. C'est gage de sécurité.

[LittleBean]

Je me permets de faire quelques remarques sur ton organisation. Premièrement, je placerais l'intégration d'Hudson bien plus loin. Tu ne sembles pas avoir une grosse équipe et un panel de projets très important. Je ne sais pas non plus si tu as de nombreuses correction et évolutions et la fréquence de commit de ton équipe. Pour toutes ces raisons, je trouve que l'intégration d'Hudson est prématurée.
Je mettrais en place les tests unitaires avant Hudson. Ceux-ci sont primordiales pour mettre en place une bonne organisation de développement.

C'est une question de préférence en effet .
Mais je pense qu'il est plus facile de faire accepter et de suivre des changements lorsqu'il y a des indicateurs (issus de l'intégration continue)

L'avantage de mettre en place hudson avant tout autre modification est que c'est complètement indépendant de ton process normal.
Une fois que tu as tes indicateurs à vert.
Tu peux bidouiller les environnements de dev, hudson te prévient si il y a un soucis (en théorie )

+1 Pour l'ide commun.

[lunatix]

si tu n'a pas de compétence particulière sur tous ces outils, tu peux aussi passer par un hébergeur

typiquement : cloudbees te propose husdon/repo maven/ svn ou git dans son hebergement dev@cloud. Tu pourras utiliser ces outils en oubliant la partie administration/mise en place. (of course, moyennant un cheque , mais ca peut valoir le coup)


sinon :mon avis

maven : indispensable en entreprise.
hudson : pareil : la validation des builds est obligatoire
IDE : intelliJ si tu as les moyens, ou eclipse/netbeans