A première vue, l’écran de configuration d’une tâche de build Maven 2/3 est très similaire à celle que nous avions vu pour les tâches de build dans la section précédente. La première différence que vous pouvez noter est dans la section Déclencheurs de build. Dans cette section, une option supplémentaire est disponible « Lance un build à chaque fois qu'une dépendance SNAPSHOT est construite ». Si vous sélectionnez cette option, Jenkins examinera votre fichier pom.xml (ou les fichiers)pour regarder si aucunes dépendances SNAPSHOT sont en train d’être construire par d’autres tâches de build. Si n’importe laquelle des tâches de build met à jour une dépendance SNAPSHOT que votre projet utilise, Jenkins construira aussi votre projet.

Typiquement dans Maven, les dépendances SNAPSHOT sont utilisées pour partager la toute dernière version d’une librairie avec d’autres projets de la même équipe. Comme elles sont par définition instables, ce n’est pas une pratique recommandée de lier des dépendances SNAPSHOT avec d’autres équipes ou depuis des sources externes.

Par exemple, imaginiez que vous êtes en train de travailler sur une nouvelle application web game-of-life. Vous utilisez Maven pour votre projet, donc vous pouvez utiliser une tâche de build Maven dans Jenkins. Votre équipe travaille aussi sur une librairie réutilisable appelée cooltools. Comme ces deux projets sont développés par la même équipe, vous utilisez certaines des dernières fonctionnalités de cooltools dans l’application game-of-life. vous avez une dépendance SNAPSHOT dans la section <dependencies> du fichier pom.xml de game-of-life :

    <dependencies>
        <dependency>
            <groupId>com.acme.common</groupId>
            <artifactId>cooltools</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <scope>test</scope>
        </dependency>
        ...
    </dependencies>

Dans votre serveur Jenkins, vous avez configuré des tâches de build Maven à la fois pour l’application cooltools et game-of-life. Comme votre projet game-of-life a besoin de la dernière version SNAPSHOT de cooltools, vous cochez l’option « Lance un build à chaque fois qu'une dépendance SNAPSHOT est construite ». Comme cela, dès lors que le projet cooltools est reconstruit, le projet game-of-life sera aussi automatiquement reconstruit.

La prochaine section où vous noterez un changement est la section Build. Dans une tâche de build Maven, la section Build est entièrement dévoué au lancement d’un seul goal Maven (voir la figure Figure 5.38, “Spécifier les goals Maven”). Dans cette section, vous spécifiez la version de Maven que vous voulez exécuter (rappelez-vous, en tant que job Maven, cela ne fonctionnera qu’avec Maven), la position du fichier pom.xml, et le goal Maven (ou les goals) à invoquer. Vous pouvez aussi ajouter n’importe quelles options de ligne de commande que vous voulez ici.

Dans beaucoup de cas, c’est tout ce que vous aurez besoin de faire pour configurer une tâche de build Maven. Cependant, si vous cliques sur le bouton « Avancé… », vous pouvez cocher certaines fonctionnalités avancées (Figure 5.39, “Les tâches de build Maven — les options avancées”).

L’option de build incrémental est très pratique pour les grands builds multi modules Maven. Si vous cochez cette option, lorsqu’un changement est effectué sur l’un des modules du projet, Jenkins reconstruira uniquement ce module et les modules qui utilisent le module modifié. Il fait cette magie en utilisant certaines nouvelles fonctionnalités introduites par Maven 2.1 (donc cela ne fonctionnera pas si vous utilisez Maven 2.0.x). Jenkins détecte quels modules a été modifiés, et utilise l’option -pl (--project-list) pour construire uniquement les modules mis à jour, et l’option -amd (--also-make-dependents) pour construire aussi les modules qui utilises les modules mis à jour. Si rien n’a été modifié dans le code source, tous les modules sont construits.

