Une part importante de tout pipeline de build est d'avoir une stratégie de release bien définie. Ceci implique, entre autres choses, de dédier comment et quand lancer une nouvelle release, et comment l'identifier avec un libellé unique ou numéro de version. Si vous travaillez avec des projets Maven, utiliser le plugin Maven Release pour gérer les numéros de versions est une pratique hautement recommandée.

Les projets Maven utilisent des numéros de version bien définis et bien structurés. Un numéro de version typique est composé de trois digits (e.g., “1.0.1”). Les développeurs travaillent sur des versions SNAPSHOT (e.g.,“1.0.1-SNAPSHOT”), qui, comme son nom l'indique, n'est pas conçu pour être définitif. Les releases définitives (e.g., “1.0.1”) sont construites une seule fois et déployées dans le dépôt local d'entreprise (ou le dépôt central Maven pour les bibliothèques opensource), où elles peuvent à leur tour être utilisées par d'autres projets. Les numéros de version utilisés dans des artefacts Maven sont une part critique du système de gestion de dépendances Maven, et il est fortement conseillé de respecter les conventions Maven.

Le plugin Maven Release aide à automatiser le processus de mise à jour des numéros de version Maven de vos projets. En résumé, cela vérifie, construit et teste votre application, monte les numéros de version, met à jour votre système de contrôle de versions avec les tags appropriés, et déploie les versions de release de vos artefacts dans votre dépôt Maven. C'est une tâche fastidieuse à faire manuellement, le plugin Maven Release est donc un excellent moyen d'automatiser les choses.

Toutefois, le plugin Maven Release peut aussi être capricieux. Des fichiers locaux non-archivés ou modifiés peuvent faire échouer le processus, par exemple. Le processus est aussi consommateur en temps et consomme intensivement le CPU, plus spécialement pour les gros projets : cela construit et exécute entièrement l'ensemble de tests unitaires et d'intégration plusieurs fois, récupère une copie propre du code depuis le dépôt, et envoie plusieurs artefacts au dépôt d'entreprise. Concrètement, ce n'est pas le genre de chose que vous voulez exécuter sur une machine de développeur.

Il est donc de bon ton d'exécuter ce processus sur votre serveur de build.

Une façon de faire cela est de configurer une tâche manuelle de build spéciale invoquant le plugin Maven Release. Toutefois, le plugin M2Release propose une approche plus simple. En utilisant ce plugin, vous pouvez ajouter la possibilité de construire une version de release Maven à une tâche existante. Vous pouvez ainsi éviter de dupliquer des tâches de builds inutilement, facilitant par la même la maintenance du serveur.

Une fois ce plugin installé, vous pouvez configurer toute tâche de build pour qu'elle propose une étape manuelle de release Maven. Ceci s'effectue en cochant la case “Maven release build” dans la section Environnement de Build (voir Figure 10.36, “Configurer une release Maven en utilisant le plugin M2Release”). Ici, vous définissez les goals que vous voulez exécuter pour le build (typiquement release:prepare release:perform).

