OCTO talks ! » maven

Faut-il passer à Maven 3 ?

Jonathan Scher — Fri, 08 Jul 2011 13:05:40 +0000

Maven 3 est sorti depuis quelques mois, et ne propose que peu de nouvelles fonctionnalités au développeur qui l’utilisera. Quelles sont ces nouveautés ? Pour les projets utilisant Maven 2, faut il les passer sur la nouvelle version ? Réponse courte : oui. Aujourd’hui, il y a peu à gagner, mais la rétrocompatibilité est presque totale. Pour plus de détails, lisez la suite…

Une plus grande rapidité dans le build.

Deux améliorations permettront une plus grande rapidité de build : une gestion des entrées/sorties (I/O) plus efficace, et le fait de pouvoir construire//tester en parallèle, tirant mieux parti des processeurs multi-cœurs.
Pour illustrer cette évolution, j’ai choisi de construire Struts 2 avec Maven 2, avec Maven 3, puis avec Maven 3 en lui forçant deux threads en parallèle (option -T 2). Struts 2 est un projet de plus de 100 000 lignes de code, réparties sur 38 modules. Le module « core » contient à lui seul près de 800 tests unitaires.
Voici les résultats. Ils ont été réalisés sur un Core 2 Duo, avec 8Go de ram et un ssd.

1 seul module			38 modules
Maven 2	Maven 3	Maven 3 -T 2	Maven 2	Maven 3	Maven 3 -T 2
57 sec	56,486 sec	56,440 sec	8 min 41 sec	8 min 11 sec	6 min 23 sec

Sur un projet ne contenant qu’un unique module, la différence ne se fait presque pas sentir. Sur un SSD, je suppose que les optimisations d’I/O ne sont pas significatives. Par contre, sur le projet de 38 modules, le gain est de 25%.

En multi-modules, Maven 3 optimise votre build, en construisant en parallèle vos différents modules. Cela pose quelques contraintes. Si tous vos modules forment une chaîne de dépendances, impossible d’en construire plusieurs en parallèle. Au contraire, si vos dépendances sont légères, Maven 3 améliorera vos performances.

Par ailleurs, si vous construisez en parallèle, pensez à vos tests, particulièrement ceux d’intégration. Partagent-ils une base de données en commun ? Dans ce cas, partagent-ils la même donnée ? Vous pourriez alors avoir des surprises.

Que va t’il falloir changer sur mon projet ?

Pour réaliser le test, je n’ai pas eu besoin de changer les pom.xml. La rétro compatibilité est forte.

Au niveau des plugins, beaucoup sont immédiatement compatibles. En voici une matrice de compatibilité.

Si à la sortie, certains logiciels connexes ne fonctionnaient pas avec Maven 3, tous le supportent aujourd’hui. Jenkins (ou Hudson) intègrent Maven 3 depuis janvier. Le plugin m2eclipse est également compatible avec Maven 3. C’est d’ailleurs la version qui est intégrée avec m2eclipse, lorsque vous le téléchargez depuis le site d’Eclipse Indigo.

Parmis les plugins incompatibles, vous trouvez Maven Site. Une version beta compatible est actuellement disponible.

Sinon, la liste des soucis de compatibilité est disponible.

Validation du pom plus stricte

Une nouvelle fonctionnalité est particulièrement utile. Désormais, Maven est plus strict sur la validité des fichiers pom.xml. Par exemple : si vous avez une erreur d’héritage, Maven 3 refusera de compiler au début plutôt que de planter au milieu. Si vous avez déclaré la même version d’une dépendance dans votre parent et dans votre sous module, Maven vous enverra un warning.

M2Eclipse intègre ces warnings. Dans Eclipse, il vous indique directement les lignes auxquelles il faut faire attention, dans vos pom.xml. Du coup, on peut corriger immédiatement et simplement ces petites choses qui peuvent vous poser problème un jour.

Et voilà !

Il existe des projets connexes. Avec une extension, vous pouvez écrire vos pom dans d’autres langages que le xml. Il existe une console, qui vous permet de gagner le temps de démarrage de Maven. La version 3.1 intégrera peut être les mixin. Je ne doute pas que d’autres projets de ce type existeront prochainement.
Faut il migrer dès aujourd’hui à Maven 3 ? Ca ne coûte pas grand chose, cela peut optimiser votre build, et ça vous prépare à l’avenir.

Suggestion d'articles :

Développer des applications Android avec Maven

Jérôme Van Der Linden — Thu, 17 Feb 2011 10:33:20 +0000

Il y a quelques mois de cela, je vous parlais d’industrialisation des développements Android. Tout n’était pas parfait pour être vraiment productif, notamment l’intégration entre les outils de build et l’IDE. Qu’en est-il aujourd’hui ? Peut-on enfin être aussi efficace sur du développement Android que sur du Java standard ? Ce sont les questions auxquelles je réponds dans cet article.

Maven enfin utilisable… ou presque !

Lorsque nous l’avions testé avant l’été, nous avions rencontré des problèmes avec le trio Maven / Android / Eclipse. L’intégration Eclipse/Android se passe très bien avec ADT et Eclispe/Maven fonctionne à merveille avec m2eclipse. L’intégration Maven/Android était un peu compliquée de par l’absence des jar Android sur le repo central mais fonctionnait tout de même (avec le plugin maven-android-plugin). Le véritable point noir était l’intégration des trois.

Aujourd’hui, tout cela a évolué et le plugin m2eclipse-android-integration (qui existait déjà à l’époque) fonctionne !

Il est donc bien plus simple de travailler avec nos outils habituels (je ne rentre pas dans les détails, chacun des outils est globalement bien documenté si vous avez un soucis) :

Installation

Premièrement, récupérez et installez chacun des outils suivant : Eclipse, Maven, le SDK Android et les plugins ADT (Android Development Tools), m2eclipse et m2eclipse-android-integration pour Eclipse.
Définissez les variables d’environnements nécessaires : JAVA_HOME, ANDROID_HOME et le PATH vers les binaires (mvn et les tools Android).
Créez votre projet Android dans Eclipse comme vous le faites habituellement.
Transformez ensuite votre projet en projet Maven (click droit sur le projet / Maven / Enable Dependency Management). Il devrait automatiquement vous créer un pom.xml très basique dans lequel il va falloir ajouter quelques éléments pour pouvoir utiliser le plugin maven-android-plugin.
Dans le settings.xml de Maven, ajoutez la configuration suivante, cela vous permettra d’utiliser ce plugin sans avoir à spécifier le groupId :
```
com.jayway.maven.plugins.android.generation2
```