Par défault, Jenkins archivera tous les artefacts générés par une tâche de build Maven. Cela peut être utile à certains moments, mais cela peut aussi être très coûteux en place sur le disque. Si vous souhaitez désactiver cette option, il suffit de cocher l’option « Désactive l’archivage automatique des artefacts ». Alternativement, vous pouvez toujours limiter les artefacts stockés en utilisant l’option « Supprimer les anciens builds» tout en haut de la page de configuration.

L’option « Construire les modules en parallèle » informe Jenkins qu’il peut démarrer chaque module individuellement en parallèle comme un build séparé. En théorie, cela pourrait rendre un peu plus rapide les constructions. En pratique, cela fonctionnera réellement si vos modules sont totalement indépendants (si vous n’utilisez pas d’agrégation), ce qui est rarement le cas. Si vous pensez que construire vos modules en parallèle peut réellement accélérer votre projet multi module, vous pouvez avoir envie d’utiliser un build freestyle avec Maven 3 et sa nouvelle fonctionnalité de construction parallèle.

Une autre option utile est « Utiliser une repository Maven privé ». Normalement, lorsque Jenkins démarre Maven, il se comportera exactement de la même manière que Maven en ligne de commande : il stockera les artefacts et retrouvera les artefacts depuis le dépôt Maven local (dans ~/.m2/repository si vous ne l’avez pas configuré dans le fichier settings.xml). Ceci est efficient en terme d’espace disque, mais pas souvent idéal pour des constructions en IC. En effet, si plusieurs tâches de build sont en construction avec les mêmes artefacts en SNAPSHOT, les constructions peuvent finir par se gêner les unes avec les autres.

Lorsque cette option est sélectionnée, Jenkins demande à Maven d’utiliser $WORKSPACE/.repositorycomme dépôt local Maven. Cela signifie que chaque job aura son propre dépôt Maven isolé pour lui tout seul. Cela règle les problèmes ci-dessus, au détriment de la consommation d'espace disque supplémentaire.

Avec cette option, Maven utilisera un dépôt Maven dédié pour cette tâche de build, situé dans le répertoire $WORKSPACE/.repository . Ceci prend plous d’espace disque, mais garantie une meilleur isolation pour nos tâches de build.

Une autre approche pour ce problème est de redéfinir l’emplacement par défaut du dépôt en utilisant la propriété maven.repo.local, comme montré ici :

$ mvn install -Dmaven.repo.local=~/.m2/staging-repository

Cette approche à l’avantage d’être capable de partager un dépôt entre certaines tâches de builds, ce qui est utile si vous souhaitez faire une série de builds liés. Cela fonctionnera aussi avec des tâches Freestyle.

Les actions à la suite du build dans une tâche de build Maven est considérablement simple à configurer comparé à une tâche Freestyle. C’est simplement parce que, puisque c’est un build Maven, Jenkins sait où chercher un certain nombre de sortie du build. Les artefacts, rapports de test, Javadoc, en ainsi de suite, sont tous générés dans les répertoires standards, ce qui signifie que vous n’avez pas besoin de préciser à Jenkins où trouver ces éléments. Donc Jenkins trouvera, et effectuera automatiquement des rapports sur des résultats de test JUnit, par exemple. Plus loin dans ce livre, nous verrons comment les projets Maven simplifient aussi la configuration de beaucoup d’outils de mesure de qualité de code et de rapports.

Beaucoup des autres actions à la suite du build sont similaires à ceux que nous avons vus dans une tâche de build Freestyle.

Une option supplémentaire qui apparait dans les tâches de build Maven est la capacité de déployer vos artefacts vers un dépôt Maven (voir la figure Figure 5.40, “Déployer des artefacts vers un dépôt Maven”). Un gestionnaire de dépôt d’entreprise est un serveur qui agit à la fois comme un proxy/cache pour des artefacts publics de Maven, et comme un serveur de stockage centralisé pour vos propres artefacts internes. Des gestionnaires de dépôt d’entreprise open source comme Nexus (de Sonatype) et Artifactory (de JFrog) fournissent des fonctionnalités de maintenance et d’administration puissantes qui permettent de configurer et maintenir vos dépôts Maven très simplement. Ces deux produits ont des versions commerciales, avec des fonctionnalités additionnelles visant à construire des infrastructures plus sophistiquées ou haut de gamme.