Lorsque ceci est configuré, vous pouvez déclencher manuellement une release Maven en utilisant une nouvelle option de menu appelée “Perform Maven Release” (voir Figure 10.37, “L'option de menu Perform Maven Release”).

Cela déclenchera une tâche de build spéciale utilisant les goals que vous avez fournis dans la configuration du plugin (voir Figure 10.38, “Effectuer une release Maven dans Jenkins”). Jenkins vous offre le choix d'utiliser soit les numéros de version par défaut fournis par Maven (par exemple, la version 1.0.1-SNAPSHOT sera livrée avec la version 1.0.1, et le numéro de version en développement sera positionnée à 1.0.2-SNAPSHOT), soit de fournir vos propres numéros de version personnalisés. Si, par exemple, vous voulez livrer une version majeure vous pourriez décider de spécifier manuellement 1.1.0 comme numéro de version et 1.1.1-SNAPSHOT comme prochain numéro de version de développement.

Si vous avez un projet multimodule Maven, vous pouvez choisir une configuration de numéro de version unique pour tous les modules, ou de fournir une mise à jour de numéro de version différente pour chaque module. Notez que ce n'est généralement pas une pratique recommandée que de fournir des numéros de version différents pour différents modules dans un projet multimodule.

En fonction de votre configuration SCM, vous pourriez aussi avoir besoin de fournir un nom d'utilisateur et un mot de passe valide pour permettre à Maven de créer les tags dans votre dépôt de code source.

L'édition professionnelle du Dépôt d'Entreprise Nexus fournit une fonctionnalité appelée Staging Repositories, qui permet de déployer des artefacts dans un espace spécial de staging afin de faire davantage de tests avant de les livrer officiellement. Si vous utilisez cette fonctionnalité, vous devez paramétrer plus finement votre configuration de serveur de build pour de meilleurs résultats.

Nexus Professional travaille en créant un nouvel espace de staging pour chaque adresse IP unique, utilisateur de déploiement et User-Agent HTTP. Une machine de build Jenkins donnée aura toujours la même adresse IP et le même utilisateur. Toutefois, vous voudrez typiquement avoir un espace de staging séparé pour chaque build. L'astuce est alors de configurer Maven pour qu'il utilise une chaîne de User-Agent HTTP unique pour le processus de déploiement. Vous pouvez le faire en configurant le fichier settings.xml sur votre serveur de build afin qu'il contienne quelque chose dans le genre des lignes suivantes (l'ID doit correspondre à l'ID du dépôt de release de la section deployment de votre projet) :

 <server>
    <id>nexus</id>
    <username>my_login</username>
    <password>my_password</password>
    <configuration>
      <httpHeaders>
        <property>
          <name>User-Agent</name>
          <value>Maven m2Release (java:25.66-b01 ${env.BUILD_TAG }</value>
        </property>
      </httpHeaders>
    </configuration>
  </server>

Pendant un processus de build impliquant plusieurs tâches de build, comme celle illustrée dans Figure 10.33, “Un graphe de dépendance de tâche de build plus compliqué”, il peut parfois être utile de réutiliser des artefacts produits par un build dans une tâche de build ultérieure. Par exemple, vous pourriez vouloir exécuter une série de tests web en parallèles sur des machines séparées, en utilisant des serveurs d'application locaux pour améliorer les performances. Dans ce cas, il est normal de récupérer le binaire exact qui a été produit dans le build précédent, plutôt que de le reconstruire chaque fois ou, si vous utilisez Maven, de reposer sur un build SNAPSHOT déployé dans le dépôt d'entreprise. En effet, ces deux approches pourraient vous faire courir le risque de résultats de build incohérent : si vous utilisez une SNAPSHOT d'un dépôt d'entreprise, par exemple, vous utiliserez le dernier build SNAPSHOT, qui pourrait ne pas nécessairement être celui construit dans la tâche de build amont.

Le plugin Copy Artifact vous permet de copier des artefacts d'un build amont et de les réutiliser dans votre build courant. Une fois que vous avez installé ce plugin et redémarré Jenkins, vous pourrez ajouter une nouvelle étape de build appelée “Copier des artefacts d'un autre projet” à vos tâches de build freestyle (voir Figure 10.39, “Ajouter une étape de build “Copier des artefacts d'un autre projet””).

Cette nouvelle étape de build vous permet de copier des artefacts d'un projet dans l'espace de travail du projet courant. Vous pouvez spécifier n'importe quel autre projet, bien que ce sera typiquement l'une des tâches de build amont. Et bien sûr vous pouvez spécifier, avec une grande flexibilité et précision, les artefacts exacts que vous souhaitez copier.

Vous devez spécifier où trouver les fichiers que vous voulez dans l'espace de travail de l'autre tâche de build, et où Jenkins doit les mettre dans votre espace de travail courant. Ceci peut être une expression régulière flexible (comme **/*.war, pour tout fichier WAR produit par la tâche de build), ou cela peut être beaucoup plus précis (comme gameoflife-web/target/gameoflife.war). Notez que par défaut, Jenkins copiera la structure de répertoire en même temps que le fichier que vous récupérez, ainsi si le fichier WAR se trouve dans dans le répertoire target du module gameoflife-web, Jenkins le placera dans le répertoire gameoflife-web/target de votre espace de travail courant. Si cela ne vous convient pas, vous pouvez cocher l'option “Aplatir l'arborescence” pour dire à Jenkins de mettre tous les artefacts à la racine du répertoire que vous spécifiez (ou, par défaut, dans l'espace de travail de votre projet).

Souvent, vous voudrez simplement récupérer des artefacts depuis le build réussi le plus récent. Toutefois, vous voudrez parfois plus de précision. Le champ "Quel build” vous permet de spécifier où chercher des artefacts d'un bon nombre d'autres façons, incluant le dernier build sauvé (builds qui ont été marqués à "toujours conserver"), le dernier build réussi, ou même un numéro spécifique de build.

Si vous avez installé le plugin Build Promotion (voir Section 10.7.3, “Promotions de build”), vous pouvez aussi sélectionner le dernier artefact promu dans un processus de promotion en particulier. Pour faire cela, choisissez "Spécifier par permalien", puis choisissez le processus de promotion de build approprié. C'est un excellent moyen de s'assurer d'un pipeline de build fiable et cohérent. Par exemple, vous pouvez configurer un processus de promotion de build pour déclencher un build qui copie un fichier WAR généré depuis le dernier build promu et le déploie sur un serveur particulier. Ceci vous assure de déployer le bon fichier binaire, même si d'autres builds se sont produits depuis.

Si vous copiez des artefacts d'une tâche de build multimodule Maven, Jenkins copiera, par défaut, tous les artefacts de ce build. Toutefois vous êtes souvent intéressé uniquement par un artefact spécifique (comme l'artefact WAR pour une application web, par exemple).

Ce plugin est particulièrement utile quand vous avez besoin d'exécuter des tests fonctionnels ou de performance sur votre application web. Il est souvent stratégiquement utile de placer ces tests dans un projet séparé, et non comme une partie de votre processus de build principal. Cela facilite l'exécution de ces tests sur différents serveurs ou d'exécuter le sous-ensemble des tests en parallèle, tout en utilisant le même artefact binaire pour déployer et tester.

Par exemple, imaginez que vous avez une tâche de build par défaut appelée gameoflife qui génère un fichier WAR, et que vous vouliez déployer ce WAR sur un serveur d'application local et exécuter une série de tests fonctionnels. De plus, vous voulez pouvoir faire cela en parallèle sur plusieurs machines distribuées.

Une façon de faire cela serait de créer un projet Maven dédié pour lancer les tests fonctionnels sur un serveur arbitraire. Ensuite, vous mettriez en place une tâche de build pour exécuter ces tests fonctionnels. La tâche de build utiliserait le plugin Copy Artifact pour récupérer le dernier fichier WAR (ou même le dernier fichier WAR promu, pour plus de précision), et le déploierait sur une instance Tomcat locale en utilisant Cargo. Cette tâche de build pourrait ensuite être configurée en tant que tâche de build (“matrix”) configurable, et exécutée en parallèle sur plusieurs machines, éventuellement avec des paramètres de configuration supplémentaires pour filtrer les exécutions de test de chaque build. Chaque exécution de build utiliserait ensuite sa propre copie du fichier WAR original. Un exemple d'une configuration comme celle-ci est illustré dans Figure 10.40, “Exécuter des tests web sur un fichier WAR copié”.

Le plugin Copy Artifact n'est pas restreint à la récupération de fichiers depuis des tâches de build conventionnelles. Vous pouvez aussi copier des artefacts à partir de tâches de build multiconfiguration (voir Section 10.4, “Tâches de build multiconfiguration”). Les artefacts de chaque configuration exécutée seront copiés dans l'espace de travail courant, chacun dans son propre répertoire. Jenkins construira une structure de répertoire en se basant sur les axes utilisés dans le build multiconfiguration. Par exemple, imaginez que nous ayons besoin de produire une version hautement optimisée de notre produit pour un certain nombre de bases de données et de serveurs d'application cibles. Nous pourrions faire cela avec une tâche de build multiconfiguration comme celle illustrée dans Figure 10.41, “Copier à partir d'un build multiconfiguration”.

Le plugin Copy Artifacts peut dupliquer n'importe lequel ou même tous les artefacts produits par cette tâche de build. Si vous spécifiez un build multiconfiguration comme source de vos artefacts, le plugin copiera les artefacts de toutes les configurations dans l'espace de travail de la tâche de build cible, en utilisant une structure de répertoire imbriquée basée sur les axes du build multiconfiguration. Par exemple, si vous définissez le répertoire cible comme multi-config-artifacts, Jenkins copiera les artefacts dans un certain nombre de sous-répertoires dans le répertoire cible, chacun avec un nom correspondant à un ensemble particulier de paramètres. Ainsi, en utilisant la tâche de build illustrée dans Figure 10.41, “Copier à partir d'un build multiconfiguration”, le fichier JAR personnalisé pour Tomcat et MySql serait copié dans le répertoire $WORKSPACE/multi-config-artifacts/APP_SERVER/tomcat/DATABASE/mysql.

Dans le monde de l'Intégration Continue, tous les builds créés ne sont pas égaux. Par exemple, vous pourriez vouloir déployer la dernière version de votre application web sur un serveur de test, mais seulement après avoir réussi un certain nombre de tests fonctionnels automatisés ou de charge. Ou vous pourriez vouloir que les testeurs puissent marquer certains builds comme étant prêts pour un déploiement pour les tests d'acceptation utilisateur, une fois qu'ils ont terminé leurs propres tests.

Le plugin Promoted Builds vous permet d'identifier des builds spécifiques ayant atteint des critères additionnels de qualité, et de déclencher des actions sur ces builds. Par exemple, vous pourriez construire une application web dans une tâche de build, exécuter une série de tests automatisés dans un build ultérieur, puis déployer le fichier WAR généré sur le serveur de tests d'acceptation utilisateur pour effectuer davantage de tests.

Voyons comment cela fonctionne en pratique. Dans le projet illustré ci-dessus, une tâche de build par défaut (phoenix-default) exécute des tests unitaires et d'intégration, puis produit un fichier WAR. Ce fichier WAR est ensuite réutilisé pour des tests plus étendus (dans la tâche de build phoenix-integration-tests) et ensuite pour une série de tests web automatisés (dans la tâche de build phoenix-web-test). Si le build réussit les tests web automatisés, nous aimerions déployer l'application dans un environnement de tests fonctionnels où elle pourrait être testée par des testeurs humains. Le déploiement dans cet environnement est effectué avec la tâche de build phoenix-test-deploy. Une fois que les testeurs ont validé la version, elle peut être promue vers l'environnement de tests d'acceptation utilisateur, et enfin en production. La stratégie complète de promotion est illustrée dans Figure 10.42, “Tâches de build dans le processus de promotion”.

Cette stratégie est facile à implémenter en utiliser le plugin Promoted Builds. Une fois que vous l'avez installé de la façon habituelle, vous trouverez une nouvelle case "Promouvoir builds quand" dans la page de configuration de la tâche. Cette option est utilisé pour configurer les processus de promotion de build. Vous définissez un ou plusieurs processus de promotion de build dans la tâche de build initiale du processus (phoenix-default dans cet exemple), comme illustré dans Figure 10.43, “Configurer un processus de promotion de build”. Une tâche de build peut être le point de départ de plusieurs processus de promotion de build, certains automatisés, certains manuels. Dans Figure 10.43, “Configurer un processus de promotion de build”, par exemple, il y a un processus de promotion de build automatisé appelé promote-to-test et un manuel appelé promote-to-uat. Les processus de promotion de build automatisés sont déclenchés par les résultats de tâches de build avals. Les processus de promotion manuels (indiqués en cochant la case ‘Seulement si approuvé manuellement’) peuvent uniquement être déclenchés par une intervention utilisateur.

Regardons à présent comment configurer le processus de build automatisé promote-to-test.

Vous devez commencer par définir comment le processus de promotion de build sera déclenché. La promotion de build peut être soit automatique, basée sur le résultat d'une tâche de build aval, soit activée manuellement par un utilisateur. Dans Figure 10.43, “Configurer un processus de promotion de build”, la promotion de build pour cette tâche de build sera automatiquement déclenchée lorsque les tests web automatisés (exécuté par la tâche de build phoenix-web-tests) auront réussi.

Vous pouvez aussi faire que certaines tâches de build ne puissent être promues que manuellement, comme illustré dans Figure 10.44, “Configurer un processus manuel de promotion de build”. La promotion de build manuelle est utilisée pour les cas où une intervention humaine est requise pour approuver une promotion de build. Le déploiement dans l'environnement de test d'acceptation utilisateur ou de production en sont des exemples courants. Autre exemple, lorsque vous voulez suspendre temporairement les promotions de build pour une courte période, comme à l'approche d'une release.

Les builds manuels, comme leur nom le suggère, nécessite d'être approuvés manuellement avant de pouvoir être exécutés. Si le processus de promotion consiste à déclencher une tâche de build paramétrée, vous pouvez aussi fournir des paramètres que l'approbateur devra entrer lors de l'approbation. Dans certains cas, il peut être utile de désigner certains utilisateurs autorisés à activer la promotion manuelle. Vous pouvez faire cela en spécifiant une liste d'utilisateurs ou de groupes dans la liste d'approbateurs.

Parfois, il est utile de donner un peu de context à une personne approuvant une promotion. Quand vous configurez un processus de promotion manuel, vous pouvez aussi spécifier d'autres conditions devant être remplies, en particulier des tâches de build avals (ou amonts) qui doivent avoir été construites avec succès (voir Figure 10.45, “Voir les détails d'une promotion de build”). Celles-ci apparaîtront dans les “Met Qualifications” (pour les tâches de build en succès) et dans les “Unmet Qualifications” (pour les tâches de builds qui ont échoué ou n'ont pas encore été exécutées).

Vous devez ensuite dire à Jenkins ce qu'il doit faire lorsque le build est promu. Cela se fait en ajoutant des actions, tout comme dans une tâche de build freestyle. Ceci rend les promotions de build extrêmement flexible, parce que vous pouvez ajouter pratiquement n'importe quelle action disponible dans une tâche de build freestyle normale, incluant n'importe quelles étapes additionnelles offertes par le plugins installés sur votre instance Jenkins. Les actions courantes incluent l'invocation de script Maven ou Ant, le déploiement d'artefacts dans un dépôt Maven, ou le déclenchement d'un autre build.

Une chose importante à garder à l'esprit ici est que vous ne pouvez pas vous reposer sur des fichiers de l'espace de travail lors de la promotion de votre build. En effet, au moment où vous promouvez votre build, automatiquement ou manuellement, d'autres tâches de build pourraient avoir supprimé ou réécrit les fichiers que vous avez besoin d'utiliser. Pour cette raison, il est imprudent, par exemple, de déployer un fichier WAR directement à partir de l'espace de travail vers un serveur d'application pendant un processus de promotion de build. Une solution plus robuste consiste à déclencher une tâche de build séparée et d'utiliser le plugin Copy Artifacts (voir Section 10.7.2, “Copier des artefacts”) pour récupérer précisément le bon fichier. Dans ce cas, vous copierez des artefacts que vous avez demandé à Jenkins de conserver, plutôt que de copier directement des fichiers de l'espace de travail.

Pour que la promotion de build fonctionne correctement, Jenkins doit pouvoir lier précisément les tâches de build avals à celles en amont. La façon la plus précise de faire cela est d'utiliser les fingerprints. Dans Jenkins, un fingerprint est le somme de contrôle MD5 d'un fichier produit ou utilisé dans une tâche de build. En faisant correspondre les fingerprints, Jenkins est capable d'identifier tous les builds utilisant un fichier particulier.

Dans le contexte de la promotion de build, une stratégie courante est de construire votre application une seule fois, puis d'exécuter des tests sur les fichiers binaires générés dans une série de tâches de builds avals. Cette approche fonctionne bien avec la promotion de build, mais vous devez vous assurer que Jenkins créer un fingerprint des fichiers partagés ou copiés entre tâches de build. Dans l'exemple montré dans Figure 10.43, “Configurer un processus de promotion de build”, notamment, nous avons besoin de faire deux choses (Figure 10.46, “Utiliser fingerprints dans le processus de promotion de build”). Premièrement, nous devons archiver le fichier WAR généré afin qu'il puisse être utilisé dans le projet aval. Deuxièmement, nous devons enregistrer un fingerprint des artefacts archivés. Vous faites cela en cochant l'option “Enregistrer les fingerprints de fichiers pour tracer leur utilisation”, et en spécifiant les fichiers pour lesquels vous voulez créer un fingerprint. Un raccourci utile consiste simplement à créer un fingerprint pour tous les fichiers archivés, puisque ce sont les fichiers qui vont typiquement être récupérés et réutilisés par les tâches de build avals.

C'est tout ce que vous avez besoin de faire pour configurer le processus initial de build. L'étape suivante consiste à configurer les tests d'intégration exécutés dans la tâche de build phoenix-integration. Ici, nous utilisons le plugin Copy Artifact pour récupérer le WAR généré par la tâche de build phoenix-default (voir Figure 10.47, “Récupérer le fichier WAR depuis la tâche de build amont”). Comme cette tâche de build est déclenchée immédiatement après la tâche de build phoenix-default, on peut simplement récupérer le fichier WAR depuis le dernier build réussi.

Cependant, ce n'est pas encore tout à fait tout ce que nous devons faire pour les tests d'intégration. La tâche de build phoenix-integration est suivie de la tâche de build phoenix-web, qui exécute les tests web automatisés. Pour s'assurer que le même fichier WAR est utilisé à chaque étape du processus de build, nous devons le récupérer dans la tâche de build amont phoenix-integration, et non depuis la tâche originale phoenix-default (qui pourrait avoir été exécutée à nouveau dans l'intervalle). Nous avons donc aussi besoin d'archiver le fichier WAR dans la tâche de build phoenix-integration (voir Figure 10.48, “Archiver le fichier WAR dans la tâche aval”).

Dans la tâche de build phoenix-web, nous récupérons ensuite le WAR depuis la tâche phoenix-integration, en utilisant une configuration très similaire à celle montrée ci-dessus (voir Figure 10.49, “Récupérer le fichier WAR depuis la tâche d'intégration”).

Pour que le processus de promotion de build fonctionne correctement, il y a une chose importante de plus que nous devons configurer dans la tâche de build phoenix-web. Comme nous l'avons évoqué précédemment, Jenkins a besoin de pouvoir être sûr que le fichier WAR utilisé dans ces tests est le même que celui généré dans le build original. Nous faisons cela en activant la création de fingerprint sur le fichier WAR que nous avons récupéré depuis la tâche de build phoenix-integration (qui, rappelez-vous, a originellement été construit par la tâche phoenix-default). Comme nous avons copié ce fichier WAR dans l'espace de travail, une configuration comme celle de Figure 10.50, “Nous avons besoin de déterminer le fingerprint du fichier WAR que nous utilisons” fonctionnera très bien.

L'étape final consiste à configurer la tâche de build phoenix-deploy-to-test pour récupérer le dernier WAR promu (plutôt que le dernier réussi). Pour faire cela, nous utilisons à nouveau le plugin Copy Artifact, mais cette fois nous choisissons l'option "Spécifier par permalien". Ici, Jenkins proposera, entre autres choses, les processus de promotion de build configurés pour la tâche de build à partir de laquelle vous êtes en train de copier. Donc, dans Figure 10.51, “Récupérer le dernier fichier WAR promu”, nous récupérons le dernier fichier WAR promu par la tâche phoenix-default, ce qui est précisément ce que nous voulons.

Notre processus de promotion est maintenant prêt pour l'action. Quand les tests web automatisés réussiront lors d'un build particulier, la tâche de build originale sera promu et le fichier WAR correspondant déployé dans l'environnement de test. Les builds promus sont indiqués par une étoile dans l'historique de build (voir Figure 10.52, “Les builds promus sont indiqués par une étoile dans l'historique de build”). Par défaut, les étoiles sont jaunes, mais vous pouvez configurer la couleur de l'étoile dans la configuration de la promotion de build.

Vous pouvez aussi utiliser l'entrée de menu “Etat de Promotion” (ou cliquez sur l'étoile colorée dans l'historique de build) pour voir les détails d'une promotion de build particulière, et même de réexécuter manuellement une promotion (voir Figure 10.45, “Voir les détails d'une promotion de build”). Toute promotion de build peut être déclenchée manuellement, en cliquant sur "Forcer la promotion" (si cette tâche de build n'a jamais été promue) ou “Ré-exécuter la promotion” (si elle l'a été).

Lorsqu'on répartit différents types de tests dans différentes tâches de build, il est facile de perdre la vision globale des résultats de tests de l'ensemble. Ces résultats sont dispersés parmi les diverses tâches de build, sans un endroit central où voir le nombre total de tests exécutés et échoués.

Un bon moyen d'éviter ce problème est d'utiliser la fonctionnalité d'agrégation de résultats de tests de Jenkins. Ceci récupérera tout résultat de test depuis les tâches de build avals, et les agrégera dans la tâche de build amont. Vous pouvez configurer cela dans la tâche de build initiale (amont) en cochant l'option "Agréger les résultat de test avals" (voir Figure 10.53, “Rapport sur l'agrégation des résultats de test”).

Les résultats de test agrégés peuvent être consultés dans la page de détails du build (voir Figure 10.54, “Visualisation des résultats de tests agrégés”). Malheureusement, ces résultats de test agrégés n'apparaissent pas dans les résultats de test globaux, mais vous pouvez afficher la liste complète des tests exécutés en cliquant sur le lien Résultats de Test Agrégés sur la page du build particulier.

Pour que cela fonctionne correctement, vous devez vous assurer d'avoir configuré la création de fingerprint pour les fichiers binaires utilisés à chaque étape. Jenkins agrégera seulement les résultats de test avals de builds contenant un artefact avec le même fingerprint.

Le dernier plugin que nous allons regarder dans cette section est le plugin Build Pipeline. Le plugin Build Pipelines emmène l'idée de la promotion de build encore plus loin, et vous aide à concevoir et superviser des pipelines de déploiement. Un pipeline de déploiement est une façon d'orchestrer vos builds au travers d'une série de passages garantissant la qualité, avec des approbations automatisées ou manuelles à chaque étape, culminant avec le déploiement en production.

Le plugin Build Pipeline fournit une autre façon de définir des tâches de build avals. Un pipeline de build, contrairement aux dépendances avals conventionnelles, est considéré comme un processus linéaire, une série de tâches de build exécutées en séquence.

Pour utiliser ce plugin, commencez par configurer les tâches de build avals pour chaque tâche de build dans le pipeline, en utilisant le champ “Construire d'autres projets” comme vous le feriez habituellement. Le plugin Build Pipeline utilise les configurations de build amont ou aval standards, et pour les étapes automatiques c'est tout ce que vous avez à faire. Toutefois, le plugin Build Pipeline supporte aussi les étapes de build manuelles, où un utilisateur doit manuellement approuver l'étape suivante. Pour les étapes manuelles, vous devez aussi configurer les Post-build Actions de votre tâche de build amont : cochez simplement la case “Build Pipeline Plugin -> Spécifier Projet Aval”, sélectionnez l'étape suivante dans votre projet, et cochez l'option “Require manual build executor” (voir Figure 10.55, “Configurer une étape manuelle dans le pipeline de build”).

Une fois que vous avez configuré votre processus de build à votre convenance, vous pouvez configurer la vue build pipeline. Vous pouvez créer cette vue comme n'importe quelle autre (voir Figure 10.56, “Créer une vue Build Pipeline”).

Il y a une astuce à connaître lors de la configuration de la vue, cependant. Au moment de l'écriture de ces lignes, il n'y a pas d'option de menu ou de bouton vous permettant de configurer la vue directement. En fait, vous devez entrer l'URL manuellement. Heureusement, ce n'est pas difficile : ajoutez juste /configure à la fin de l'URL lorsque vous affichez cette vue. par exemple, si vous avez appelé cette vue “phoenix-build-pipeline”, comme montré ici, l'URL pour configurer cette vue serait http://my_jenkins_server/view/phoenix-build-pipeline. (voir Figure 10.57, “Configurer une vue Build Pipeline”).

La chose la plus importante à configurer dans cet écran est la tâche initiale. Ceci marque le point d'entrée de votre pipeline de build. Vous pouvez définir de multiples vues de pipeline de build, chacune avec une tâche initiale différente. Vous pouvez aussi configurer le nombre maximum de séquences de build à faire apparaître à la fois sur l'écran.

Une fois que vous avez configuré le point de départ, vous pouvez retourner à la vue pour voir l'état courant de votre pipeline de build. Jenkins affiche les tâches de build successives horizontalement, en utilisant une couleur pour indiquer le résultat de chaque build (Figure 10.58, “Un Pipeline de Build en action”). Il y a une colonne pour chaque tâche de build dans le pipeline. Dès lors que la tâche de build initiale démarre, une nouvelle ligne apparaît sur cette page. Alors que le build progresse parmi les tâches de build successives, Jenkins ajoute une boîte colorée dans les colonnes successives, indiquant le résultat de chaque étape. Vous pouvez cliquer sur la boîte pour descendre dans un résultat de build particulier pour plus de détails. Enfin, si une exécution manuelle est requise, un bouton sera affiché afin que l'utilisateur puisse déclencher la tâche.

Ce plugin est encore relativement nouveau, et ne s'intègre pas avec les autres plugins que nous avons vus ici. En particulier, il est vraiment conçu pour un pipeline de build linéaire, et ne s'en sort pas très bien avec des branches ou des tâches de build parallèles. Néanmoins, il donne une excellente vision globale d'un pipeline de build.