Jenkins possède un support intégré pour les build parallèles — quand une tâche démarre, Jenkins va lui assigner le premier noeud de build disponible. Vous pouvez donc avoir potentiellement autant de builds parallèles en exécution que vous avez de noeuds disponibles.

Si vous avez besoin d'exécuter une légère variations de la même tâche de build en parallèle, les tâches de build multiconfiguration (voir Section 10.4, “Tâches de build multiconfiguration”) sont une excellente option. Ceci peut s'avérer très pratique comme moyen d'accéler votre processus de build. Une application typique des tâches de build multiconfiguration dans ce contexte est d'exécuter des tests d'intégration en parallèle. Vous pourriez définir des profils Maven par exemple, ou configurer votre build pour utiliser des paramètres de ligne de commande pour décider quels tests exécuter. Une fois que vous avez configuré vos scripts de build de cette façon, il est aisé de configurer une tâche de build multiconfiguration pour exécuter un sous ensemble de vos tests d'intégration en parallèle.

Vous pouvez aussi faire que Jenkins déclenche plusieurs tâches avals en parallèle, en les listant simplement dans le champ "Construire d'autres projets" (voir Figure 10.30, “Déclencher plusieurs autres builds après une tâche de build”). Les tâches de build suivantes seront exécutées en parallèle autant que possible. Toutefois, comme nous le verrons plus loin, cela peut ne pas toujours être exactement ce dont vous avez besoin.

Avant d'étudier les points les plus fins des buils parallèles, il est utile de pouvoir visualiser les relations entre vos tâches de build. Le plugin Dependency Graph View analyse vos tâches de build et affiche un graphe décrivant les connexions amont et aval entre vos tâches. Ce plugin utilise graphviz, que vous aurez besoin d'installer sur votre serveur si vous ne l'avez pas déjà.

Ce plugin ajoute une icône Graphe de dépendance dans le menu principal, qui affiche un graphe montrant les relations entre toutes les tâches de build dans votre projet (au niveau tableau de bord), ou toutes les tâches de build liées à la tâche de build courante (quand vous êtes à l'intérieur d'un projet particulier [voir Figure 10.31, “Un graphe de dépendance de tâche de build”]). De plus, si vous cliquez sur une tâche de build dans le graphe, Jenkins vous emmènera directement vers la page projet de cette tâche de build.

Lors de la configuration de pipelines de builds plus compliqués, vous rencontrerez fréquemment des situations où une tâche de build ne peut démarrer tant qu'un certain nombre d'autres tâches de build ne sont pas terminées, mais que ces tâches amont ne nécessitent pas d'être exécutées séquentiellement. Par exemple, dans Figure 10.31, “Un graphe de dépendance de tâche de build”, imaginez que la tâche de build phoenix-deploy-to-uat ait en fait besoin que trois tâches réussissent avant qu'elle puisse être exécutée : phoenix-compatibility-tests, phoenix-load-tests, et phoenix-performance-tests.

On peut configurer cela en utilisant le plugin Joins, que vous devez installer de la façon habituelle via le centre de mise à jour. Une fois qu'il est installé, vous configurez une jonction dans la tâche de build qui initie le processus de jonction (ici, ce serait phoenix-web-tests). Dans notre exemple, nous devons modifier la tâche de build phoenix-web-tests afin qu'elle déclenche en premier phoenix-compatibility-tests, phoenix-load-tests, et phoenix-performance-tests, et ensuite, si ces trois réussissent, la tâche de build phoenix-deploy-to-uat.

Nous le faisons en configurant simplement le champ déclencheur de jonction avec le nom de la tâche de build phoenix-deploy-to-uat (voir Figure 10.32, “Configurer une jonction dans la tâche de build phoenix-web-tests”). Le champ “Construire d'autres projets” n'est pas modifié, et liste encore les tâches de build à déclencher immédiatement après la tâche courante. Le champ déclencheur de jonction contient les tâches de build à lancer une fois que toutes les tâches avals immédiates se sont terminées.

Résultat, vous n'avez plus besoin du déclencheur de build original pour la tâche de build final, puisque c'est à présent redondant.

Ce nouveau déroulement apparaît bien dans les graphes de dépendance illustrés dans Figure 10.33, “Un graphe de dépendance de tâche de build plus compliqué”.

Dans d'autres situations, vous pourriez être capable de lancer une série de builds en parallèle jusqu'à un certain point, mais certaines tâches de build pourraient ne pas pouvoir être lancées en parallèle parce qu'elles accèdent à des ressources en concurrence. Bien sûr, des tâches de build bien conçues devraient s'efforcer d'être aussi indépendantes que possible, mais cela peut parfois être difficile. Par exemple, différentes tâches de build peuvent accéder à la même base de données de test, ou à des fichiers sur le disque dur, et faire cela simultanément pourrait potentiellement compromettre le résultat des tests. Une tâche de build de performance pourrait avoir besoin d'un accès exclusif au serveur de test, afin d'avoir des résultats cohérents à chaque fois.

Le plugin Locks and Latches vous permet d'une certaine façon de contourner ce problème. Ce plugin permet de configuration des “verrous” (ndt: locks) pour certaines ressources, de façon similaire aux verrous en programmation multithreadée. Supposez, par exemple, dans les tâches de build dépeintes dans Figure 10.33, “Un graphe de dépendance de tâche de build plus compliqué”, que les tests de charge et les tests de performance soient exécutés sur un serveur dédié, mais qu'une seule tâche de build puisse être exécutée à la fois sur ce serveur. Imaginez de plus que les tests de performance pour les autres projets soient aussi exécutés sur ce serveur.

Pour éviter la contention sur le serveur de performance, vous pourriez utiliser le plugin Locks and Latches pour mettre en place un accès par réservation de "verrou" à ce serveur pour une tâche à un instant donné. Premièrement, dans la page de configuration du système, vous devez ajouter un nouveau verrou dans la section Verrous (voir Figure 10.34, “Ajouter un nouveau verrou”). Ce verrou sera ensuite disponible à toutes les tâches de build sur le serveur.

Ensuite, vous devez configurer chaque tâche de build qui utilisera la ressource en contention. Dans la section Environnement de build, vous trouverez un champ Verrous. Cochez la case et sélectionnez le verrous que vous venez juste de créer (voir Figure 10.35, “Configurer une tâche de build pour utiliser un verrou”). Une fois que avez fait cela pour chacune des tâches de build qui ont besoin d'accéder à la ressource en question, seule une des tâches de build pourra s'exécuter à un instant donné.