Article paru dans la newsletter #20 – Ete 2007

Un serveur d’intégration continue permet d’automatiser la reconstruction régulière d’une application afin de détecter le plus régulièrement possible des régressions potentielles. Le serveur d’intégration continue va régulièrement récupérer la dernière version du code source et exécuter des scripts de construction, plus potentiellement des jeu de tests automatisés, voire même déployer l’application, etc. L’équipe projet est alors notifiée automatiquement par mail des problèmes détectés.

Il existe un grand nombre d’outils d’intégration continue, avec des fonctionnalités plus ou moins larges. Certains sont payants et un bon nombre sont gratuits et/ou open-source. Le plus connu (au moins dans les domaines abordés par Valtech) est Cruise Control. Un certain nombre d’outils d’intégration continue sont listés ici :
http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Feature+Matrix

Hudson fait partie des petits derniers dans cette gamme d’outils et semble assez prometteur.
C’est un outil gratuit (dans les javatools de java.net). Il est très simple à installer, en version standalone ou comme webapp dans un container tel que tomcat (ce qui est le cas d’un grand nombre d’outils d’intégration continue).
L’interface web est simple à utiliser et assez intuitive, la prise en main est très rapide. On peut réellement configurer l’intégration continue d’un projet existant en quelques minutes sans connaître l’outil.
Toutes les tâches d’administration ou de configuration se font via la console web. Il n’est pas nécessaire d’accéder à la machine serveur d’intégration pour rajouter un projet ou changer une configuration.
Ce point différentie assez Hudson de Cruise Control et facilite l’utilisation de Hudson de façon transverse à plusieurs projets (on gère une seule machine serveur mutualisée). Avec Cruise control, on a plutôt tendance à avoir une installation de Cruise Control pour chaque projet et les membres d’équipe accèdent directement à leur machine d’intégration continue.

Cette mutualisation de l’intégration continue (et de l’usine logicielle en général) est une problématique que j’ai vu évoquée récemment chez plusieurs clients, souvent par architectes ou managers, qui souhaitent homogénéiser un « portefeuille » de projets. La plupart des nouveaux outils d’intégration continue font des efforts dans ce sens et fournissent en général une configuration par interface web. (Il n’y a pas d’outil magique et il reste toujours des limitations lorsqu’on veut avoir une usine logicielle transverse).

La vue principale d’Hudson est un tableau de bord affichant les différents projets gérés en intégration continue et leur statut. On peut ensuite aller examiner le détail de chaque build.
Hudson permet des notifications par email ou par flux RSS, par projet ou de façon globale. Il permet très simplement la publication de pages web générées lors du build (typiquement javadoc ou site web généré par maven).
Par défaut, l’outil publie aussi des informations sur chaque build : métriques simples sur les tests JUnit, liste des fichiers modifiés entre deux builds, évolution du temps d’exécution de build.

D’un point de vue intégration, l’architecture d’Hudson semble très bien faite et permet d’envisager beaucoup d’options d’intégration avec divers outils.
Hudson propose un mécanisme de plugin permettant de rajouter des fonctionnalités dans le serveur d’intégration continue (par exemple la possibilité de configurer un timeout de build). Il existe déjà un certain nombre de plugins parmi lesquels on peut noter un plugin JIRA et un plugin Trac (tous les chemins mènent à Trac !) permettant de suivre les liens entre un bug, le ou les fichiers commités corrigeant le bug et les builds Hudson associés.
Hudson fournit aussi une API remote (de type ReST) permettant à des outils externes de s’intégrer à Hudson. Il existe par exemple un plugin Eclipse pour Hudson utilisant cette API.
Pour une utilisation intensive en mode multi-projet, l’outil permet une configuration multi-serveurs avec un serveur master et des slaves vers lesquels sont délégués les builds des différents projets.

En point à améliorer, il est important de noter qu’aujourd’hui, Hudson ne s’intègre qu’avec CVS ou Subversion (facteur très limitant en fonction des contextes clients). Ce point sera vraisemblablement amélioré rapidement par des plugins spécifiques à tel ou tel système de gestion de version.
L’outil est encore dans ses premières versions et il arrive qu’une page web “plante” lorsqu’on modifie la configuration d’un projet. Il faut espérer que ce genre de problème sera rapidement corrigé dans les versions à venir.
Ce point ne me semble pas bloquant pour l’utilisation d’Hudson, dans des contextes standards de projet ou la configuration de l’intégration continue est rarement une mécanique parfaitement huilée.

Autre point qui pourrait être amélioré pour une mise en œuvre à grande échelle de façon transverse aux projets : la gestion d’utilisateurs et de droits de configuration par projets. Hudson par défaut permet à n’importe qui de modifier les configurations des projets. On peut intégrer Hudson à un mécanisme de login fourni par un conteneur web, afin d’authentifier les utilisateurs.
Cependant, Hudson n’a pas aujourd’hui de mécanisme permettant de préciser des droits spécifiques par projet. (C’est une fonctionnalité qui est fournie dans les versions payantes de certains outils).

Hudson a été utilisé sur le cours USIL au catalogue de Valtech Training, en particulier pour sa simplicité et rapidité de mise en oeuvre.

http://hudson.gotdns.com/wiki/display/HUDSON/Use+Hudson
https://hudson.dev.java.net

Guillaume Tardif

Tags: Outils

This entry was posted on Thursday, June 28th, 2007 at 1:31 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.