Au niveau du pom, plusieurs choses avant d’être complètement opérationnel. Au niveau du packaging, précisez que vous créez un apk. Configurez ensuite le plugin de jayway comme suit (plus d’options et d’infos ici) :


  src


      com.jayway.maven.plugins.android.generation2
      maven-android-plugin
      2.6.0
      
        
${env.ANDROID_HOME}
8
        
        true
      
      true
    

      maven-compiler-plugin
      2.3.2
      
        1.6
        1.6

Et voilà ! Votre projet Android est mavenisé et intégré à Eclipse (il vous faudra peut être ajouter le répertoire « gen » aux répertoires sources d’Eclipse). Il ne reste plus qu’à ajouter des dépendances…

Problèmes de dépendances

Peu de dépendances sur le repo central

Sur ce point, on n’est pas encore au niveau des projets java habituels. En effet, le nombre de dépendances Android qui sont disponibles sur un repo ou un autre est encore assez mince. Alors on a Android lui même, après l’avoir attendu très longtemps :


  com.google.android
  android
  2.2.1
  provided

On a également les dépendances java habituelles (commons-* et tout ce que vous pouvez trouver sur central), pour peu que ça compile sur Android. Mais à côté de ça, admob, google analytics, … et même google maps ne sont pas disponibles et devront être ajouté à la main :

mvn install:install-file -Dfile=$ANDROID_HOME/add-ons/addon_google_apis_google_inc_8/libs/maps.jar -DgroupId=com.google.android.maps -DartifactId=maps -Dversion=8_r1 -Dpackaging=jar

Bien sûr, si vous avez un référentiel d’entreprise type nexus ou archiva, ca simplifiera le travail aux développeurs.

Librairies

Autre problème, les librairies Android, des projets déclarés « is library » dans Eclipse et simplement utilisés comme dépendances de projet (par exemple Greendroid ou l’Api Facebook…). Le plugin maven-android-plugin prévoit bien de générer un package apkSources, censé être ensuite utilisable comme dépendance par un autre projet… Le soucis, c’est que le fichier R.java n’est pas disponible dans le package et par conséquent la compilation échoue.

Une issue a été créé sur ce point et une solution officieuse existe : Une branche alternative du projet jayway a été créé et propose le packaging apklib qui corrige le problème de compilation.

Il vous faudra donc maveniser les librairies que vous utilisez si elles ne le sont pas déjà. Prenons l’exemple de greendroid. Dans ce projet, ajouter un pom qui aura la définition suivante (ainsi que la conf mentionnée plus haut) :

com.greendroid
greendroid
1.0
apklib

Exécutez la commande mvn install pour déployer l’apklib dans le repo local (com/greendroid/greendroid/1.0/greendroid-1.0.apklib).
Enfin, configurez votre projet :

		
			com.greendroid
			greendroid
			1.0
			apklib

Ca nécessite un peu de boulot mais ca fonctionne. J’ai demandé quand on pouvait espérer cette fonctionnalité dans la branche principale du plugin mais aucune réponse n’a été fournie.

Un plugin complet

Une fois ces soucis de compilation et de dépendances résolues, pas mal de choses sont ensuite possibles avec le plugin maven-android-plugin : deployer un apk sur l’émulateur ou un téléphone branché en USB (mvn deploy), signer et « zipaligner » un apk avant un déploiement sur le Market, et tout un tas d’autres commandes dont vous trouverez la liste ici (et notamment les tests dont nous allons parler juste après).

Associé à cela, Hudson (pardon, Jenkins) et le plugin Android dont nous avions parlé la dernière fois, et vous êtes paré pour développer des applications Android d’Entreprise !

Conclusion

Tout n’est pas encore tout rose et quelques réglages manuels sont nécessaires pour avoir un environnement prêt à l’emploi. Mais une fois ces manipulations effectuées, vous voilà parés pour développer vos applications Android avec Maven. Dans mon dernier article à ce sujet, je n’étais pas totalement favorable à son utilisation (peu de librairies, environnement non fonctionnel). Je reviens sur ce choix aujourd’hui du fait du nombre grandissant de librairies utilisées sur nos projets (greendroid, spring-android, analytics, jackson, …) et de l’évolution des outils. Les projets Android se complexifient et un outil comme Maven devient désormais nécessaire.
Quid de la qualité de ces projets ? … dans un prochain article !

Suggestion d'articles :

Mise en place technique de FitNesse

Thomas Queste — Sat, 04 Dec 2010 15:24:48 +0000

Mettre en place FitNesse dans une équipe n’est pas particulièrement évident. Il y a plusieurs possibilités et certaines sont plus efficaces que d’autres.

La mise en place décrite dans cet article offre une bonne combinaison d’avantages et d’inconvénients. Elle permettra le travail commun de deux équipes : une équipe de fonctionnels utilisant un serveur central, et une équipe de développement écrivant les fixtures directement depuis leur workspace.

Lisez la suite de l’article en anglais : http://blog.octo.com/en/fitnesse-technical-setup

Suggestion d'articles :

Industrialisation des développements Android

Jérôme Van Der Linden — Thu, 15 Jul 2010 08:24:01 +0000

Avec la croissance de la plateforme Android et l’annonce de Google sur le nombre de terminaux activés chaque jour, le nombre de projets Android a de bonnes chances de progresser également. Avec cette augmentation, la question de l’industrialisation des développements se pose donc. Pourquoi industrialiser ? Comment ? Des questions auxquelles nous allons répondre dans ce billet…

Pourquoi industrialiser ?

Autant sur une application de gestion, la question ne se pose quasiment pas, autant sur une application Android, on est en droit de se demander si cela vaut le coup.

Effectivement, alors que les projets java se déroulent généralement sur plusieurs mois avec des équipes un peu conséquentes, les projets d’applications mobiles sont généralement plus courtes, avec des équipes plus petites. Les applications doivent être innovantes et rapidement mises sur le Market pour arriver avant la concurrence. Cela vaut-il donc le coup d’investir dans tous les moyens habituels (build, intégration continue, …) qui peuvent paraître lourds et démesurés pour un tel projet ?

