L'intégration continue avec Hudson

L'Intégration Continue (" I.C. ") est le nom donné initialement par la communauté de l'Extreme Programming (" XP ") pour désigner la pratique de génie logicielle visant à accélérer la livraison des logiciels en réduisant le temps d'intégration.

Pour que l'Intégration Continue puisse se faire correctement, il faut tout d'abord partager les sources du projet via un serveur de Gestion de Contrôle des Sources (ou " SCM " pour Source Control Management) tel que CVS ou Subversion. Il faut également que les équipes de développements postent (committent) régulièrement les modifications apportées au code, de préférence plusieurs fois par jour. Enfin, il est nécessaire de disposer de tests unitaires qui seront exécutés par l'outil JUnit ou TestNG par exemple.

La présence des tests n'est en réalité pas obligatoire, mais elle est très fortement conseillée. Ils ont en effet pour tâche principale de vérifier que le code ne subit pas de régression, et que les fonctions implémentées réalisent correctement leurs tâches. Plusieurs types de tests existent (tests unitaires, fonctionnels, graphiques, de déploiement, etc.), chaque type ayant un rôle précis dans la vérification de l'application et de son code. Les tests étant un (très) vaste sujet, nous ne nous y étendrons pas davantage dans cet article

Des outils vont alors se charger de vérifier régulièrement les modifications sur le SCM afin d'assurer la non régression de l'application, en compilant l'ensemble du projet et en en exécutant les tests unitaires.

Globalement, les principaux intérêts de l'IC sont les suivants :

• Vérification fréquente du code, et de sa bonne compilation.
• Réalisation des tests unitaire et / ou fonctionnels, voire tests d'intégration.
• Mise à disposition éventuelle d'une version testable comportant les dernières modifications du code (on pourra ainsi faire déployer son WAR sur un serveur Tomcat tous les jours).
• Possibilité de créer des rapports périodiques exprimant la qualité du code, la couverture des tests, etc. Si le projet est configuré pour Maven, alors on pourra créer le site du projet qui contiendra l'ensemble de ces rapports.

Les deux premiers avantages de cette liste montrent que l'IC permet de détecter quasi-immédiatement la présence d'un problème dans le code... et donc d'y apporter une solution instantanément !

Il existe aujourd'hui de nombreux outils d'intégration continue. Nous n'allons pas aller dans le détail de chacun d'eux, mais voici une liste (loin d'être exhaustive) des principaux outils existants dans ce domaine :

• Anthill Pro.
• Atlassian Bamboo.
• Build Forge.
• Cruise Control : l'un des outils d'IC les plus anciens et plutôt populaire.
• Apache Continuum : l'outil " officiel " de la communauté Maven.
• Hudson : l'un des tout derniers, qui fait beaucoup parler de lui. Pour preuve, cet article lui est entièrement consacré !
• Luntbuild (et Luntbuild pro).
• JetBrains TeamCity.
• etc.

Une page faisant un comparatif assez complet entre de nombreux outils d'IC est disponible ici.

Hudson est un serveur d'Intégration Continue très en vogue actuellement. Sa simplicité, comme nous allons le voir dans les chapitres suivants, en fait un outil très apprécié. La version d'Hudson présentée dans cet article est la 1.200, la dernière disponible lors de la publication de cet article est la 1.206 (le 9 Avril 2008).

La license d'Hudson est à la fois basée sur la license Creative Commons et sur la license MIT. Concrètement, son utilisation est libre, que ce soit pour une utilisation dans un cadre personnel ou dans un cadre professionnel.

Pour faire fonctionner Hudson, la seule contrainte est de disposer d'une JVM sur le serveur (Java 5 ou supérieur est requis). La première étape, bien sûr, est de télécharger Hudson sur le site officiel de l'application. Une fois le fichier WAR téléchargé, il suffit de lancer la commande suivante pour démarrer le serveur Hudson : java -jar hudson.war.

On privilégiera cependant l'installation du package hudson.war dans un containeur, tel que le serveur Apache Tomcat. Il est même possible de tester Hudson sans le télécharger, en utilisant la version JNPL disponible ici !

Hudson va loger tous les fichiers nécessaires à son fonctionnement dans son espace de travail (le " workspace "). Ce répertoire se définit via la variable système HUDSON_HOME. Il contiendra tous les fichiers XML de configuration, ainsi que tous les projets - et leurs fichiers - qui seront créés avec cet outil. Ainsi, la mise à jour d'Hudson se réalise très aisément, en ne mettant à jour que le fichier WAR hébergé par Tomcat, aucun fichier de " travail " n'étant perdu.

En se rendant à l'adresse locale http://localhost:8080/hudson (ou http://localhost:8080) on arrive sur la page d'accueil du serveur d'Hudson. L'interface y est pour le moment très épurée :

On notera la présence d'une boite de recherche située dans l'entête de toutes les pages d'Hudson. Cette fonction de recherche permet surtout de se déplacer rapidement vers une page précise d'Hudson, d'un projet, etc. Voir la page ici (en anglais) pour plus de détails...

Contrairement à certains autres outils d'IC, Hudson ne nécessite l'écriture ou la modification d'aucun fichier XML. Toute la configuration (qu'elle soit générale ou spécifique à un projet) se fait directement depuis l'interface en ligne d'Hudson. Sur la page principale, le lien " Gérer Hudson " permet d'accéder aux fonctions suivantes :