L’avantage d’avoir Jenkins qui déploie vos artefacts (à l’opposé de simplement faire mvn deploy) est que, si vous avez un build Maven multi module, les artefacts seront déployés uniquement lorsque le build entier a fini avec succès. Par exemple, supposons que vous ayez un projet Maven multi module avec cinq modules. Si vous lancez mvn deploy, et que le build échoue après trois modules, les deux premiers modules vont avoir été déployés vers votre dépôt, mais pas les trois premiers, qui laissent votre dépôt dans un état instable. Faire en sorte que Jenkins faire le déploiement assure que les artefacts sont déployés comme un groupe une fois que le build a terminé avec succès.

Pour faire cela, il suffit de cocher l’option « Déployer les artefacts dans le repository Maven » dans les actions à la suite du build. Vous aurez besoin de spécifier l’URL du dépôt sur lequel vous voulez déployer. Il faut que cela soit l’URL complète vers le dépôt (ex : http://nexus.acme.com/nexus/content/repositories/snapshots, et pas juste http://nexus.acme.com/nexus)

La plupart des dépôts ont besoin de vous authentifier avant de vous laisser déployer des artefacts. La manière standard de Maven pour faire cela est de placer <server> dans votre fichier settings.xml local, comme montré ici :

<settings...>
  <servers>
    <server>
      <id>nexus-snapshots</id>
      <username>scott</username>
      <password>tiger</password>
    </server>
    <server>
      <id>nexus-releases</id>
      <username>scott</username>
      <password>tiger</password>
    </server>
  </servers>
</settings>

Pour les personnes qui souhaitent plus de sécurité, vous pouvez aussi encrypter ces mots de passe si besoin est.

Ensuite, entrez l’identifiant correspondant dans le champ Identifiant du repository de Jenkins. Jenkins sera alors capable de retrouver le bon nom d’utilisateur et mot de passe, et de déployer vos artefacts. Une fois que le build sera terminé, vos artefacts devraient être disponibles sur votre dépôt d’entreprise Maven (voir la figure Figure 5.41, “Après déploiement, l’artefact devrait être disponible sur votre gestionnaire de dépôt d’entreprise”).

En utilisant cette option, vous n’avez pas toujours besoin de déployer tout de suite — vous pouvez toujours revenir en arrière et redéployer des artefacts d’une version précédente. Il suffit de cliquer sur le menu « Redéployer les artefacts » à gauche et spécifier l’URL du dépôt sur lequel vous voulez redéployer votre artefact (voir la figure Figure 5.42, “Redéployer un artefact”). Comme dans l’exemple précédent, le bouton Avancé vous permet de spécifier l’identifiant pour le tag <server>dans votre fichier settings.xml local. Comme vous pourrez voir plus loin dans ce livre, vous pour aussi utiliser ce déploiement dans le cadre d’un processus de promotion de buid en configurant un déploiement automatique vers un dépôt différent lorsque certaines métriques de qualité sont satisfaites, par exemple.

Cette approche fonctionnera bien pour n’importe quel gestionnaire de dépôt d’entreprise. Cependant, si vous utilisez Artifactory, vous pourriez préférer installer le plugin Artifactory de Jenkins, qui fournit une intégration bidirectionnelle vers le gestionnaire de dépôt d’entreprise Artifactory. Il fonctionne en envoyant des informations supplémentaires au serveur Artifactory durant le déploiement, permettant au serveur d’avoir un lien vers le build qui a généré un artefact donné. Une fois que vous avez installé le plugin, vous pouvez l’activer dans votre tâche de build Maven en cochant l’option « Deploy artifacts to Artifactory » dans les actions à la suite du build. Ensuite vous choisissez sur quel dépôt votre projet doit déployer dans une liste de dépôt sur le serveur, avec le nom d’utilisateur et le mot de passe requis pour faire le déploiement (voir la figure Figure 5.43, “Déployer vers Artifactory depuis Jenkins”).

Votre tâche de build déploiera automatiquement vers Artifactory. En supplément, un lien vers l’artefact sur le serveur sera maintenant affiché sur la page d’accueil de la tâche de build et la page de résultat des builds (voir la figure Figure 5.44, “Jenkins affiche un lien vers le dépôt Artifactory correspondant”).

Ce lien vous emmène sur une page sur le serveur Artifactory contenant les artefacts déployés (voir la figure Figure 5.45, “Voir l’artefact déployé sur Artifactory”). Depuis cette page, il y a aussi un lien pour vous ramener vers la page du build qui a construit cet artefact.

Un gestionnaire de dépôt d’entreprise est une partie essentielle de n’importe quelle infrastructure de développement de logiciel basé sur Maven. Ils jouent aussi un rôle clé pour les projets non basés sur Maven utilisant des outils tels que Ivy ou Gradle, chacun d’eux étant liés aux dépôts standards de Maven.

Chacun des principaux gestionnaires de dépôt d’entreprise, Nexus and Artifactory, propose des versions professionnelles qui fournissent des fonctionnalités supplémentaires avec Jenkins. Plus loin dans ce livre, nous discuterons comment vous pouvez utiliser des fonctionnalités avancées comme la gestion de release et de staging de Nexus Pro pour implémenter des stratégies sophistiquées de promotion de build. Sur l’aspect déploiement, l’édition commerciale d’Artifactory (Artifactory Pro Power Pack) étend l’intégration bidirectionnelle que nous avons vu plus tôt. Lorsque vous voyez un artefact sur le navigateur du dépôt, un onglet ‘Builds’ affiche les détails sur le build Jenkins Jenkins qui a créé l’artefact, et un lien vers la page du build sur Jenkins (voir la figure Figure 5.46, “Voir les artefacts déployés et le build Jenkins correspondant dans Artifactory”). Artifactory assure également le suivi des dépendances qui ont été utilisées dans le build Jenkins, et vous alertera si vous essayez de les supprimer depuis le dépôt.

Lorsque vous utilisez Maven, il est habituel de découper le projet en plusieurs modules. Les tâches de build Maven ont un connaissance intrinsèque des projets multi modules, et ajoute un élément Modules au menu qui vous permet d’afficher la structure du projet d’un coup d’œil (voir la figure Figure 5.47, “Gérer les modules dans une tâche de build Maven”).

Cliquer sur l’un des modules vous permettra d’afficher la page de build pour ce module. A partir de la, vous pouvez voir les résultats détaillés des builds pour chaque module, déclencher un build pour un module isolé, et si nécessaire, affiner la configuration d’un module, surchargeant ainsi la configuration global du projet.

Par Par défaut, une tâche de build Maven ne permet qu’un seul goal Maven. Il y a des fois ou c’est assez limitatif, et vous voudriez ajouter des étapes supplémentaires avant ou après la build principal. Vous pouvez faire ceci avec le plugin M2 Extra Steps de Jenkins. Ce plugin vous permet d’ajouter des étapes de builds normales avant et après le goal Maven principal, vous donnant la flexibilité d’une tâche de build Freestyle tout en gardant l’avantage de la configuration d’une tâche de build Maven.

Installez le plugin et allez dans la section Environnements de Build de votre tâche de build. Cochez l’option « Configure M2 Extra Build Steps ». Vous devriez pouvoir maintenant ajouter des étapes de build qui seront ajoutées avant et/ou après que votre goal Maven principal soit exécuté (voir la figure Figure 5.48, “Configurer des étapes de build Maven supplémentaires”).