A fortiori, le versionning du code est indispensable, peu importe la nature et la taille du projet. Je ne vais pas m’étendre sur le sujet, cela fait des années que cette pratique s’est généralisée. Concernant le build et l’intégration continue, cela a un intérêt dès lors que l’équipe de développement est constituée de plus d’une personne. Cela facilitera le travail des développeurs et permettra d’avoir une version rapidement montrable au marketing ou la MOA, indispensable pour avoir du feedback rapide.

Malgré la taille réduite de ces projets, il ne faut donc pas hésiter à investir un minimum pour faciliter le travail des développeurs d’une part et dans une optique de maintenance d’autre part. L’application doit certes sortir rapidement, mais elle devra continuer de vivre et d’évoluer et donc la qualité incombe.

Maven, la bonne solution ?

Maven a ses détracteurs mais est globalement très répandu en entreprise pour construire les projets java. Concernant Android, je ne suis pas sûr qu’on puisse en dire autant pour le moment…

Après l’avoir utilisé sur l’application Sinistres de Generali, plusieurs constats :

Les jar Android n’étaient disponibles dans aucun repo central. J’ai contacté Romain Guy pour avoir des infos sur le sujet mais aucune réponse. Ils sont disponibles depuis quelques jours sur le repo central. Enfin ! Par contre, il manque encore google maps.
Le plugin mosabua, décrit dans le livre Maven Definitive Guide, censé remédier à cela en installant les jar dans le repo local, nécessitait il y a encore peu de temps de modifier les pom.xml pour concorder avec les versions du SDK Android (1.5 pour la 3, 1.6 pour la 4…). Cela semble aujourd’hui résolu mais nous a fait perdre pas mal de temps.
Une fois installé, le plugin fonctionne plutôt bien et permet de compiler, tester, packager, déployer sur un émulateur… depuis sa ligne de commande mvn.
Par contre, n’espérez pas trop utiliser le trio Eclipse – Maven – Android, y compris avec m2eclipse. Les trois s’entendent assez mal : les projets Android sous Eclipse ont un format un peu particulier (répertoire gen généré lors des modifications de ressources, référencement du sdk Android). Lorsque m2 est activé sur le projet ou simplement avec eclipse:eclipse, plus rien ne fonctionne : On perd le type Android du projet et il s’emmêle les pinceaux avec le répertoire gen donc impossible de travailler depuis Eclipse, fâcheux. Il existe un plugin eclipse supplémentaire pour tenter d’intégrer les trois mais ca n’a pas fonctionné pour moi…

Au final beaucoup de temps perdu pour avoir un environnement de développement un peu bancal et la question : est ce que Maven est vraiment utile dans notre cas ? On pense tout de suite à Maven lorsqu’il s’agit de builder notre application mais n’est-ce pas un peu too much ?

L’un des principaux bénéfices de Maven est la gestion des dépendances. Hors, dans une application Android, le nombre de dépendances est somme toute assez ridicule. Vous aurez généralement l’api google maps, éventuellement une librairie pour faire du soap, et en poussant le bouchon admob ou google analytics. Aucune dépendance transitive. Bref, pas de quoi sortir la grosse artillerie. D’autant plus qu’aucune de ces librairies n’est dispo dans un repo central et il vous faudra donc les installer manuellement dans un repo d’entreprise ou local.

Pour le reste, toutes les commandes disponibles grâce au plugin Maven le sont également avec ant, qui semble être l’outil préconisé par Google.

Ant, la solution fournie en standard

Lorsque vous créez un projet via la ligne de commande (android create project --target 8 --name AndroidAnt --path ./AndroidAntProject --activity AndroidAntActivity --package com.octo.android.androidant), un fichier build.xml est généré, contrairement aux projets créés dans Eclipse. Ce build.xml minimaliste (quasiment vide) fourni toutefois l’essentiel des tâches nécessaires :

clean, pour nettoyer le projet
compile, pour compiler le code et générer les classes
debug, pour générer le package (apk) avec le keystore de debug (généralement dans $HOME/.android/debug.keystore)
release, pour générer le package avec votre keystore (généralement celui que vous allez utiliser pour publier sur le market)
install, pour installer l’application sur un émulateur (démarré) ou un device connecté.
uninstall, pour désinstaller l’application précédemment installée.

C’est assez confortable car vous n’avez pas à écrire ces tâches, elles sont définies dans le fichier {SDK}/platforms/{platform}/templates/android_rules.xml. Comparé à toutes les tâches plus ou moins manuelles à effectuer avec Maven, on y gagne franchement au départ.

Par contre, la solution Ant souffre également de l’intégration avec Eclipse. En effet, les tâches étant définies dans un fichier externe, elles ne sont pas disponibles dans la vue Ant. La solution alternative consiste à utiliser les external tools avec une des commandes ci-dessus.

Intégration continue

Si les deux outils vu précédemment sont un peu en désaccord avec l’IDE, ils n’en restent pas moins tout à fait utilisable en dehors via la ligne de commande et donc également via un outil d’intégration continue comme Hudson.

Aussi simplement que sur un projet Java standard, vous pouvez configurer un build (maven ou ant) et la commande souhaitée. Mais Hudson va plus loin puisque via le plugin Android Emulator Plugin, vous pouvez démarrer l’émulateur au début du build et l’éteindre à la fin. Vous pouvez également installer l’application sur différentes configurations (version d’Android, résolution d’écran, densité d’écran, locale) afin de valider l’application sur les différentes plateformes cibles.
Si vous ne testez que sur une plateforme, mieux vaut laisser un émulateur fonctionner, ca évite de perdre plus de 5 minutes à chaque build.

Pour le reste, tout se passe comme pour un build standard, la seule particularité étant d’avoir le SDK installé sur le serveur d’intégration continue.

Conclusion

	Maven	Ant
Simplicité / Prise en main	2/5 (plugins diverses pas encore opérationnels)	4/5 (par défaut avec Android)
Gestion de dépendances	3.5/5 (les jars android sont enfin sur central, manque encore maps)	2/5 (pas besoin de préciser les jars android)
Intégration IDE	2.5/5 (utiliser les external tools)	2.5/5 (utiliser les external tools)
Intégration continue	4/5 (plugin hudson)	4/5 (plugin hudson)
TOTAL	12 / 20	12.5 / 20

Alors, Ant ou Maven ? Après nos déboires avec Maven sur le projet Generali, j’aurai conseillé Ant sans hésiter. L’arrivée (très) récente des jars dans le repo central me laisse à penser qu’on pourra bientôt travailler avec Maven, Android (et Eclipse) plus sereinement.