• Configuration système : configuration générale d'Hudson : répertoire d'installation des JDK, de Maven, configuration du SCM, gestion de la sécurité, etc.
• Rechargement la configuration à partir du disque : permet de recharger la configuration contenue dans les fichiers XML se trouvant sur le disque dur du serveur. Utile lorsque l'on s'amuse à modifier manuellement les fichiers de configuration.
• Gérer les plugins : gestionnaire des plugins d'Hudson.
• Informations système : informations sur la configuration système du serveur.
• Log système : logs d'Hudson.
• Console de script : exécution de scripts pour l'administration.
• Gérer les machines esclaves (option disponible seulement si des machines esclaves sont définies) : permet de vérifier l'état des machines esclaves.
• Se préparer à la fermeture : commande utilisée pour préparer Hudson à son arrêt, de façon propre. A employer lorsqu'il s'agit de mettre à jour la version d'Hudson ou tout simplement pour stopper le serveur Tomcat.

Jetons maintenant un oeil attentif au panneau de configuration système d'Hudson. Voici quelques paramètres intéressants :

• Nombre de lanceurs : nombre maximal d'exécutions concurrentes qu'Hudson peut lancer. Autrement dit, ce paramètre définit combien de compilations simultanées peuvent être lancées par le serveur d'IC.
• Activer la sécurité : permet de gérer la sécurité sur Hudson, de façon à en limiter son accès. Nous y reviendrons plus tard.
• JDKs : liste des JDK installés sur le serveur.
• Ant : liste des versions de Ant installés sur le serveur.
• Maven : liste des Maven installés sur le serveur.
• Notification par email : paramètres de configuration pour l'envoi des emails.

Ces paramètres sont importants, car ils seront utilisés pour nos projets Hudson. Nous allons d'ailleurs nous occuper maintenant de créer notre premier projet.

Nous allons créer notre premier projet. Considérons que nous disposons d'un projet basé sur Maven 2. Nous choisissons donc l'option " Construire un projet Maven 2 " parmi les possibilités offertes par Hudson lorsque l'on crée un nouveau job.

Les autres options sont les suivantes :

• Construire un projet free-style : créer un projet en choisissant sa propre configuration. Utile si l'on veut gérer un projet basé sur Ant ou si l'on désire exécuter des lignes de commandes batch Windows.
• Construire un projet multi-configuration : créer un projet pouvant disposer d'une configuration multiple (voir la " matrice de configuration " dans le chapitre sur les fonctionnalités avancées).
• Contrôler un job externe : ce type de projet permet de suivre l'exécution d'un process exécuté hors d'Hudson, éventuellement sur une machine distante.
• Copier un job existant : créer un nouveau projet à partir d'un projet déjà existant dans Hudson.

Sur cet écran de configuration, voici les options principales à paramétrer :

