Blog myBlog = BlogFactory.getWordPressBlog();
Article tagué Outils de développement
Gérer AUTREMENT un projet Maven avec Git
13/04/11
Comme vous avez été nombreux à apprécier mon article sur Maven et git, en voici la suite ! Il s’agit d’une solution alternative permettant de répondre à la même problématique, basée sur les subtree.
Rappel : mon but était de séparer la gestion de configuration de plusieurs modules Maven d’un même projet, tout en conservant un dépôt pour maintenir le projet (pom racine du projet, etc.).
La problématique étant la même, nous allons nous baser sur le même exemple : un projet créé à partir de l’archetype appfuse-modular-jsf. Pour sa mise en place de ce projet, je vous renvoie donc aux étapes Créer le projet de démonstration et Mise en place des dépôts distants.
Revenons à notre espace de travail
Maintenant que nous avons nos dépôts distants, la première chose à faire pour mettre en place les subtrees est de supprimer les répertoires des deux modules dans l’espace de travail. En effet, avec cette méthode, les modules n’ont pas de dépôt git locaux dédiés.
Déclarons ensuite les dépôts distants de notre espace de travail :
1 2 3 | git remote add origin $BARE_REPOS/demo.git # S'il n'existe pas déjà git remote add core $BARE_REPOS/demo-core.git git remote add webapp $BARE_REPOS/demo-webapp.git |
A ce stade, les habitués de git qui ne sont pas trop endormis doivent crier « KEUOUA ??? ». Effectivement, les démos distants sont normalement des clones du dépôt local. Or nous venons de déclarer trois dépôts distants qui n’ont pas un seul commit en commun.
Ce n’est pas une erreur, et c’est le mode de fonctionnement des subtrees. Contrairement aux submodules pour lesquels on avait trois dépôts locaux, avec les subtree, on a un unique dépôt local : le lien entre cet unique dépôt et les dépôts distants passe donc par les « remotes » du dépôt local.
Des branches locales pour travailler sur les modules
Nous allons maintenant créer des branches locales associées aux branches distantes afin de pouvoir travailler sur nos modules.
1 2 3 4 | git fetch core git fetch webapp git branch localcore --track core/master git branch localwebapp --track webapp/master |
Il est maintenant possible de travailler sur les modules localcore et localwebapp dans leurs branches locales respectives. Le tracking étant défini, les push seront effectués vers les dépôts respectifs des deux modules.
Et l’arborescence globale de notre projet ?
Depuis notre unique dépôt local, nous avons vu comment travailler séparément sur nos différents modules. Mais à ce stade, nous n’avons pas reconstitué l’arborescence de notre projet Maven. C’est à ce stade qu’interviennent les subtrees.
On rebascule dans la branche master de notre projet, et on exécute :
git read-tree --prefix=core/ -u localcore git read-tree --prefix=webapp/ -u localwebapp
Après cette étape, on n’oublie pas de commiter l’ensemble et nous avons récupéré l’arborescence globale de notre projet.
Mettre à jour le projet lorsque les modules évoluent
Notre module core a maintenant évolué dans sa branche. Ces modifications ne sont pas automatiquement reportées dans la branche master de notre projet.
Pour récupérer ces mises à jour, il suffit d’utiliser la commande :
1 | git merge -s subtree localcore |
Cette opération aura pour effet de fusionner dans la branche master les modules (ainsi que leurs historiques respectifs).
On peut juger que ces historiques sont « parasites » à ce niveau : on les a déjà dans la branche du module. On préfèrera dans ce cas la commande :
1 | git merge -s subtree --squash --no-commit localcore |
Cela aura pour effet d’agréger tous les commits en un seul et de préparer le message de commit (qui concatène les messages de tous les commits agrégés). Il ne reste plus qu’à corriger ce message et à valider le commit.
Submodules ou Subtrees ?
Nous avons donc deux méthodes permettant de traiter la même problématique. Il ne reste plus qu’à en choisir une. Les deux approches ont leurs avantages et leurs inconvénients.
Les subtrees sont plus faciles à manipuler : ils nécessitent moins d’opérations, et il est plus difficile de faire une erreur qu’avec les submodules (oubli d’un push par exemple).
Les submodules sont plus complexes à utiliser, mais plus structurés (il s’agit là d’un avis subjectif de ma part) : chaque dépôt distant est associé à un dépôt local.
Personnellement, ce sont les submodules que je préfère.
Gérer un projet Maven multi-modules avec Git
4/03/11
J’ai récemment assisté à l’atelier Git avancé de Christophe Porteneuve. Au programme, de nombreuses choses intéressantes, dont les submodules Git, La partie de la formation les concernant m’intéressait particulièrement pour une problématique que je rencontre très fréquemment : travailler avec un projet Maven multi-modules.
Il y a bien sûr la solution qui consiste à utiliser un unique dépôt Git à la racine du projet. Ca fonctionne bien, mais pour des gros projets, je préfère avoir un dépôt dédié à chacun des modules Maven. Cela ne poserait aucun problème, s’il n’y avait une arborescence de répertoires entre le projet principal, et ses modules.
Voyons donc avec un exemple comment mettre en place une gestion de configuration séparée pour chacun des modules d’un projet Maven.
La suite >
IntelliJ IDEA 10 au secours de Spring Roo
16/12/10
J’ai déjà abordé rapidement le cas de Spring Roo, qui est depuis passé en version stable 1.1.0, proposant une génération de la couche graphique avec au choix Spring MVC ou GWT (en version 2.1, dont la version stable est parue le même jour).
J’ai actuellement l’occasion de travailler sur plusieurs projets dont l’architecture technique est imposée par les normes du client (Hibernate + JPA, Spring, etc.). Ces normes cadrent ce qu’il est possible de faire, et en particulier, elles excluent un certains nombre de frameworks « de productivité » (Grails, Play, etc.). C’est sur ces projets que Spring Roo présente tout son intérêt, car il permet d’appliquer les mêmes principes que ces frameworks, et de gagner en productivité.
De plus, la syntaxe des scripts Roo étant assez simple, il est possible de développer des plugins UML permettant de générer automatiquement ces scripts à partir du modèle de données (et voilà comment on reprend aussi les bonnes idées du MDA en plus).
C’est donc cette approche et ces outils que nous utilisons sur les projets de ce type (architecture imposée à base de Spring) : effectivement, c’est un framework qui permet de largement gagner en productivité. De plus, on peut se séparer de Roo quand on le souhaite (quand le projet est suffisamment mature) dans le cycle de développement.
La suite >
Au revoir SVN… Bonjour Git !
7/12/10
Commençons par un résumé des épisodes précédents :
- Tout a commencé avec la découverte de Git.
- Après un premier test concluant, c’est à l’atelier de rentrée de Git-Attitude que j’ai vraiment appris à utiliser Git et eu « l’effet Whaou » !
- Convaincu par l’intérêt des DCVS, j’ai commencé à travailler avec Git comme frontal de Subversion : voir ici et là.
- Après avoir joué avec Git, « Git + SVN » laisse un sérieux arrière-goût d’inachevé. Nous avons donc cherché et trouvé une solution pour coupler Git au SI, de la même manière que SVN avant lui.
La solution ayant été trouvée, il ne reste plus qu’à effectuer la migration définitive de SVN vers Git, en conservant l’historique du projet.
La suite >
Git et LDAP en entreprise
19/11/10
Le gain apporté par les gestionnaires de configuration distribués n’est plus à démontrer. Dans ce domaine, les projets libres montrent la voie, et en utilisent presque tous un, que ce soit Git, Mercurial, etc.
Cela fait maintenant quelques temps que je teste Git, y compris au travail en interface avec SVN, notre gestionnaire de configuration d’entreprise.
Pour aller plus loin dans cette utilisation, il fallait envisager de remplacer (ou de doubler) le serveur SVN central par un repository Git central (« bare repository« ). La contrainte imposée par mon administrateur système préféré étant d’avoir le même système de gestion des droits d’accès, centralisé sur notre serveur LDAP (où chaque projet est associé à un groupe d’utilisateurs).
Voici différentes pistes que nous avons envisagées pour ce faire :
La suite >
Allons un peu plus loin avec Git-SVN
12/10/10
Il y a très peu de temps, j’expliquais comment utiliser Git avec SVN dans Eclipse. C’est maintenant quelque chose que j’utilise au quotidien, que ce soit avec Eclipse ou IntelliJ IDEA, mon nouveau choucou. Dans un cas comme dans l’autre, on ne coupera pas à l’utilisation des « external tools » pour la configuration des commandes « git svn rebase/dcommit/etc. »
Après plusieurs semaines d’utilisation, j’ai voulu étendre cette utilisation à d’autres commandes, afin de voir si on pouvait pousser plus loin les interactions entre Git et SVN.
La suite >
Découverte de IntelliJ IDEA
4/10/10
Je pourrais titrer ce billet « Confessions d’un éclipsien repenti », mais on m’accuserai de mauvais plagiat… et malgré la très bonne impression que m’a faite IntelliJ IDEA, j’apprécie toujours également mon fidèle Eclipse.
Mais revenons un tout petit peu en arrière… Depuis plus d’un an, j’entends parler de cet IDE : blogs, un récent comparatif, le Paris JUG, etc. J’avais donc décidé d’y regarder de plus près, mais sans jamais vraiment prendre le temps de m’y mettre. J’en ai eu récemment l’occasion, en testant le Play! Framework. Celui-ci dispose en effet d’une commande « idealize » permettant de générer le projet au format IDEA, qui n’a pas d’équivalent pour Eclipse. J’ai donc décidé de faire d’une pierre deux coups et de tester Play! en même temps qu’IntelliJ IDEA.
J’ai rapidement beaucoup apprécié les fonctionnalités de l’IDE, et j’ai donc étendu mon test à un projet Java/J2EE. Voici pas à pas le déroulement de ma découverte de l’IDE, pour les retardataires qui, comme moi, n’avaient pas encore franchi le pas…
La suite >
Spring Roo et Spring Tools Suite
29/09/10
Cela fait maintenant quelques temps que nous utilisons Spring Roo sur des projets professionnels (un outil de développement rapide proposé par SpringSource). Cependant, avant de vous donner mon avis sur cet outil, je vous invite à lire ces deux articles récents sur le sujet, qui m’ont inspiré :
- Un comparatif entre celui-ci et Play! Framework par Nicolas Martignole.
- Un bon tutoriel de Eric Molle (de Valtech).
De SVN à Git sous Eclipse
31/08/10
Il y a maintenant quelques semaines, j’ai été frappé par le virus Git. Dans la foulée, j’ai migré la gestion de configuration de mes composants pour Talend Open Studio sous GitHub. Et depuis, pour mieux maitriser cet environnement, j’ai pris ProGit comme livre de chevet.
Plus récemment encore, j’ai décidé de passer également sous Git mon environnement de travail professionnel pour le développement Java. Mais cette fois, ce n’est plus aussi simple, car on ne peut pas remplacer comme ça le serveur SVN central utilisé par les différentes équipes de développement.
Mais Git et Subversion peuvent être utilisés ensemble. On travaille sous Git en local, profitant ainsi de tous ses avantages (passage rapide d’une branche à l’autre, pour bien découpler les différents travaux, etc.), et on synchronise ce travail sous Git avec le serveur SVN.
Ce mode de travail et ses avantages ont très bien été expliqués dans le dernier article de Nicolas de Loof. En particulier, ce qui m’intéresse, c’est la rapidité de mise en oeuvre sans avoir à faire évoluer la plate-forme de développement d’un iota.
Cet article expliquant tout ce qu’il y a à savoir pour débuter avec Git et SVN, je ne recommencerai pas. Je vais donc aborder l’étape suivante : l’intégration de cette nouvelle méthode de travail dans mon environnement de développement.
Libérons (un peu) les développeurs
29/08/10
Il y a peu, j’ai posé sur Twitter la question :
Sondage express : pour ou contre le commit des fichiers propres à l’IDE dans le gestionnaire de sources ?
Un petit échange s’en est suivi avec @pierre_fauvel, qui pense que c’est en effet une bonne pratique. Pour ma part, je suis plus mitigé sur cette question… 140 caractères, c’est un peu court pour argumenter : je pensais donc publier un billet pour étayer mon avis sur la question. M. Fauvel a eu la même idée, et m’a devancé.
Avant de lire ce qui suit, je vous renvoie donc a son très intéressant billet sur la question.
Oui, il faut partager les bonnes pratiques
Je suis bien évidemment d’accord : il doit y avoir de la communication dans une équipe, ainsi qu’un partage des bonnes pratiques : c’est une évidence !
Il me vient tout de suite à l’esprit plusieurs applications concrètes incontournables de ce principe. En particulier pour tout ce qui concerne l’outillage du projet :
- l’outil de gestion de configuration : c’est la base du travail collaboratif. Il est donc inconcevable qu’un développeur n’utilise pas le même système que les autres
- la gestion du build : la manière de construise le projet doit être la même pour chaque développeur (Ant, Maven, Gradle, Ivy, ou autre), afin d’assurer la reproductibilité de celui-ci. C’est pour cela que nous mettons les fichiers de configuration du build (les pom.xml, profiles.xml, etc. de Maven dans notre cas) sont mis en gestion de configuration.
- les outils d’intégration continue ainsi que les résultats associés (tests en échec, métriques de qualité Sonar, etc.)
- les règles de qualité de code à mettre en place (PMD, CheckStyle, FindBugs). En particulier pour celles-ci, il est important que tous les développeurs soient convaincus de leur utilité, et soient d’accord sur les limites à appliquer et leurs raisons : pourquoi limiter une méthode à 30 lignes de code plutôt que 20 ou 40 ?…
Mais il faut aussi laisser une marge de liberté aux développeurs…
Les points précédents étant acquis, il ne faut pas non plus trop vouloir trop contrôler. En particulier, je ne suis pas partisan d’avoir un environnement de développement unique, configuré de la même manière pour tous les développeurs, et dont la configuration serait mise en gestion de configuration.
En effet, même s’il faut partager les bonnes pratiques, il me semble que certaines pratiques ne peuvent justement pas être hiérarchisées. Dans ce cas, pourquoi en imposer une plutôt qu’une autre ?
Prenons un exemple concret : l’utilisation de SVN avec Eclipse. On peut utiliser Subclipse ou Subversive. Les deux ont des fonctionnalités similaires, et le choix est donc affaire de préférence plus que de « bonne pratique ». On pourrait effectivement choisir d’en imposer un arbitrairement, afin d’uniformiser les environnements de développement, mais j’avoue que je n’en vois pas l’intérêt : le choix n’impacte en rien la productivité, et je préfère donc laisser la liberté à chacun de choisir celui qu’il préfère.
Les développeurs ont souvent leurs propres habitudes, et leurs outils préférés. Et bien souvent, il existe des outils concurrents dont il est difficile de dire lequel est meilleurs que l’autre :
- vi, kate, emacs, etc. pour l’édition de fichiers sur les systèmes Unix
- Notepad++, PSPad, etc. pour faire la même chose sous Windows
- 7Zip ou PeaZip pour la gestion des archives sous Windows
- etc.
Plutôt que d’imposer un outil unique, je préfère laisser le choix aux développeurs d’utiliser celui qu’ils préfèrent. Ainsi, chacun sera efficace (en utilisant l’outil avec lequel il est à l’aise), et cela ne pénalise à mon avis pas le travail de l’ensemble de l’équipe.
Si je fais ce choix, c’est aussi pour une question de moral : un développeur n’est pas un enfant, et n’aime donc généralement pas qu’on le prenne pour tel. J’ai tendance à penser que chacun est à même de décider quels outils lui conviennent le mieux, et appréciera de pouvoir les utiliser : il en sera non seulement plus efficace, mais aussi plus motivé qu’on lui fasse confiance.
Tout ceci n’étant bien sûr vrai que dans la mesure où ces choix personnels ne sont pas gênants pour le travail de l’équipe. Bien sûr, nous discutons souvent de ces choix, et parfois, nous convainquons nos collègues qu’un logiciel est vraiment meilleurs qu’un autre. C’est ainsi que sur la recommandation de Damien, j’ai adopté yEd pour l’édition de diagrammes.
Quelques exemples
Un de mes collaborateurs a préféré travailler sous Ubuntu plutôt que sous Windows. Cet OS répond à ses besoins, et est parfaitement compatible avec le travail du reste de l’équipe (SVN, serveurs de test, etc.). Sa licence Windows a été installée sur une machine virtuelle lorsqu’il en a besoin occasionnellement.
Mon nouveau dada, c’est Git. J’en ai fait la présentation aux équipes de développement, mais avant de le déployer à grande échelle, je préfère le tester : je l’ai donc installé localement, en le connectant au SVN de l’équipe. Mon environnement est donc « personnalisé », mais cela n’impacte pas le travail de l’équipe. Si je suis convaincu, je proposerai aux autres cette solution, en leur présentant ses avantages, mais en laissant libres ceux qui préfèrent garder leurs habitudes de travailler directement avec Subversion. Et il y a des arguments pour chacune, comme par exemple le plugin EGit pour Eclipse qui n’est pas encore du tout au niveau de ceux qui existent pour SVN (mais là, j’anticipe sur un prochain article…).
Nous travaillons tous sous Eclipse. Je n’ai jamais eu l’occasion de travailler avec des IDE mixtes. Mais dans la mesure où d’autres IDE (Netbeans par exemple), permettent de travailler avec Maven, SVN, etc., je ne pense pas que cela soit impossible ou nuisible. Ainsi, si un collaborateur préférait par habitude utiliser un autre IDE, je n’y verrais pas d’inconvénient (mais là, je suis peut-être un grand optimiste).
Conclusion
Afin de laisser cette marge de manoeuvre aux développeurs, il faut y mettre quelques moyens. Deux d’entre eux me viennent à l’esprit :
- chaque développeur est administrateur local de sa machine
- maintien de manière collaborative (wiki, par exemple) d’une liste de « logiciels recommandés » par catégorie : édition de texte, etc., voire d’un centre de téléchargement interne, pour accélérer la vitesse d’accès et uniformiser les versions des logiciels (lorsque c’est pertinent)
- chacun a un accès à Internet peu restreint, permettant au moins l’accès au téléchargement de logiciels (libres) de son choix, mais aussi à la veille technologique, aux forums de discussion techniques, etc. (personnellement, je préconise même l’absence totale de blocage, sauf en cas d’abus manifestes).
A mon sens, cette souplesse ne va pas à l’encontre d’un développement structuré, tant qu’elle respecte la plate-forme de développement commune et les spécificités du projet. Elle permet aux membres de l’équipe de tester plusieurs outils, et d’échanger sur leurs expériences avec ceux-ci.
Cette diversité permet de multiplier les tests comparatifs, de communiquer et de capitaliser sur les résultats de ces tests :
- si un outil a clairement l’avantage sur ses concurrents, il sera naturellement adopté par l’ensemble de l’équipe
- si les outils ne peuvent être départagés, il n’est pas la peine de choisir
Mais revenons au sujet initial. Pour les raisons évoquées ci-dessus, je ne mets pas les fichiers propres à l’IDE sous gestion de configuration. Je ne considère pas la configuration de l’environnement de développement comme étant une « partie intégrante du projet ». Ceci dit, une « configuration type du projet » est tout de même accessible pour ceux qui la veulent : elle n’est pas sous SVN pour éviter à ceux qui ont une configuration personnalisée d’écraser par erreur lors d’un commit celle par défaut.