Android a l’avantage d’être basé sur le langage Java. On bénéficie ainsi des outils existants pour construire nos applications. Si l’intégration n’est pas totale entre l’IDE, le SDK et ces outils de builds, ils sont indispensables sur un serveur d’intégration continue. C’est aujourd’hui leur principal intérêt, car Eclipse et le plugin Android (AJDT) restent à mon sens incontournable sur le poste du développeur pour être productif.

Dans un prochain article, nous aborderons les problématiques de qualité du code et des tests…

Suggestion d'articles :

Maven: Mes plugins préférés

Henri Tremblay — Mon, 11 Jan 2010 10:39:36 +0000

Ayant beaucoup utilisé Maven ces derniers temps, j’ai dû faire pas mal de recherches pour lui faire faire ce que je voulais. Cela m’a permis de découvrir une série de plugins intéressants que je vous livre ici. De façon générale, il s’agit de plugins méconnus mais qui m’ont fait pousser un « Oh la bonne idée super pratique » lorsque je l’ai découvert. Avec un peu de chance, vous aurez la même réaction.

Évidemment, de nombreux autres plugins sont disponibles, utiles et bien faits. J’ai voulu focaliser ici sur mes nouvelles découvertes et sur les anciens qui sont revenus en grâce. Si vous recherchez un plugin, les deux points de départ sont http://maven.apache.org/plugins/ et http://mojo.codehaus.org/. Ensuite, Google est votre ami.

Débogage Maven

maven-help-plugin (org.apache.maven.plugins)

Plugin existant depuis toujours et s’étoffant tranquillement. Il permet d’avoir des informations sur un projet.

Buts préférés:

help:active-profiles – Liste de profils actifs pour ce build
help:effective-pom – Crée le pom résultant de la résolution des profils actifs, de héritage et des variables
help:evaluate – Permet d’évaluer une expression Maven (par exemple ${project.version}). Prend en considération les profils actifs

maven-dependency-plugin (org.apache.maven.plugins)

Un autre plugin relativement vieux. C’est le plugin ultime pour résoudre les problèmes de dépendances transitives.

Buts préférés:

dependency:tree – Vous donne un arbre de dépendances indiquant qui tire quoi et dans quel scope. Absolument indispensable pour faire le ménage

versions-maven-plugin (org.codehaus.mojo)

Mon tout nouveau plugin préféré. Il permet de gérer les versions d’un peu tout. En particulier, vous pourrez mettre à jour la version des poms enfants à partir de celle du pom parent. Vous pourrez aussi vérifier si les versions de vos dépendances et de vos plugins sont à les dernières disponibles. C’est un peu le plugin qu’on attendait depuis toujours.

Buts préférés:

versions:display-dependency-updates – List toutes les dépendances ayant une version plus récente
versions:display-plugin-updates – Liste tous les plugins ayant une version plus récente
versions:update-child-modules – Il faut tout d’abord changer la version du pom parent. En appelant ensuite ce goal sur le pom parent, il mettra à jour les versions dans enfants. Très pratique pour faire des changements de versions
versions:set – Comme update-child-modules mais permettant de spécifier la nouvelle version en ligne de commande (-DnewVersion=VALUE) au lieu de changer le pom parent.

Packaging

maven-remote-resources-plugin (org.apache.maven.plugins)

Un plugin un peu obscur mais très utile pour partager des ressources entre plusieurs projets. Il permet de récupérer un « resource bundle » qui est en fait un jar avec un packaging particulier et disponible dans le repository maven. Le contenu de ce jar est filtré et ensuite intégré à l’artifact en cours de construction. Par exemple, pour un project sous license Apache, cela permet d’ajouter les fichiers au jar les fichiers requis par la licence (LICENSE, NOTICE, …).

Buts préférés:

remote-resources:process – Le goal permettant d’intégrer le « resource bundle » à l’artifact courant

maven-license-plugin (com.mycila.maven-license-plugin)

