Pour créer une nouvelle tâche de build multiconfiguration, choisissez simplement l'option suivante sur la page Nouvelle Tâche (voir Figure 10.19, “Créer une tâche de build multiconfiguration”).

Une tâche de build multiconfiguration ressemble à n'importe quelle autre tâche, mais avec un élément supplémentaire très important : la Matrice de Configuration (voir Figure 10.20, “Ajouter un axe à un build multiconfiguration”). C'est là que vous définissez les différentes configurations qui seront utilisées pour exécuter vos builds.

Vous pouvez définir différents axes d'options de configuration, incluant l'exécution de la tâche de build sur différents esclaves ou sur différents JDKs, ou en fournissant vos propres propriétés personnalisées au build. Par exemple, dans les tâches de build discutées précédemmennt, nous pourrions vouloir tester notre application pour différentes bases de données et différents systèmes d'exploitation. Nous pourrions définir un axe définissant les machines esclaves avec différents systèmes d'exploitation sur lesquels nous voudrions faire tourner nos builds, et un autre axe définissant toutes les valeurs possibles de bases de données. Jenkins exécutera ensuite la tâche de build pour chaque base de données et chaque système d'exploitation possibles.

Regardons à présent les types d'axes que nous pouvons définir.

La première option consiste à configurer votre build pour exécuter simultanément le build sur différentes machines esclaves (voir Chapter 11, Builds distribués). Evidemment, l'idée d'avoir un ensemble de machines esclaves est généralement pour que vous puissiez exécuter votre build sur n'importe laquelle. Mais il y a des cas où il est normal d'être plus sélectif. Par exemple, vous pourriez vouloir lancer vos tests sur Windows, Mac OS X, et Linux. Dans ce cas, vous créez un nouvel axe pour vos noeuds esclaves, comme montré dans Figure 10.21, “Définir un axe de noeuds esclave”. Vous pouvez choisir les noeuds que vous voulez utiliser de deux façons : par label ou par noeud individuel. Utiliser des labels vous permet d'identifier des catégories de noeuds de construction (par exemple, des machines Windows), sans lier le build à aucune machine en particulier. C'est une option plus flexible, et elle rend plus facile l'extension de votre capacité de build si nécessaire. Parfois, cependant, vous pouvez réellement vouloir exécuter un build sur une machine spécifique. Dans ce cas, vous pouvez utiliser l'option "Noeuds individuels" et choisir la machine dans la liste.

Si vous avez besoin de plus de flexibilité, vous pouvez aussi utiliser une Label Expression, ce qui vous permet de définir quels noeuds esclaves peuvent être utilisés pour un axe particulier en utilisant des expressions booléennes et des opérateurs logiques pour combiner les labels. Par exemple, supposons que vous avez défini des labels pour les machines esclaves en fonction du système d'exploitation (“windows”, “linux”) et des bases de données installées (“oracle”, “mysql”, “db2”). Pour définir un axe n'exécutant les tests que pour les machines Windows sur lesquelles est installé MySQL, vous pouvez utiliser une expression comme windows && mysql.

Nous traitons du travail avec des noeuds esclaves et les builds distribués plus en détail dans Chapter 11, Builds distribués.

Si vous déployez votre application sur une large base client sur laquelle vous avez un contrôle limité de l'environnement cible, vous pouvez avoir besoin de tester votre application en testant différentes versions de Java. Dans ce genre de cas, il est utile de pouvoir mettre en place un axe JDK dans un build multiconfiguration. Quand vous ajoutez un axe JDK, Jenkins propose automatiquement la liste des versions de JDK dont il a connaissance (voir Figure 10.22, “Définir un axe de versions de JDK”). Si vous avez besoin d'utiliser des JDKs additionnels, ajoutez les simplement à votre page de configuration Jenkins.

Le troisième type d'axe vous permet de définir différentes façons d'exécuter votre tâche de build, basées sur des variables arbitraires que vous définissez. Par exemple, vous pouvez fournir une liste de bases de données que vous avez besoin de tester, ou une liste de navigateurs à utiliser dans vos tests web. Ceci est très similaire aux paramètres pour une tâche de build paramétré, excepté que vous fournissez la liste complète des valeurs possibles, et que plutôt que d'interroger l'utilisateur pour qu'il entre une valeur, Jenkins lance le build avec toutes les valeurs fournies (Figure 10.23, “Définir un axe spécifique à l'utilisateur”).