• Description : la description du projet !
• Supprimer les anciens builds : indique si Hudson doit supprimer les anciens builds de ce projet, afin de ne pas encombrer le serveur de fichiers. On peut paramétrer Hudson pour ne garder qu'un nombre limité de builds ou alors pour ne les conserver que pendant une période donnée... Il faut toutefois noter qu'Hudson ne se base que sur les builds conservés par le serveur pour définir les statistiques et l'historique du projet (temps de construction, résultats des tests, etc.).
• Désactiver le build : permet de désactiver le projet sans le supprimer.
• Gestion du Code Source : configuration du SCM, qui permet à Hudson d'aller récupérer les fichiers sources sur CVS ou Subversion par exemple. D'autres systèmes de SCM sont accessibles grâce à l'ajout de plugins.
• Scruter l'outil de gestion de version : une option permettant d'indiquer à Hudson d'aller vérifier périodiquement l'existence de fichiers modifiés sur le SCM pour lancer le build. Autrement dit, cette option permet à Hudson de ne lancer un build qu'en cas de modification des sources sur le serveur SCM.
• Builder périodiquement : force Hudson à faire des builds à intervalles réguliers, qu'il y ait des modifications sur le SCM ou non. On privilégiera toutefois l'option précédente, en fixant un intervalle de temps plus long pour gérer les nightly builds, ces builds qui prennent beaucoup de temps (car on va réaliser un maximum de tests, créer le site du projet contenant les rapports, etc.) et qui sont ainsi généralement lancés la nuit. Il est en effet inutile de démarrer un build si aucune modification du code n'a été faite depuis le précédent build...
• Goals : indique quel(s) goal(s) Maven 2 doivent être exécutés lors du build. Un bon choix serait par exemple " clean install ".
• Email notification : option permettant de dire à Hudson s'il faut envoyer des emails ou non à la fin d'un build lorsque celui-ci échoue, redevient correct (c'est-à-dire lors du premier build réussi après un échec) ou est instable (c'est-à-dire que certains tests ont échoué). Il est aussi possible de notifier, lors d'un échec, toutes les dernières personnes ayant mis à jour le code source sur le SCM depuis le dernier build réussi. Les développeurs sont ainsi informés automatiquement qu'un commit récent a cassé la compilation du code.
• Actions à la suite du build : actions à réaliser par Hudson une fois le build terminé. Il peut s'agir de lancer un autre projet, ou de déployer l'artifact créé sur un repository Maven.

On notera la présence de l'icône à proximité de la plupart des options, offrant une explication plus approfondie de l'option.

Comme on peut le constater, la création d'un projet Maven 2 est d'une grande simplicité avec Hudson : il suffit pratiquement de lui indiquer où trouver le pom.xml du projet sur le SCM pour qu'il se débrouille tout seul !

Une fois le projet créé, Hudson va nous proposer de lancer le premier build manuellement. On verra alors l'exécution d'un build apparaître dans l' " Historique des builds " d'Hudson

A noter qu'il est possible de s'abonner aux flux RSS pour chaque projet, comme le montre la capture précédente. Il existe un flux RSS regroupant tous les builds, ainsi qu'un autre flux se limitant aux builds en échec.

Une autre option intéressante est la possibilité de rassembler plusieurs projets au sein d'un même groupe pour plus de clarté, chaque groupe étant alors présenté dans un onglet sur la page d'accueil d'Hudson (l'ajout se fait en appuyant sur le dernier onglet marqué d'un " + ") :

Lors de la première lecture du pom.xml par Hudson, ce dernier va déterminer les éventuels sous-modules du projet. Lors de la construction d'un projet par Hudson, il est alors possible de suivre avec précision l'avancée du travail :

Lorsque l'on visualise un projet, nous pouvons voir sur la partie gauche de l'interface d'Hudson, une série d'options ou de commandes :

• Changements : liste des dernières modifications trouvées sur le SCM depuis le précédent build. Une sorte de changelog.
• Espace de travail : accès à l'espace de travail du projet, celui utilisé par Hudson. On peut y voir l'ensemble des fichiers sur lequel Hudson travaille, et les récupérer (une option utile permet de récupérer tous les fichiers sous forme de ZIP).
• Lancer un build : lance un build manuel sur ce projet.
• Supprimer ce projet : supprime définitivement ce projet d'Hudson. Il est possible, via la configuration du projet, de désactiver le projet, sans le supprimer.
• Configurer : permet de configurer ce projet.

