Combien de temps doit prendre un build Maven ?

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

Mots-clés: , ,

4 commentaires pour “Combien de temps doit prendre un build Maven ?”

  1. Article très pertinent.

    J’ajouterais juste la notion de build incrémental dans des projets multi-modules pour éviter la reconstruction systématique de tous les modules alors qu’un seul a changé.

    Fonctionnalité disponible via le plugin ‘reactor’ ou en natif à partir de Maven 2.1.0.

    Sylvain FRANCOIS
    Kalistick

  2. C’est exact. J’en avais rapidement parlé sur mon blog (http://blog.aheritier.net/les-nouveautes-de-maven-210/). Dernièrement Hudson a rajouté le support du build incrémental. ainsi le serveur d’intégration continue regarde quels modules ont été modifiés et ne rebuild que ces derniers avec ceux qui en dépendent.
    La seule chose que je ne sais pas optimiser aujourd’hui et qu’au mieux je rend optionnel si possible c’est le packaging. Selon la taille des archives (war, ears, ..) cela peut consommer bcp de temps proportionnellement au reste du build. Il est donc important (pour ne pas dire vital) d’avoir une machine (que cela soit le poste de dev ou le serveur d’intégration continue) avec un disque dur ultra performant.

  3. Eh beh je suis bien loin des 30 s !! Dans mon cas il y a 2 causes évidentes.
    Le packaging, comme dit Arnaud, en est une.
    L’autre c’est l’utilisation de plugins de génération de code (hbm2java, wsdl2java) au fond de l’arbre de dépendances entre modules. C’est tout de suite beaucoup moins incrémental… et difficile à contourner sans revoir pas mal de choses. Mais l’investissement en vaut peut-être la peine !

  4. Oui je suis d’accord que la génération de code c’est aussi un problème. Je me demande l’intérêt de les lancer systématiquement notamment pour du wsdl2java on ne change pas le wsdl toutes les deux minutes. Dans ce cas je me demande si ce module ne devrait pas être un projet à part entière puisque son cycle de vie est celui du WSDL et peut donc être indépendant des applications consommatrices/productrices. Ensuite c’est le livrable de ce projet qui serait versionné et utilisé par les applications. La maintenance de ce projet est à la charge de l’application productrice.

Laissez un commentaire