Une fois que vous avez configuré les axes, vous pouvez exécuter votre build multiconfiguration comme n'importe quel autre. Toutefois, Jenkins traitera chaque combinaison de variables comme un build séparé. Jenkins affiche les résultats agrégés dans un tableau, où toutes les combinaisons sont montrées (voir Figure 10.24, “Résultats de build multiconfiguration”). Si vous cliquez sur les boules, Jenkins vous emmènera aux résultats détaillés pour un build particulier.

Par défaut, Jenkins exécutera les tâches de build en parallèle. Toutefois, il y a quelques cas où cela n'est pas une bonne idée. Par exemple, de nombreuses applications web Java utilisent des tests Selenium ou WebDriver s'exécutant sur une instance locale de Jetty automatiquement démarrée par la tâche. Les scripts de build de ce genre doivent être spécialement configurés pour pouvoir s'exécuter en parallèle sur la même machine, pour éviter les conflits de ports. L'accès concurrent à la base de données pendant les tests peut être une autre source de problèmes si la gestion de la concurrence n'est pas intégrée à la conception des tests. Si vos builds ne sont pas conçus pour fonctionner en parallèle, vous pouvez forcer Jenkins à exécuter les tests de manière séquentielle en cochant la case Exécuter chaque configuration séquentiellement en bas de la section Configuration de la matrice.

Par défaut, Jenkins exécutera toutes les combinaisons possibles des différents axes. Donc, dans l'exemple ci-dessus, nous avons trois environnements, deux JDKs et quatre bases de données. Ceci résulte en un total de 24 builds. Toutefois, dans certains cas, exécuter certaines combinaisons ne pourrait avoir aucun sens (ou n'être pas possible). Par exemple, supposons que vous ayez une tâche de build qui exécute des tests web automatisés. Si un axe contient les navigateurs web à tester (Firefox, Internet Explorer, Chrome, etc.) et un autre les systèmes d'exploitation (Linux, Windows, Mac OS), cela n'aurait pas beaucoup de sens d'exécuter Internet Explorer avec Linux ou Mac OS.

L'option de Filtre de Combinaison vous permet de mettre en place des règles définissant quelles combinaisons de variables sont valides. Ce champ est une expression booléene Groovy qui utilise les noms des variables que vous définissez pour chaque axe. L'expression doit valoir true pour que le build s'exécute. Par exemple, supposez que vous ayez une tâche de build exécutant des tests web dans différents navigateurs sur différents systèmes d'exploitation (voir Figure 10.25, “Mettre en place un filtre de combinaison”). Les tests nécessitent d'exécuter Firefox, Internet Explorer et Chrome, sur Windows, Mac OS X, et Linux. Toutefois Internet Explorer ne fonctionne que sous Windows, et Chrome ne fonctionne pas sous Linux.

Pour configurer un Filtre de Combinaison, nous pourrions utiliser une expression comme la suivante :

(browser=="firefox")
|| (browser=="iexplorer" && os=="windows")
|| (browser=="chrome" && os != "linux")

Ceci résulterait dans le fait que seules les combinaisons correctes navigateur/système d'exploitation seraient exécutées (voir Figure 10.26, “Résultats de build utilisant un filtre de combinaison”). Les builds exécutés sont affichés dans les couleurs habituelles, alors que les builds non-exécutés sont grisés.

Une autre raison d'utiliser un filtre de build est qu'il y a simplement trop de combinaisons valides pour s'exécuter dans un temps raisonnable. Dans ce cas, la meilleure solution pourrait être d'augmenter la capacité de votre serveur de build. La deuxième meilleure solution, d'un autre côté, serait d'exécuter uniquement un sous-ensemble des combinaisons, éventuellement exécutant l'ensemble complet de combinaison pendant la nuit. Vous pouvez faire cela en utilisant la variable spéciale index. Si vous incluez l'expression (index%2 == 0), par exemple, cela assurera que seulement un build sur deux est en fait exécuté.

Vous pourriez aussi vouloir que certains builds s'exécutent avant les autres, comme tests de cohérence. Par exemple, vous pouvez vouloir exécuter la configuration par défaut (et, théoriquement, la plus fiable) pour votre application en premier, avant de continuer avec des combinaisons plus exotiques. Pour faire cela, vous pouvez utiliser l'option “Execute touchstone builds first”. Ici, vous entrez une valeur de filtre (comme celle montrée ci-dessus) pour définir le ou les premiers builds à exécuter. Vous pouvez aussi spécifier si le build devrait continuer seulement si ces builds sont réussis, ou même s'ils échouent. Une fois que ces builds se sont terminés comme prévu, Jenkins procédera au lancement des autres combinaisons.