Lorsque l'on visualise un build précis d'un projet, d'autres options sont proposées :

• Sortie console : la sortie console permet de voir ce que les logs des builds affichent. Il existe pour cela deux types de sortie console : la version standard et la version brute. L'avantage du premier est qu'il est possible de suivre en temps réel l'écriture des logs lorsqu'un build est en cours.
• Tagguer ce build : fonctionnalité pour tagguer le build en cours.
• Surveiller un process Maven : permet d'obtenir des informations précises sur le processus Maven en cours, comme les propriétés systèmes, les variables d'environnement, etc.

Une dernière option est disponible pour les projets Maven déjà exécutés : Mojos exécutés. On y voit la liste de tous les plugins Maven qui ont été lancés par le build d'Hudson, le goal utilisé, ainsi que leur durée d'exécution :

Si le projet que vous désirez intégrer à Hudson est géré par Ant et non par Maven, il suffit de créer un nouveau " projet free-style " et de définir les tâches Ant à appeler, comme le montre la capture suivante :

La gestion du projet une fois celui-ci créé reste la même que pour un projet Maven...

IV-A-1. Statut d'un projet▲

IV-A-2. Santé d'un projet▲

IV-A-3. Tendance d'un projet▲

Hudson nous permet d'ajouter une liste de machines " esclaves " pour le serveur actuel, ce dernier étant alors considéré comme le " maître ". L'intérêt de cette fonctionnalité est de pouvoir exécuter des jobs sur des machines autres que le serveur, et donc d'augmenter le nombre de jobs concurrents possibles. Cela devient particulièrement intéressant dès lors que l'on utilise la matrice de configuration (voir chapitre suivant).

Le principe de la matrice de configurations est d'autoriser l'exécution d'un projet selon différentes configurations. Il est ainsi possible de construire le même projet avec différentes versions du JDK, pour tester la compatibilité du projet avec Java 1.4, Java 5, Java 6... Ce type de projet Hudson nous offre également la possibilité de réaliser des tests sur différentes bases de données, par exemple MySQL, PostgreSQL, Oracle, SQL Server... Cela correspond au concept des Axes, chaque axe étant une valeur précise pour un paramètre donné. Dans notre exemple de base de données, nous avons un axe database qui peut prendre les valeurs mysql, postgresql, oracle ou encore sqlserver.

Hudson va réaliser un build par combinaison possible. Si nous définissons 3 versions de Java à tester et 4 types de bases de données, Hudson aura donc besoin de réaliser 12 builds consécutifs pour créer la matrice de configurations. Ainsi, plus on a de paramètres, plus on couvrira de configurations possibles, mais en contrepartie, Hudson aura beaucoup plus de travail à fournir ! On appréciera ici particulièrement le fait de disposer de machines esclaves !

La liste des utilisateurs est automatiquement mise à jour par Hudson via les informations récupérées sur le SCM. Lorsqu'un nouvel utilisateur commite un fichier sur le SCM, alors Hudson l'ajoutera lors du prochain build parmi la liste de ces utilisateurs. On peut ensuite configurer chaque utilisateur pour lui définir son adresse email. Ces informations seront utilisées par Hudson pour transmettre par email les rapports d'échec de builds. Ces utilisateurs peuvent également être utilisés pour définir les accès au serveur Hudson, comme nous allons le voir dans le chapitre suivant.

La gestion de la sécurité permet de limiter l'accès, ou les opérations, pour un certain type d'utilisateur d'Hudson. Par défaut, celle-ci n'est pas activée, et par conséquent, toute personne peut se logguer sur Hudson et faire ce qui lui plaît : ajouter des projets, les configurer, les supprimer, lancer des builds manuels, etc.

La sécurité se gère au niveau de la configuration système d'Hudson, en sélectionnant l'option " Activer la sécurité " :

Trois options sont proposées pour gérer la liste des utilisateurs :

• Déléguer cela au containeur servlets, par exemple Tomcat.
• Utiliser la liste des utilisateurs d'Hudson (celle présentée au chapitre précédent).
• Utiliser un annuaire LDAP.

Hudson propose plusieurs façons de spécifier les droits des utilisateurs :

