Dernièrement, j’ai essayé un serveur d’intégration continue : Cruise Control.
Je vais donc vous en parler ici.

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 tout les membres. Ensuite, une compilation automatique doit être lancé pour vérifier les éventuelle erreurs de compilation du projet puis si possible les tests unitaires doivent aussi être lancée.

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 tout ses membres. La plupart des outils d’intégration continue sont capable de faire les actions suivantes :

• lancement d’une intégration périodique (toutes le heures par exemple)
• mise à jour du code depuis un gestionnaire de code source
• compilation du code source
• lancement des tests unitaires
• envoi de mail automatiques au personnes concerné (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 serveur d’intégration continue se basant sur ANT ou MAVEN (ou les deux), ils permettent une liste quasi infinie d’actions possible.

Les bénéfices d’une intégration continue sont indéniable, elle 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é à un lancement des tests, elle 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é avec des modules de statistique très intéressant.

Bien sure , utiliser un serveur d’intégration continue implique de se donner quelques règles de développements sans lesquels l’intérêt d’une intégration continue est amoindrie:

• La compilation doit être automatisé (ANT, MAVEN, …), aucune intervention humaine doit être nécessaire pour avoir une compilation réussie
• Des commit régulier du code source doivent être réalisé par l’équipe
• Des tests automatiques doivent pouvoir être lancé (JUNIT et ANT ou MAVEN par exemple)
• Un responsable doit recevoir les rapports et vérifier que les personnes recevant les erreurs les corrigent. En d’autre terme, les résultat de l’intégration continue doivent être utilisé! Là, on arrive plus dans la gestion de projet.

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

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

1. L’application de configuration

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éfinie et de les configurer en cliquant sur Server -> Configure Projects. C’est cette partie que nous allons voire plus en détail.

2. Configuration d’un projet

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 via une interface utilisateur simple les différentes parties de ce fichier XML.

On voit dans cette capture d’écran, l’interface de modification du config.xml qui liste les propriété (possibilité de définir un fichier de propriété), les projets et les plugin (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 control pour pouvoir lister les changements depuis la dernière compilation et mettre à jour ses sources.
• schedule : configurer les tâches à lancer tel que la compilation ou le lancement des tests (ANT, MAVEN)
• log : configurer les fichiers de logs 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 quoi 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 tel que le nom du projet, la nécessité d’avoir des modifications au sein du gestion de source avant de lancer une tâche, …

Tout les éléments de configuration sont expliqué grâce à un fichier d’aide HTML changé en dessous.

2.1 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 type de gestionnaire 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 contributeur des dernières modifications, ces informations lui seront très utile plus tard.

Les principales propriété 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é, les modifications listé par Cruise Control seront toutes stream!)

2.2 schedule de type ant

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

Les possibilité d’appel sont divers: à 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éfinie au niveau global du schedule:

• Interval : interval de la tâche (en seconde)
• ShowInProgress : affichage d’une barre de progression si supporté par le plugin

Pour faciliter la définition des taches dans les différents projets, j’ai définit une configuration globale pour ANT, pour Cruise Control on appel cela définit une configuration d’un plugin (tout est plugin pour Cruise Control … et bien sur on peut définir les siens propre en plus de ceux par défaut)

Ensuite, par projet, j’ai redéfinit juste les propriété qui m’intéressaient

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

• Taget: la target ANT appelée.
• 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 de 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

2.3 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 éloquant sans explications 🙂

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

2.4 publishers

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

2.4.1 artifact publisher

L’artifact publisher permet, en fin de compilation, de publier dans un repertoir 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.

2.4.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é faites contenant leurs changements et du résultat de la compilation. C’est sans doute la fonctionnalité la plus utilise de Cruise Control.

Tout d’abord, pour éviter trop de configuration dans chaque tache mail de chaque projet, j’ai définit 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é à ‘toto@mondomaine.com’ et ‘tata@mondomaine.com’

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

Les principales propriétés sont:

• SubjectPrefix: Le prefix du sujet du mail. Cruise Control y ajoutera ensuite le numéro de compilation et le statuts (success, failed, fixed – statuts 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.

2.5 listeners

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

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

3 Aller plus loin

Pour aller plus loin, le mieux est d’installer Cruise Control et de fouiller. Une fois familiariser 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 tache de suppression des fichiers généré par Cruise Control
• pause: permet de définir des période de pause dans la compilation(éviter de compiler toute la nuit par exemple)
• always, onsuccess, onfailure: capacité étendue d’envoi de mail
• possibilité de mapper les utilisateurs du gestionnaire de source sur des adresse email via un fichier de propriété
• …

*** UPDATE ***

J’ai écrit un article sur développez.com, inspiré de celui-ci (et enrichi).
http://loic-mathieu.developpez.com/conception/article/cruise-control/