Cruise Control - Serveur d'intégration continue en JAVA

Cruise Control est un serveur d'intégration continue que j'ai mis en place pour faire de l'intégration continue sur 4-5 applications différentes. Je vais donc vous en parler ici, en commençant par une explication sur l'intégration continue, puis en vous expliquant comment configurer des projets et enfin comment voir et utiliser les résultats de ces compilations. À travers ces explications, vous comprendrez aisément tout l'intérêt d'utiliser l'intégration continue dans vos équipes de développement et les avantages que Cruise Control peut vous apporter.

Tout d'abord, qu'est-ce que l'intégration continue ?
L'intégration continue est une technique de développement/management de projet qui implique d'intégrer très fréquemment le travail de tous les membres d'une équipe. Ensuite, une compilation automatique doit être lancée pour vérifier les éventuelles erreurs de compilation du projet puis si possible les tests unitaires doivent aussi être lancés.

Concrètement, l'intégration continue est le fait d'automatiser des compilations fréquentes du code source d'une équipe incluant les derniers changements de tous ses membres. La plupart des outils d'intégration continue sont capables de faire les actions suivantes :

• lancement d'une intégration périodique (toutes les heures par exemple) ;
• mise à jour du code depuis un gestionnaire de code source ;
• compilation du code source ;
• lancement des tests unitaires ;
• envoi de mails automatique aux personnes concernées (celui qui a fait l'erreur recevra le mail d'erreur) ;
• envoi d'un mail de rapport ;
• déploiement sur un serveur de test ;
• création de statistiques.

En réalité, la plupart des serveurs d'intégration continue se basant sur ANT ou MAVEN (ou les deux), ils permettent un nombre quasi infini d'actions possibles.

Les bénéfices de l'intégration continue sont indéniables, cela permet de vérifier petit à petit le travail de toute l'équipe, de détecter les erreurs beaucoup plus rapidement et d'assurer la cohérence de l'application. Couplé aux tests unitaires, cela permet de voir l'évolution de la qualité de l'application et montre les progrès de l'équipe en temps réel. Le plus souvent, ces outils sont livrés avec des modules de statistique très intéressants.

Bien sûr, utiliser un serveur d'intégration continue implique de se donner quelques règles de développements sans lesquelles l'intérêt de l'intégration continue est amoindri :

• la compilation doit être automatisée (ANT, MAVEN…), aucune intervention humaine ne doit être nécessaire pour compiler avec succès ;
• des commit réguliers du code source doivent être réalisés par l'équipe ;
• des tests automatiques doivent pouvoir être lancés (JUnit par exemple, couplé à ANT ou MAVEN) ;
• un responsable recevant les rapports doit vérifier que les personnes recevant les erreurs les corrigent. En d'autres termes, les résultats de l'intégration continue doivent être utilisés! Là, on tombe plus dans la gestion de projet…

Pour aller plus loin, l'excellent article de Martin Fowler(en anglais) : http://www.martinfowler.com/articles/continuousIntegration.html.

Continuons maintenant sur Cruise Control. En me basant sur quelques captures d'écran, je vais faire le tour de ses fonctionnalités les plus courantes, sans trop aller dans le détail, l'application étant très complète. Pour aller plus loin, consultez donc son site web: http://cruisecontrol.sourceforge.net/.

L'installation est des plus simples, vous avez le choix entre un fichier exe ou zip. L'exe étant pour Windows (c'est lui que j'ai choisi) le zip étant multiplateforme, l'outil étant écrit en JAVA. Après téléchargement à cette adresse: http://cruisecontrol.sourceforge.net/download.html, j'ai exécuté l'installation qui se fait toute seule. Ensuite, lancez Cruise Control (via le menu Programme ou via le fichier .bat installé) et tout fonctionne. Cruise Control est fourni avec une application d'exemple, il lance par défaut une application de reporting, un dashboard, un serveur JMX et tout ça accessible via un simple browser.

Si vous cherchez la simplicité, vous l'avez trouvée !

Lancez tout d'abord l'application de configuration de Cruise Control (CruiseConfig) qui est une application Java Webstart, ce qui est fort pratique, car vous pouvez alors la lancer depuis un ordinateur différent de votre serveur d'intégration. Vous obtenez alors cela:

Cette application vous permet de monitorer les différents projets définis et de les configurer en cliquant sur Server -> Configure Projects. C'est cette partie que nous allons voir plus en détail.

La configuration des projets de Cruise Control se trouve dans le fichier config.xml qui est à la racine du répertoire d'installation de Cruise Control. Son écriture est facilitée par l'application de configuration CruiseConfig qui permet de définir les différentes parties de ce fichier XML via une interface utilisateur simple.

On voit dans cette capture d'écran, l'interface de modification du config.xml qui liste les propriétés (possibilité de définir un fichier de propriété), les projets et les plugins (configuration par défaut d'un plugin, par exemple pour configurer par défaut ANT).

Pour configurer un projet, le principe est le suivant :

• modificationset : configurer le gestionnaire de source (source control manager) pour pouvoir lister les changements depuis la dernière compilation et mettre à jour ses sources ;
• schedule : configurer les tâches à lancer telles que la compilation ou le lancement des tests (ANT, MAVEN) ;
• log : configurer les fichiers de log du projet. Cruise Control se base uniquement sur les fichiers de logs générés lors de la compilation ou de l'exécution des tests ;
• publishers : permet de définir ce qu'il faut faire après une tâche (envoi de mails, copie de fichier…) ;
• listeners : permet de définir des éléments de contrôle du déroulement des tâches.

La première page du projet permet de définir des éléments globaux tels que le nom du projet, la nécessité d'avoir des modifications au sein du gestionnaire de source avant de lancer une tâche…

Tous les éléments de configuration sont expliqués grâce à un fichier d'aide HTML chargé en dessous.

IV-A. modificationset de type clearcase▲

Je n'ai utilisé que le modificationset de clearcase, donc c'est celui-ci dont je vais parler ici. Mais il en existe pour la plupart des types de gestionnaires de source du marché.

Le principe est de définir le gestionnaire de source pour que Cruise Control puisse mettre à jour ses sources (faire un update) et aussi savoir qui sont les contributeurs des dernières modifications, ces informations lui seront très utiles plus tard.

Les principales propriétés de configuration sont :

• QuietPeriod : période minimale en seconde d'inaction dans le gestionnaire de source avant de faire un update. Cela permet de ne pas faire d'update au milieu d'un checkin/commit ;
• ViewPath : chemin de la vue clearcase dans laquelle l'update se fait ;
• Branch : stream clearcase (si elle n'est pas précisée, les modifications listées par Cruise Control seront celles de toutes les streams !).

IV-B. schedule de type ant▲

Enfin, on entre dans le vif du sujet ! Les tâches à effectuer. C'est ici que l'on définit ce que va faire Cruise Control. Pour cela, tout simplement on peut appeler périodiquement des scripts ANT ou MAVEN (d'autres sont disponibles).

Les possibilités d'appel sont diverses: à une heure précise ou périodiquement (en seconde), on peut aussi définir des pauses ou des jours précis…

Quelques propriétés sont définies au niveau global du schedule :

• Interval : intervalle de la tâche (en secondes) ;
• ShowInProgress : affichage d'une barre de progression si supporté par le plugin.

Pour faciliter la définition des tâches dans les différents projets, j'ai défini une configuration globale pour ANT, pour Cruise Control on appelle cela définir une configuration d'un plugin (tout est plugin pour Cruise Control … et bien entendu on peut définir les siens en plus de ceux par défaut).

Ensuite, par projet, j'ai redéfini les propriétés qui m'intéressaient.

Explications des propriétés les plus utilisées :

• Taget : le target ANT appelé ;
• SaveLogDir : le répertoire dans lequel est mis le log de ANT (remarquez ici l'utilisation d'une variable de CruiseControl: project.name) ;
• AntHome : le répertoire d'installation d'ANT ;
• UseLogger : ANT utilisera un Logger au lieu de la console (conseillé pour des raisons de performance) ;
• UseDebug : si vous voulez lancer ANT en mode debug (attention aux performances!) ;
• UseQuiet : l'inverse de UseDebug… ;
• KeepGoing : lance ant avec l'option -keep-going ;
• Time : permet de définir à quelle heure le script est lancé, dans ce cas là, la propriété Interval est ignorée.

Une question est récurrente sur les forums : peut-on définir une expression de type 'Cron' pour lancer le schedule. Hélas, la réponse est non. Mais peut-être qu'au vu des fréquentes demandes à ce sujet, ce sera intégré dans une version ultérieure.

Bien que l'exemple ci-dessus soit basé sur ANT, on peut obtenir exactement la même chose en utilisant MAVEN, tant que les logs fournis par MAVEN sont bien mergés avec celui de la compilation de Cruise Control (voir la section suivante).

IV-C. log▲

Cruise Control définit un fichier de log XML unique pour chaque compilation de chaque projet.

On peut ensuite configurer le répertoire où Cruise Controle placera ce fichier de log et optionnellement, des fichiers de logs extérieurs que nous voudrions merger à ce fichier de log primaire (log ANT, JUNIT…)

Le snapshot me semble éloquent sans explications :)

L'application de reporting et le dashboard utilisent ce fichier de log XML pour présenter les données d'une compilation. Il est d'ailleurs lui-même accessible depuis ces applications.

IV-D. publishers▲

Un publisher permet, comme son nom l'indique de publier des données en fin de compilation.
Je vais ici évoquer deux publishers très utiles : l'artifact publisher et le l'htmlmail publisher.

IV-D-1. artifact publisher▲

L'artifact publisher permet, en fin de compilation, de publier dans un répertoire précis un fichier donné. Il permet par exemple de copier le JAR généré par ANT dans un répertoire donné. Ce fichier artifact sera ensuite accessible depuis l'application de reporting et le dashboard.

Les principales propriétés sont :

• File : le fichier à exporter (il faut utiliser soit File, soit Dir) ;
• Dir : le répertoire à exporter (il faut utiliser soit File, soit Dir) ;
• Dest : le répertoire de destination, Cruise control créera ensuite un sous répertoire par compilation et placera dedans le ou les fichiers à exporter ;
• PublishOnFailure : si oui ou non la publication doit se faire en cas de failure de la compilation.

IV-D-2. htmlmail publisher▲

Le grand intérêt de Cruise Control réside dans sa possibilité d'envoyer un mail automatique en fin de compilation. Ce mail pouvant se baser sur les utilisateurs ayant fait des modifications pour les informer qu'une compilation a été faite contenant leurs changements et du résultat de la compilation. C'est sans doute la fonctionnalité la plus utilisée de Cruise Control.

Tout d'abord, pour éviter trop de configuration dans chaque tâche mail de chaque projet, j'ai défini une configuration par défaut du plugin de mail.

Les principales propriétés sont :

• MailHost : l'adresse du serveur SMTP ;
• MailPort : le port du serveur SMTP si différent du port par défaut ;
• ReturnAddress : l'adresse qui va envoyer le mail ;
• DefaultSuffix : le suffixe qui permet de passer des utilisateurs du gestionnaire de source à son adresse mail. Par exemple, si vos utilisateurs s'appellent 'toto' et 'tata' et que votre DefaultSuffix est '@mondomaine.com', les emails seront envoyés à 'toto@mondomaine.com' et 'tata@mondomaine.com' (si vous ne pouvez passer du nom de l'utilisateur à l'adresse mail via un suffixe, vous pouvez définir un fichier liant chaque utilisateur à une adresse mail).

Ensuite on définit l'htmlemail du projet avec juste les propriétés manquantes.

Les principales propriétés sont :

• SubjectPrefix: le préfixe du sujet du mail. Cruise Control y ajoutera ensuite le numéro de compilation et le statut (success, failed, fixed - statut donné pour une compilation réussie après une compilation ratée) ;
• BuildResultUrl: l'URL mise en début de mail pour pouvoir consulter les résultats de la compilation.

IV-E. listeners▲

Permet de définir un listener (un 'écouteur', donc quelque chose qui écoute en temps réel) de la compilation. Utile pour suivre en temps réel la compilation.

Ici, j'ai utilisé un currentbuildstatuslistener qui se configure via la propriété File qui définit le fichier dans lequel le statut de la compilation est inscrit.

Cruise Control n'est pas livré avec une, mais plusieurs interfaces web. Cruise control, est livré avec deux interfaces que je vais appeler l'interface de reporting et le dashboard. Il faut savoir qu'en plus des interfaces web, Cruise Control est aussi livré avec une console JMX.

V-A. L'interface de reporting▲

La première page de l'interface de reporting donne la liste des différents projets configurés dans Cruise Control, en donnant le statut, la date de dernière compilation et permet l'accès aux pages de détail d'un projet. On peut aussi directement lancer une compilation forcée d'un projet, dans ce cas là, la compilation se fera même si aucune modification n'est détectée.

Un des endroits les plus intéressants de Cruise Control, on accède ici à toute l'information de toutes les compilations faites sur un projet (pas vraiment toutes les compilations, seules celles dont les données sont encore présentes sur le serveur). Toutes les informations affichées ici sont celles extraites du log de la compilation du projet (d'où l'importance du merge des fichiers JUnit dans le log de Cruise Control évoqué plus haut). Sur la première page, on a accès aux mêmes informations que celles envoyées dans le mail: un résumé de la compilation. Les pages suivantes donnant accès à plus de détails.

Détail des pages de détails

• Build Result : résumé de la compilation + lien vers les artifacts de compilation ;
• Test Result : accès aux détails des tests unitaires (JUnit par exemple) ;
• XML Log File : accès au log XML de la compilation
• Metrics : statistiques de compilation, comprend plusieurs gr ;aphiques tels que le pourcentage de build OK, les données de Checkstyle… ;
• Config : accès à la configuration du projet, permet de directement la modifier ;
• Control Panel : accès à la console JMX.

Ces pages de détails sont ce que l'on appelle des widgets, on peut facilement en ajouter, Cruise Control est livré avec quelques widget en plus (Panoticode et Checkstyle par exemple), mais vous pouvez aussi développer le vôtre propre. Toutes ces pages sont personnalisables par modification d'un fichier XSL, en effet, elles sont toutes générées depuis le fichier de log de la compilation par une transformation XSL.

V-B. Le dashboard▲

Le dashboard est une interface plus 'user-friendly' et graphique de reporting des compilations de Cruise Control, il est livré en complément de l'application de reporting classique. Moins complet, il donne un aperçu plus direct et peut être pratique si beaucoup de projets sont configurés. Il comprend en outre une barre d'outils à droite qui permet un accès rapide aux flux RSS, à l'application de configuration, à la console JMX et à Cruise Control Tray, un petit outil qui permet de suivre les compilations en barre de tâche (non testé personnellement).

Dans la même idée que dans l'application de reporting, des pages de détails permettent d'accéder aux informations détaillées d'une compilation.

Pour aller plus loin, le mieux est d'installer Cruise Control et de fouiller. Une fois familiarisé avec sa configuration grâce à ce tutoriel et à l'aide contextuelle, configurer le reste est très simple.

Les fonctionnalités de Cruise Control sont très complètes, quelques exemples de ce qui n'a pas été abordé :

• delete : création de tâches de suppression des fichiers générés par Cruise Control (permet de ne pas saturer les disques durs) ;
• pause : permet de définir des périodes de pause dans la compilation (éviter de compiler toute la nuit par exemple) ;
• always, onsuccess, onfailure : capacité étendue d'envoi de mails ;
• possibilité de mapper les utilisateurs du gestionnaire de source sur des adresses email via un fichier de propriété ;
• possibilité de redéfinir les XSL qui servent à envoyer les mails (donc possibilité de personnaliser les mails envoyés) ;
• possibilité d'ajouter des widgets à l'interface web de reporting ;
• …

• Site officiel : http://cruisecontrol.sourceforge.net/
• Très bon article d'introduction à l'intégration continue sur le site de Martin Fowler : http://www.martinfowler.com/articles/continuousIntegration.html
• L'article original sur mon blog : http://loicmathieu.free.fr/wordpress/?p=40

Je remercie tous les gens qui m'ont aidé dans la rédaction de cet article et spécialement :

• Ricky81, pour ses conseils et sa relecture technique ;
• Hikage, denisC et Baptiste Wicht, pour leur relecture technique ;
• RideKick, pour sa relecture orthographique ;
• Baptiste Wicht, pour sa relecture orthographique.