• Les utilisateurs loggués ont le droit de tout faire : autrement dit, un utilisateur ayant les droits d'accès à Hudson pourra faire ce qu'il y veut.
• N'importe qui peut tout faire : il s'agit de la même option que la précédente, à ceci près qu'aucune authentification n'est demandée. Cette option, sélectionnée par défaut, est à éviter si Hudson est accessible par un réseau externe (comme Internet).
• Mode legacy : dans ce mode, seul les utilisateurs admin sont autorisés à réaliser des actions sur les projets. Tous les autres utilisateurs ont un accès en lecture seule.
• Sécurité basée sur une matrice : grâce à ce mode, on peut attribuer des droits d'accès plus précis à chaque groupe d'utilisateurs :

Hudson récupère automatiquement les informations liées à l'exécution des tests lorsqu'il construit un projet. A l'aide de ces graphiques, il est possible de voir l'évolution de l'exécution - et de la réussite - des tests au cours des builds du projet.

En cliquant sur ce graphique, la liste complète des tests - réussis et échoués - s'affiche, avec le détail de leur exécution.

Hudson dispose de la possibilité d'étendre ses capacités grâce à l'ajout de plugins. Certains plugins vont ajouter le support d'un système particulier, comme par exemple le support des SCM ClearCase, Mercurial, Perforce, etc. D'autres vont offrir un support pour de nouveaux rapports. Nous pouvons ainsi disposer de rapports Clover, Cobertura, Crap4J, FindBugs, NUnit, etc. lors de la construction des projets.

Certains plugins vont également permettre de connecter Hudson à des systèmes externes, comme Jira, Trac, Google Calendar, etc.

La liste (non exhaustive, mais assez complète) des plugins disponibles pour Hudson est visible ici.

Sur la page d'administration d'Hudson, une option est destinée à la configuration des plugins installés sur le serveur Hudson. On retrouvera sur cette page la liste des plugins installés, ainsi qu'un lien pour ajouter un nouveau plugin :

L'ajout d'un plugin se fait donc simplement en indiquant où trouver le fichier du plugin en question sur son disque dur (fichier à l'extension hpi). Celui-ci sera alors installé dans l'espace de travail d'Hudson (dans le répertoire HUDSON_HOME/plugins). La mise à jour d'Hudson sur Tomcat n'impactera donc pas l'installation - et la configuration - des plugins déjà présents.

Il est maintenant nécessaire de stopper puis de redémarrer Hudson pour que le plugin soit pris en compte (pensez à utiliser l'option " Préparation à la fermeture " !). Chaque plugin se configure d'une façon particulière. Par exemple, certains ajouterons une nouvelle option dans la configuration générale d'Hudson, d'autres proposeront un nouveau rapport lors de la construction d'un projet... Nous laisserons donc le soin de documenter ces informations à l'équipe de développement de ces plugins !

Il existe également des plugins pour différents IDE - Eclipse, NetBeans, IntelliJ - offrant une vue rapide de l'état des projets Hudson au sein même de l'IDE. La capture suivante illustre ceci pour la plateforme Eclipse :

On peut développer son propre plugin pour l'intégrer à Hudson. Une page indique tout ce qu'il faut savoir pour créer son propre plugin. Nous n'entrerons pas plus dans le détail du développement des plugins dans cet article, le sujet étant assez vaste !

Les sites présentés ici sont en anglais :

• Site officiel d'Hudson : https://hudson.dev.java.net
• Changelogs des versions: https://hudson.dev.java.net/changelog.html
• Wiki : http://hudson.gotdns.com/wiki/display/HUDSON/Use+Hudson
• http://en.wikipedia.org/wiki/Continuous_integration
• http://www.martinfowler.com/articles/continuousIntegration.html

• Eric Lefèvre pour ses conseils.
• Pour la relecture: cdeniaud, David Gimelle et mon papa :)
• A l'équipe d'Hudson pour ce superbe outil, bien entendu !

• Version actuelle d'Hudson : 1.206.
• Version utilisée lors de la rédaction de cet article : 1.200.

• SCM supportés par Hudson:

  • Nativement: CVS et Subversion.
  • Grâce à l'ajout d'un plugin : Perforce, ClearCase, Mercurial et Acurev, StarTeam.