Un autre plugin que j’ai récemment découvert et qui change la vie. Il permet de mettre le classique petit texte de copyright requis par une licence au haut de tous les fichiers du projet. Le formatera l’entête en fonction du type de fichier ( pour xml, # pour .properties, /* */ pour .java, etc.). Il y a aussi la possibilité de valider la présence de la licence durant la compilation.

Buts préférés:

license:format – Ajouter la licence à chaque fichier
license:check – Valide que la licence est correctement mise pour chaque fichier

maven-bundle-plugin (org.apache.felix)

J’aime bien aussi celui-là. Il transforme votre artifact en un bundle OSGi avec presque aucune configuration. Il n’y a pas de but explicite car il se lie lui-même à la phase prepare-package.

maven-shade-plugin (org.apache.maven.plugins)

Utiliser pour faire un uber jar, c’est-à-dire un jar agrégeant le contenu de plusieurs jars. Pour ceux qui connaissent, il fait plus ou moins la même chose que jarjar pour lequel il n’existe pas de plugin Maven. Un exemple d’utilisation et la création d’un jar exécutable.

Buts préférés:

shade:shade – Effectue la « uberisation »

Divers

maven-timestamp-plugin (com.keyboardsamurais.maven)

Pas vraiment un plugin de reporting mais très utile pour en faire. En fait il comble un lacune de Maven qui est qu’il n’y a pas de variable pour la date. Donc ce plugin vous permet de mettre la date/heure dans des variables sous le format que vous voulez (SimpleDateFormat servant d’interpréteur). Vous pouvez donc utiliser ces variables par la suite.

Buts préférés:

timestamp:create – Pour créer une variable contenant la date. Il faut mettre plusieurs exécutions pour avoir plusieurs formats différents

Reporting

maven-clover2-plugin (com.atlassian.maven.plugins)

Donne un rapport Clover, c’est-à-dire un rapport complet de la converture du code par les tests. Il est relativement connu et je le mentionne ici pour indiquer qu’il est désormais activement maintenu par Atlassian et suit de très près les livraisons Clover. Il est aussi maintenant très étoffé et beaucoup plus facilement configurable qu’historiquement.

Buts préférés:

clover2:instrument – Effectue l’instrumentation du code
clover2:clover – Genère le rapport Clover
clover2:check – Vérifie que la couverture dépasse le pourcentage désiré

findbugs-maven-plugin (org.codehaus.mojo)

Autre plugin très connu qui souffrait d’un problème de maintenance dernièrement. Il semblerait que certaines personnes s’y sont penchés et il suis maintenant relativement correctement les mises à jour findbugs.

Buts préférés:

findbugs:findbugs – Génère le rapport findbugs. En général, on configure plutôt le plugin dans la section reporting du pom pour l’avoir au moment de la génération du site
findbugs:check – Fait planter le build si findbugs trouve des erreurs

Optimisation du build

Les dernières versions de Maven se sont en autres consacrées à l’amélioration de la productivité. Plusieurs options en ligne de commande ont été ajouté. Elles proviennent à peu près toute du maven-reactor-plugin qui a été redescendu au coeur de Maven. Il ne s’agit donc pas vraiment de plugins mais ça reste pratique de savoir qu’elles existent.

Nouvelles options:

–resume-from (-rf): Permet, pour un projet multi-module, de recommencer la compilation à partir d’un projet donné. Utile par exemple lorsque le build a échoué au milieu et que vous ne voulez pas reprendre du début.
–also-make (-am): Construire les projets mentionnés et leurs dépendances.
–also-make-dependents (-amd): Construire les projets mentionnés et les projets en dépendants.

Anciennes options:

–non-recursive (-N): Ne construire que le projet courant sans ses sous-modules. Surtout utile pour installer un pom parent ou bien faire tourner un plugin.
–file (-f): Utiliser le pom en paramètre et non le pom du répertoire courant. Cela va en pratique compiler un projet quelconque sans changer de répertoire (j’utilise surtout cette option dans des .bat utilitaires).
–projects (-pl): Construire les projets spécifiés en ligne de commande. Permet d’avoir un build très spécifique.

maven-reactor-plugin (org.apache.maven.plugins)

Comme mentionné plus haut, ce plugin n’est presque plus nécessaire (si vous utilisez une version Maven 2.1.x ou supérieure) car il a été intégré dans le coeur de Maven. Il reste toutefois un but intéressant. Ils n’ont pas pu le mettre à plus bas niveau car il dépend de fonctionnalités de SCM qui ne sont pas présentes dans le coeur.

Buts préférés:

reactor:make-scm-changes: Ne recompile que les projets (et les projets en dépendant) ayant des fichiers géré dans le SCM et modifiés localement. C’est assez magique comme optimisation car il ne recompile que ce qui est nécessaire. Faire attention toutefois, si votre SCM est un peu longuet à déterminer les changements locaux, cela peut parfois être plus long qu’un build en entier.

Suggestion d'articles :

Distribuer les tests JUnit avec Gridgain et Maven

Jérôme Van Der Linden — Mon, 02 Nov 2009 05:20:46 +0000

Dans un précédent article, Meriem Berkane introduisait le build distribué et notamment la distribution des tests sur des agents. TestNG propose cette fonctionnalité de base, JUnit par contre ne le fait pas. Mais Gridgain vient combler ce manque depuis sa version 1.6. Dans cet article, je vais donc mettre en oeuvre Gridgain dans un build Maven afin de pouvoir, par la suite, l’utiliser sur le serveur d’intégration continue.

Gridgain

Gridgain est un framework open source permettant de développer des applications java en cloud ou en grille. Basé sur des annotations, il permet depuis la version 1.6 de distribuer les tests :

public class GridTests extends TestSuite {
 
	@GridifyTest
	public static Test suite()
	{
		TestSuite suite = new TestSuite("Test for com.octo.gridgain");
		suite.addTestSuite(ClientDaoTest.class);
		// ...
	}
}

L’annotation @GridifyTest permet d’exécuter la suite de tests sur la grille. Si vous n’aimez pas les annotations, vous pouvez utiliser GridJunit3TestSuite au lieu de la simple TestSuite.

C’est censé fonctionner avec JUnit 4 également (GridJunit4Suite) mais j’ai essuyé quelques exceptions m’empêchant d’aller au bout…

Le code et les tests sont envoyés sur chaque nœud automatiquement selon l’algorithme Round Robin. Vous pouvez également réécrire votre méthode de répartition.

Alors bien sûr, ce n’est pas magique et pour distribuer les tests, il faut bien un ou des nœuds sur lesquels les distribuer. Plusieurs possibilités :

Dans un mode simple et un peu artisanal, vous disposez dans le répertoire bin de l’installation de gridgain, d’un fichier gridgain-junit.bat (ou .sh). Lancez le autant de fois que vous souhaitez de nœuds sur une ou plusieurs machines. C’est assez laborieux et si on lance tout sur la même machine, on fini par plomber le temps de test.
Pour pallier à ça, on peut envisager de lancer le script gridgain au démarrage de la machine en tant que service.
Dans un mode un peu plus industrialisé, vous pouvez exploiter des serveurs d’application existants en y installant gridgain. Ainsi, gridgain se lancera en même temps que le serveur d’app et sera prêt à traiter des tests tant que le serveur sera up. Par exemple, j’ai testé l’installation de gridgain dans un JBoss. C’est assez simple à mettre en place et ça fonctionne très bien.

Gridgain peut découvrir les nœuds faisant partie de la grille grâce au mécanisme d’IP multicast. Ça simplifie beaucoup le travail, gridgain se charge de soumettre les paquets et toute machine capable de les recevoir (gridgain installé) se verra remettre des tests à exécuter.

Une fois l’infrastructure prête, plusieurs choses restent à configurer pour exécuter les tests. Et plutôt que de le faire dans Eclipse comme la vidéo d’exemple le montre, je l’ai fait dans Maven (toujours dans l’optique de mon build continu)…

Maven

Dépendances

Avant de rentrer dans les détails techniques, quelques généralités. Tout d’abord, les dépendances de build :

>
	>
		>gridgain>
		>GridGain Repository>
		>http://www.gridgainsystems.com/maven2/>
		>
			>false>
		>
		>
			>true>
		>
	>
>
 
>
	>
		>junit>
		>junit>
		>4.4>
		>test>
	>
	>
		>org.gridgain>
		>gridgain>
		>2.1.1>
		>test>
	>
>

Il faut ajouter le repo gridgain car les dépendances ne sont pour le moment pas dans le repo central.

Compilation 1.5

Compilation en 1.5 pour le support des annotations :

>
	>
		>
			>org.apache.maven.plugins>
			>maven-compiler-plugin>
			>
				>1.5>
				>1.5>
			>
		>
		
	>
>

Exécution de la suite sur la grille

>
	>1.6.4>
>
>
	>
		>
			>org.apache.maven.plugins>
			>maven-surefire-plugin>
			>2.4>
			>
				
				>
					>**/*GridTests.java> 
				>
 
				
				>-javaagent:${project.build.directory}/libs/aspectjweaver-${aspectjweaverversion}.jar> 
				>${project.build.directory}/libs/>
			>
		>
 
		
		>
			>org.apache.maven.plugins>
			>maven-dependency-plugin>
			>
				>
					>copy>
					>process-resources>
					>
						>copy>
					>
					>
						>
							>
								>org.aspectj>
								>aspectjweaver>
								>${aspectjweaver-version}>
								>${project.build.directory}/libs/>
							>
						>
					>
				>
			>
		>
	>
>

Premièrement, j’exclue les tests pour n’ajouter que la ou les suites de tests (effectivement, c’est la suite qui est gridifiée).
Ensuite, on a besoin de préciser le javaagent, en l’occurence aspectj weaver pour instrumenter le code annoté et l’exécuter sur la grille plutôt qu’en local.
Et pour que le javaagent retrouve ses petits, il faut copier le jar dans le répertoire pointé par le javaagent.

Un point important qu’on ne voit pas dans le pom est la présence du META-INF/aop.xml (disponible dans gridgain-x.x.x/config/aop/aspectj/) dans les ressources du projet (src/test/resources). Effectivement ce répertoire doit être dans le classpath. Il permet de sélectionner les portions de code qui seront tissés et donc susceptibles d’être exécutées sur la grille gridgain.

Exécution

Comme je le disais plus haut, il faut utiliser le .bat pour simuler des nœuds ou avoir une vraie grille. Ensuite, depuis votre projet maven, lancez simplement un mvn test -DGRID_ROUTER_PREFER_REMOTE=true

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.octo.gridgain.GridTests
[00:56:01,906][INFO ][main][GridKernal%junit]
  _____      _     _  _____       _
 / ____|    (_)   | |/ ____|     (_)
| |  __ _ __ _  __| | |  __  __ _ _ _ __
| | |_ | '__| |/ _` | | |_ |/ _` | | '_ \
| |__| | |  | | (_| | |__| | (_| | | | | |
 \_____|_|  |_|\__,_|\_____|\__,_|_|_| |_|

...

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Et voilà ! On a un build Maven qui exécute les tests en parallèle sur plusieurs nœuds (dans les logs jboss ou sur la console du bat, vous pouvez voir les tests exécutés par le nœud en question).

Conclusion

Écrire des tests, c’est bien… Les exécuter, c’est mieux ! Et donc si vous avez arrêté de les exécuter car vous êtes perpétuellement en train d’attendre qu’ils soient terminés, gridgain peut vous aider en répartissant l’exécution sur une grille.

Je ne l’ai pas précisé avant mais il va de soit que les tests doivent être le plus unitaires, optimisés et indépendants possibles. Donc dans un premier temps, envisagez d’optimiser vos tests, et si les problèmes persistent, songez à gridgain et gardez en tête que les tests ne doivent pas être dépendants.

Sur l’intégration continue, cela peut également être utile pour alléger la charge sur le serveur. L’idéal serait de pouvoir combiner cette fonctionnalité avec les possibilités de build distribué fournies par les principaux acteurs du marché (Teamcity, Hudson, …) et ainsi lancer les tests sur les agents déjà configurés. Mais pour peu que le réseau soit capable de gérer l’IP Multicast (sur du LAN de préférence), vous devriez déjà pouvoir distribuer les tests sur différents nœuds en laissant Gridgain découvrir les noeuds participants à la grille…

Suggestion d'articles :

FitNesse, Maven, Hudson : pour une intégration continue des tests d’acceptance

Jean-Loup YU — Thu, 15 Oct 2009 09:58:28 +0000

Dans un projet d’entreprise, il est important de vérifier continuellement la non-régression du produit réalisé. Au même titre que les tests unitaires, les tests d’acceptance font partie intégrante du harnais de tests à mettre en place sur un projet. FitNesse est une des solutions à ce besoin.

FitNesse / Slim

FitNesse dormait jusqu’à Juillet 2008. Mais il suffit de voir le rythme des releases depuis cette date, pour se rendre compte qu’il s’est réveillé ! Avec une nouvelle version presque tous les mois entre Juillet 2008 et Juillet 2009, et l’arrivée de Slim, on obtient un produit qui a sensiblement changé.

Mais avec une évolution aussi soudaine, on ne peut malheureusement pas éviter les effets de bords. Notamment dans le monde des outils qui tournaient autour de la sphère FitNesse. Par exemple, je recherchais un plugin Maven pour FitNesse. Mais la plupart des liens que me renvoie mon moteur de recherche préféré, pointe sur des outils incompatibles avec les nouvelles versions de FitNesse.

Il faut creuser un peu avant de trouver les perles rares…

Intégration avec Maven

Classpath generator

Dès qu’on joue un peu avec FitNesse, on se rend vite compte que la gestion du classpath est une vraie galère ! L’écriture manuelle n’est pas une solution envisageable lorsque le projet embarque plus d’une dizaine de dépendances. Et puis après tout c’est le rôle de Maven de gérer tout ça !

C’est là qu’entre en jeu le superbe plugin Classpath generator.

Compatible avec la dernière version de FitNesse (20090818), il permet de générer automatiquement la liste des dépendances des fixtures décrites dans le pom, directement dans le wiki.

Pour savoir comment configurer le plugin et comment l’utiliser, il suffit de suivre ce lien.
Attention, la page dans laquelle vous souhaitez générer le classpath doit être de type « Suite ».

Trinidad

L’étape suivante consiste à intégrer l’exécution automatique des tests d’acceptance dans le processus de build du projet. Pour cela, il existe le plugin Maven nommé Trinidad. Nous nous concentrons ici uniquement sur l’aspect exécution des tests FitNesse dans Maven, sachant que le plugin permet de faire bien plus que ça.

Pour cela, je vous décris dans la suite comment j’ai configuré et utilisé le plugin.

Configuration du pom.xml du projet contenant les fixtures :

Ajout de la dépendance :

 
   
     
      neuri-maven 
      http://maven.neuri.com/ 
       
        true 
       
      
        true 
      
     
   
  
     
      com.neuri.tdd 
      fitnesserunner 
      20090818

Configuration du plugin :


  
    
      
        maven-trinidad-plugin
        20090818
        
          
            test 
            
              run-tests
             
          
        
        
          slim 
          fitnesse
          C:\Programs\fitnesse 
          true 
           
            MyProject.MyTestSuite 
           
        
       
     
   
   
     
      neuri-maven 
      http://maven.neuri.com/ 
       
        true 
       
       
        true

Ainsi configuré, tous les tests FitNesse inclus dans la suite « MyTestSuite » seront exécutés lors du lancement de la phase test de Maven.

Le paramètre « breakBuildOnFailure » permet comme son nom l’indique de casser le build en cas d’échec sur les tests d’acceptance. Par défaut, le paramètre est à false.

Hudson

L’usine d’intégration continue est une brique logiciel essentielle dans un projet agile. Il garantit l’intégrité de l’application construite au fil de l’eau. Hudson est un des outils les plus répandus. Intégrer les tests d’acceptance dans l’usine d’intégration continue participe donc à construire un logiciel de qualité.

Par contre, on est en droit de se demander s’il est indispensable d’exécuter les tests d’acceptance à chaque fois que l’application est construite (c’est-à-dire à chaque commit d’un développeur). En effet, les tests FitNesse sont souvent longs à exécuter, et les jouer à chaque fois peut parfois nuire à la productivité de l’équipe. Un bon compromis est de lancer le build des tests d’acceptance toutes les nuits.

Voici comment j’ai configuré le job Hudson qui exécute les tests FitNesse tous les jours à minuit:

Malgré une version stable depuis Août 2009, FitNesse peut être amené à évoluer dans quelques mois. Cet article se base sur la version 20090818. Les outils présentés ont été testés sur cette version. Il n’est pas garantit qu’ils fonctionneront toujours avec les versions futures de FitNesse.

Suggestion d'articles :

Trois pistes pour distribuer vos builds

Meriem Berkane — Mon, 05 Oct 2009 08:00:00 +0000

L’objectif du build continu est de fournir aux développeurs un retour sur la qualité du code qu’ils viennent de commiter. Plus ce retour sera fait rapidement, plus il sera efficace. Dans leur présentation à l’Université du Système d’Information intitulée Les nouveaux défis de l’intégration continue, Jérôme Van Der Linden et Philippe Guicheney présentent le build distribué comme une solution aux problématiques de temps de build continu. Le but de cet article est d’approfondir cette notion de build distribué, en:

Présentant trois concepts de distribution du build
Positionnant les principaux outils d’intégration continue actuels par rapport à leurs implémentations du build distribué

Dans tout ce qui suivra, on rencontrera à plusieurs reprises les termes suivants :

Build : Une configuration sur l’outil d’intégration continue servant à construire un projet, à générer sa documentation, à générer des rapports de qualité, etc. Un build peut effectuer une ou plusieurs de ces étapes.
Agent : Un serveur d’intégration continue secondaire ou esclave du principal. Il reçoit des ordres de build du serveur principal, et se synchronise avec ce dernier à la fin de l’exécution de ces ordres

On peut distinguer plusieurs concepts de distribution des builds d’intégration continue.

Distribuer les builds

Ici, le principe est simple : des agents installés sur d’autres serveurs prennent à leur charge certains builds et fournissent le résultat au serveur principal. Un build constitue ici un élément atomique, et se déroule sur un seul agent :

Les builds sont répartis sur les différents agents selon une politique de distribution prédéfinie, dépendant des outils d’intégration continue. Hudson , Teamcity et Bamboo proposent un mode de distribution manuel, où l’on associe explicitement un job à un agent.

Si aucune assignation manuelle n’est faite:

Hudson fera en sorte que tous les builds les plus longs (en se basant sur les dernières durées) soit exécutés sur des agents et non sur le serveur principal. Il fera également en sorte que chacun de ces builds soit exécuté sur l’agent où il a été exécuté la dernière fois.
Teamcity et Bamboo détermineront l’ agent libre en premier en se basant sur les anciens temps de build. Ils ajouteront le build sur la file d’ attente de ce dernier.

L’intérêt de ce type de distribution n’est pas simplement d’optimiser le temps de lancement d’un build. Il permet aussi de faire ce que l’on appelle du build profilé, où les agents ne sont pas tous configurés de la même façon afin de tester l’application sur différentes plateformes (Systèmes d’exploitations, serveurs d’application,etc.).

Distribuer les modules d’un même build

Il s’agit ici de répartir un même build sur plusieurs agents. Imaginons par exemple le projet maven suivant. Ce projet est composé de trois modules (au sens maven) : A, B et C. Les dépendances suivent le schéma suivant :

A doit être buildé avant B et C, en revanche B et C peuvent être buildés simultanément. On pourrait imaginer que B et C soient buildés sur des agents séparés.
Ceci est manuellement faisable avec Maven. En effet, il est possible de déduire l’arbre des dépendances, de builder le projet parent séparément grâce à l’option non-recursive de maven (-N), puis de lancer des builds de chaque module d’une façon isolée des autres, et ce grâce à l’option projects de maven (-pl).

Une telle possibilité n’est pas encore exploitée par les solutions d’intégration continue actuelles. Mais, comme les outils d’intégration continue proposent des builds de type maven2, nous imaginons que ce genre de fonctionnalités va arriver prochainement.

D’ailleurs, Hudson par exemple, pour offrir sa fonctionnalité de build incrémental, effectue déjà lors d’un build la détection des modules maven, ainsi que l’ordre de build. Cette fonctionnalité permet de ne builder que les modules qui ont changé.

Distribuer les tests

Il s’agit ici de distribuer les tests d’ un même module sur plusieurs agents différents. Dans son post intitulé Combien de temps doit prendre un build maven , Benoit Lafontaine explique qu’un build doit prendre au maximum 30 secondes + le temps d’ exécution des tests. Distribuer les tests permet donc de réduire de manière considérable le temps de build.

Quelques frameworks de tests unitaires comme TestNG proposent aujourd’hui de distribuer les tests sur plusieurs agents. TestNG est déjà supporté par Teamcity et Hudson.

Gridgain est un framework open source pour développer des applications java en grille ou sur le cloud. Depuis la version 1.6, gridgain permet également de distribuer des tests JUnit et grâce à une simple annotation (@GridifyTest), vous pouvez distribuer une suite de tests sur les noeuds de la grille Gridgain (un prochain article approfondira ce sujet).

La distribution des tests sur plusieurs agents n’est pas encore implémentée. Un premier pas de l’implémentation de ce type de distribution serait de déclarer les agents d’une façon explicite dans les fichiers de configuration de TestNG ou de Gridgain. Mais nous pouvons imaginer aussi qu’un jour nous aurons une détection automatique des agents disponibles et une configuration à la volée de ces derniers dans les fichiers de configuration Gridgain et TestNG.

Conclusion

Le build distribué doit être une fonctionnalité à prendre en compte dans le choix d’une solution d’intégration continue. Et si le premier concept de distribution est dès aujourd’hui aisé à mettre en oeuvre, car déjà implémenté par la plupart des outils, les deux autres restent encore inexploités, et constituent à n’en pas douter une évolution majeure de l’intégration continue.

Suggestion d'articles :

Littérature Maven Française

Jérôme Van Der Linden — Wed, 30 Sep 2009 05:18:17 +0000

Jusqu’à présent la littérature au sujet de Maven était essentiellement anglophone. Ceci limitait son adoption dans nos contrées gauloises et pouvait parfois entrainer une mauvaise utilisation ou des critiques injustifiées. Mais c’est aujourd’hui de l’histoire ancienne… ou presque ! Effectivement, d’ici la fin de l’année, deux ouvrages en Français arriveront sur nos étales : Apache Maven de Nicolas De Loof et Arnaud Héritier ainsi que la traduction du déjà connu Maven: The Definitive Guide de Sonatype.

Apache Maven

Ce livre devrait paraître en Novembre (si tout se passe bien, le 20) et devrait ravir tous ceux qui n’avaient pas la motivation et l’envie de se lancer dans le guide de référence. Pour avoir participé à sa relecture, je ne peux que vous le conseiller, il se boit comme du petit lait. Au travers d’un roman bien conté, on y apprend à utiliser Maven comme en entreprise. Depuis la création du projet jusqu’à la livraison, on découvre les clés pour mener à bien un projet et se faire de Maven un allié.
N’y cherchez pas un guide de référence, ce n’est pas le but. Mais par contre, si vous débutez ou que vous souhaitez des tips, n’hésitez pas. Qui mieux que deux commiteurs Maven ayant mis en place Maven dans les entreprises Françaises pourrait mieux vous livrer ces informations ?!
Plus de détails ici…

Maven: The Definitive Guilde

À défaut de l’avoir lu, vous avez déjà probablement entendu parlé du Definitive Guide Maven, le livre de référence Maven édité par Sonatype. Et bien si vous aviez peur de vous lancer dans la lecture de ce pavé en anglais, sachez que la traduction française est actuellement en cours.
Nous sommes aujourd’hui 4 à traduire ce « Guide Absolu ». La première partie étant terminée, nous vous invitons à une campagne de relecture des 8 premiers chapitres. Vous trouverez le pdf ou la version html (en intégration continue) sur http://maven-definitive-guide.fr/.
Pour toutes vos remarques, utilisez notre projet github. Comme pour la version originale, c’est grâce à la communauté de développeurs et utilisateurs Maven, que nous aurons un bon livre alors n’hésitez pas !

Suggestion d'articles :

Combien de temps doit prendre un build Maven ?

Benoit Lafontaine — Mon, 14 Sep 2009 07:00:04 +0000

Suite à mon précédent post, La meilleure façon de rater son projet grâce à Maven2, un collègue m’a décrit la situation suivante « Une pratique sur notre projet est de lancer un build maven -mvn clean install- sur son poste local avant de faire un commit. Cette commande est super longue, et les développeurs disent ‘c’est normal c’est maven qui est long’, ça doit prendre combien de temps un build Maven ? ».

Avant de répondre, je répète mon précédent conseil : fixez votre environnement pour que vous soyez confiants dans votre code sans avoir à lancer un build maven.

Combien de temps doit prendre un build Maven ?

En testant les projets que j’ai sous la main, des petits projets de quelques modules Maven à des projets de plus de 100 modules Maven, j’en viens à la conclusion :
temps de build Maven = temps des tests unitaires + 30s
(pour le projet de 100 modules, on dépasse de peu la minute supplémentaire).

Au final, le temps de build imputable à Maven est de l’ordre de 30 secondes voire 1 minute. Une différence de plus d’une minute est une alerte : le build est mal configuré.
A ce propos, selon Arnaud Héritier (membre du Project Management Committee sur Maven2) :

Le gros Kouak dans Maven c’est à l’initialisation la résolution de toutes les dépendances (le parcours du graphes etc).
Plus il y a des sous-modules, plus il y a de choses a faire.
En Maven 2.0.x les temps sont catastrophiques.
Ainsi un projet qui compte plus de 150 modules Maven peut prendre 8 minutes à s’initialiser.
Sur un autre projet, qui a aussi quelques dizaines de modules cela prend entre 1 et 2 minutes.
A partir de la version 2.1.0 le premier projet met moins d’une minute à s’initialiser et le deuxième ne met plus que quelques secondes.

Si vous êtes encore sur Maven 2.0.x et que votre build met plusieurs minutes à s’initialiser, je vous conseille d’essayer les dernières versions de Maven.

Pensez aussi à bien distinguer les étapes nécessaires lors d’un build développeurs et celles qu’on peut garder que sur l’intégration continue et à les séparer dans des profils différents. Typiquement, si l’on pré-compile des JSPs pour les environnements d’intégration et de production, cette tâche n’est pas utile lors des développements.

Maintenant, j’entends déjà la question suivante :

Mes tests unitaires prennent plusieurs minutes, comment je fais ?

Si vos tests unitaires prennent trop de temps, c’est surement que vous ne faites pas des tests unitaires, mais plutôt des tests d’intégration. Pour mieux comprendre la distinction : un article sur les types de tests.
Mon conseil n’est pas d’abandonner les tests d’intégration, bien au contraire, mais de ne pas les lancer systématiquement :

Tests unitaires : très rapides, lancés systématiquement sur le poste de développement
Tests d’intégration : potentiellement longs, lancés systématiquement par l’intégration continue, le développeur ne lance que ceux qu’il juge nécessaire

En résumé :

Le temps d’un build Maven doit être le temps de vos tests unitaires plus 30 secondes maximum

Ne conservez que le strict minimum dans le build « courant » et déléguez les tâches plus longues à l’intégration continue

Distinguez les tests unitaires des tests d’intégration, ces derniers seront joués régulièrement par l’intégration continue et à la demande sur les postes de développement

Suggestion d'articles :