Intégration continue avec Hudson

L'intégration continue est devenue une pratique courante pour les équipes soucieuses de garantir la qualité du code tout au long du cycle de vie du développement logiciel. Dans cet article, Nicholas Whitehead présente Hudson, un serveur CI open source populaire. Apprenez à configurer un serveur Hudson dans votre environnement de développement d'applications (des exemples sont donnés pour Windows XP avec Tomcat 6 ou Ubuntu Linux avec JBoss AS), obtenez un aperçu des nombreuses options de configuration fournies par Hudson, puis implémentez une construction automatisée, un test, et processus de rapport pour un exemple de projet. Niveau: débutant

L'intégration continue (CI) est un ensemble de pratiques destinées à faciliter et stabiliser le processus de création de versions logicielles. CI assiste les équipes de développement dans les défis suivants:

  • Automatisation de la construction logicielle : avec CI, vous pouvez lancer le processus de construction d'un artefact logiciel en appuyant simplement sur un bouton, selon un calendrier prédéfini ou en réponse à un événement spécifié. Si vous souhaitez créer un artefact logiciel à partir de la source, votre processus de génération n'est pas lié à un IDE, un ordinateur ou une personne spécifique.
  • Vérification continue et automatisée de la construction : un système CI peut être configuré pour exécuter en permanence des compilations à mesure que le code source nouveau ou modifié est archivé. Cela signifie que si une équipe de développeurs de logiciels vérifie périodiquement le code nouveau ou modifié, le système CI vérifie en permanence que la compilation n'est pas interrompu par le nouveau code. Cela réduit la nécessité pour les développeurs de vérifier les uns avec les autres les modifications apportées aux composants interdépendants.
  • Test de build automatisé en continu : une extension de la vérification de build, ce processus garantit que le code nouveau ou modifié ne provoque pas l'échec d'une suite de tests prédéfinis sur les artefacts générés. Dans la vérification et les tests de build, les échecs peuvent déclencher des notifications aux parties intéressées, indiquant qu'une build ou certains tests ont échoué.
  • Automatisation des procédures post-construction : le cycle de vie de construction d'un artefact logiciel peut également nécessiter des tâches supplémentaires qui peuvent être automatisées une fois la vérification et les tests de construction terminés, comme la génération de la documentation, l'empaquetage du logiciel et le déploiement des artefacts dans un environnement en cours d'exécution ou dans un référentiel de logiciels. De cette manière, les artefacts peuvent être rapidement mis à la disposition des utilisateurs.

Pour implémenter un serveur CI, vous avez besoin, au minimum, d'un référentiel de code source accessible (et du code source qu'il contient), d'un ensemble de scripts et de procédures de génération, et d'une suite de tests à exécuter sur les artefacts générés. La figure 1 présente la structure de base d'un système CI.

Les composants du système entrent en jeu dans l'ordre suivant:

  1. Les développeurs vérifient le code nouveau et modifié dans le référentiel de code source.
  2. Le serveur CI crée un espace de travail dédié pour chaque projet. Lorsqu'une nouvelle génération est demandée ou planifiée, la source est extraite du référentiel dans cet espace de travail, où la génération est ensuite exécutée.
  3. Le serveur CI exécute le processus de génération sur l'espace de travail nouvellement créé ou actualisé.
  4. Une fois la construction terminée, le serveur CI peut éventuellement appeler la suite de tests définie sur les nouveaux artefacts. Si la compilation échoue, les personnes enregistrées peuvent être notifiées par e-mail, messagerie instantanée ou toute autre méthode.
  5. Si la construction réussit, les artefacts sont conditionnés et transmis à une cible de déploiement (telle qu'un serveur d'applications) et / ou stockés en tant que nouvel artefact versionné dans un référentiel de logiciels. Ce référentiel peut faire partie du serveur CI, ou peut être un référentiel externe, tel qu'un serveur de fichiers ou un site de distribution de logiciels comme Java.net ou SourceForge. Le référentiel de code source et le référentiel d'artefacts peuvent être séparés, et il est en fait possible d'utiliser certains serveurs CI sans aucun système de contrôle de source formel.
  6. Les serveurs CI ont généralement une sorte de console où les projets peuvent être configurés et débogués, et où des demandes peuvent être émises pour des opérations telles que des générations immédiates ad hoc, la génération de rapports ou la récupération d'artefacts générés.

Hudson: un serveur d'intégration continue

L'intégration continue a gagné en popularité au cours des dernières années et aujourd'hui, vous avez le choix entre plusieurs serveurs CI, à la fois commerciaux et gratuits. J'avais personnellement utilisé quatre serveurs CI avant qu'un collègue ne me recommande de regarder Hudson. J'ai été immédiatement impressionné par cela. Alors que j'ai d'abord supposé que Hudson n'était pas bien connu, une enquête sur le site Java Power Tools le montre comme le serveur CI le plus utilisé parmi les répondants, recueillant (au moment de la rédaction de cet article) 37,8% de tous les votes.

SCM pris en charge

Hudson a intégré la prise en charge de Subversion dès la sortie de la boîte, et seule une petite quantité de configuration est nécessaire pour s'intégrer à CVS, en supposant que le client CVS est installé sur l'hôte Hudson. Plusieurs autres solutions de gestion de code source (SCM) sont prises en charge sous la forme de plugins Hudson. Au moment d'écrire ces lignes, les SCM suivants sont pris en charge:

  • Accurev
  • BitKeeper
  • ClearCase
  • Git
  • Mercuriel
  • Forcément
  • StartTeam
  • Team Foundation Server
  • Visual SourceSafe
  • URL SCM (un plugin SCM spécial qui permet l'utilisation d'URL pour SCM)

Dans cet article, j'utiliserai Subversion et le référentiel source sur Java.net, vous n'aurez donc pas besoin d'installer l'un de ces plugins. (En passant, je connais quelqu'un qui travaille sur un plugin MKS SourceIntegrity Hudson. Si cela vous intéresse, envoyez-moi un e-mail.)

Hudson est un produit gratuit et open source hébergé sur Java.net. Il a été initialement écrit par Kohsuke Kawaguchi, un ingénieur de Sun Microsystems, qui a annoncé sa sortie sur son blog en février 2005. Hudson a depuis eu environ 154 versions.

Voici quelques-unes des raisons pour lesquelles j'aime Hudson et pourquoi je vous le recommanderais, sauf exigences inhabituelles:

  • De tous les produits CI que j'ai utilisés, c'est de loin le plus simple à installer et à configurer.
  • Ses interfaces utilisateur basées sur le Web sont très conviviales, intuitives et réactives, fournissant dans de nombreux cas un retour immédiat activé par Ajax sur les champs de configuration individuels.
  • Hudson est basé sur Java (ce qui est utile si vous êtes un développeur Java) mais ne se limite pas à la création de logiciels basés sur Java.
  • Hudson est proprement composant et offre une API d'extensibilité bien définie et documentée sous la forme de plugins Hudson. Cela a conduit à son tour à une grande bibliothèque de plugins Hudson qui étendent les fonctionnalités du serveur; ceux-ci sont disponibles gratuitement et installables à partir de la console Hudson.

Installation de Hudson: Windows XP ou Ubuntu Linux

Pour utiliser Hudson, vous aurez besoin d'un système de contrôle de source accessible et pris en charge (voir la barre latérale «SCM pris en charge» pour une liste), d'une source pouvant être intégrée dans un artefact et d'un script de construction fonctionnel. Au-delà de cela, tout ce dont vous avez vraiment besoin pour installer et configurer un serveur Hudson fonctionnel est une installation de Java, version 1.5 ou supérieure, et le fichier d'installation Hudson, qui se présente sous la forme d'une archive Web Java EE (WAR). Vous pouvez démarrer le serveur très simplement en utilisant la ligne de commande suivante:

C:\hudson> java -jar hudson.war

Il est probablement plus courant, cependant, de déployer Hudson sur un conteneur de servlet Java basé sur les spécifications Servlet 2.4 et JSP 2.0, comme GlassFish, Tomcat, JBoss ou Jetty. Dans les sections suivantes, je vais vous guider à travers deux scénarios d'installation Hudson: un utilisant Tomcat 6 sur Windows XP et un autre utilisant JBoss 4.2.3 sur Ubuntu Linux. (JBoss AS 5.0 a été publié après la date de soumission de cet article.)

Installation de Hudson: Tomcat 6 et Windows XP

Je suppose que vous avez déjà la version 1.5 ou supérieure de Java installée sur votre machine Windows XP. En suivant les étapes ci-dessous, vous installerez Tomcat 6.0.18 à l'aide du programme d'installation du service Windows, de sorte que Hudson démarre immédiatement après le démarrage de Windows XP et s'exécute en arrière-plan même si aucun utilisateur n'est connecté. Le fichier de téléchargement pour Tomcat est apache-tomcat- 6.0.18.exe, que vous devez exécuter pour commencer l'installation de Tomcat.

L'installation de Tomcat vous invite à sélectionner les options d'installation. Veillez à sélectionner les options personnalisées , puis le service , comme illustré à la figure 2, afin que Tomcat s'exécute en tant que service.

Ensuite, sélectionnez un répertoire dans lequel vous souhaitez installer Tomcat, comme illustré dans la figure 3. Je vous recommande vivement de choisir un répertoire sans espaces. Vous pourrez me remercier plus tard.

Maintenant, l'installateur vous demandera sur quel port vous souhaitez écouter. La valeur par défaut est le port 8080, ce qui est probablement très bien; assurez-vous simplement que vous n'avez pas d'autre application utilisant ce port. Si vous le faites, Tomcat ne démarrera pas correctement. Il vous sera également demandé de fournir un nom d'utilisateur et un mot de passe d'administrateur Tomcat. Tout cela est illustré à la figure 4.

Le programme d'installation vous demandera alors de fournir l'emplacement du JRE Java que vous avez installé. Comme vous pouvez le voir sur la figure 5, j'ai utilisé Sun Java 1.6.0_07.

Une fois que vous avez cliqué sur Installer , l'installation devrait se terminer et le service commencera à s'exécuter. Vous pouvez vous assurer que Tomcat fonctionne correctement en pointant votre navigateur Web vers // localhost: 8080 (en remplaçant le nom ou l'adresse IP approprié par localhost si vous n'utilisez pas de navigateur Web fonctionnant sur l'ordinateur sur lequel Tomcat est installé). La page Web affichée doit ressembler à la capture d'écran de la figure 6.

Maintenant, pour installer Hudson, copiez le fichier hudson.war dans le sous-répertoire webapps de votre répertoire d'installation Tomcat. Si vous avez utilisé le même répertoire d'installation illustré dans la figure 3, ce serait C: \ Tomcat6 \ webapps. Tomcat déploiera à chaud les fichiers WAR, mais la chose la plus simple à faire maintenant est de redémarrer Tomcat. Il y a deux façons de faire ça. La première consiste à ouvrir un shell DOS et à saisir les commandes suivantes:

 C:\Tomcat6>net stop Tomcat6 C:\Tomcat6>net start Tomcat6

The second option is to open the Services applet. This applet can be found in the Administrative Tools group in the Control Panel, which can be located by clicking the Start button on the Windows toolbar, then selecting Settings and then Control Panel. In the Services applet, locate the service named Apache Tomcat and then click the Restart button. This is illustrated in Figure 7.

Hudson should now be installed. You can verify this by pointing your Web browser to //localhost:8080/hudson. The main Hudson screen is shown in Figure 8.

That's all there is to it! If you're comfortable with an application development environment based on Windows XP and Tomcat, you're all set. If you prefer a system running JBoss and Ubuntu Linux, read on.

Installing Hudson: JBoss 4.2.3 on Ubuntu Linux 8.04 (Hardy Heron)

To install Sun Java 1.6 on Ubuntu, open a shell and execute the following command:

 sudo apt-get install sun-java6-jdk

When issuing a sudo command, you will be prompted to enter your password.

Note that there are several ways to install JBoss; in the technique outlined here, you'll create a dedicated jboss user. This is considered a best practice, and is preferable to installing JBoss in your own home directory. The procedure outlined here has been condensed from a useful description at the Ubuntu forums.

First, you need to download the JBoss 4.2.3.GA package. Look for the file named jboss-4.2.3.GA.zip.

Next, you will need to create a user, a home directory, and a group, all named jboss. The group is a convenience not explored in this article; it will allow you to extend JBoss privileges to other users on your Ubuntu server.

Listing 1 shows the commented commands to create the jboss home directory, user, and group, and then install the JBoss server. Some commands are prefixed with sudo because they are root-privileged commands.

Listing 1. Creating the jboss account and installing the server

echo Create the jboss group sudo groupadd jboss echo Create the jboss user, define bash as the user's default shell and /home/jboss as the home directory echo and make the user jboss part of the group jboss sudo useradd -s /bin/bash -d /home/jboss -m -g jboss jboss echo Copy the jboss-4.2.3.GA file to /home/jboss or download directly into that directory sudo mv jboss-4.2.3.GA /home/jboss echo Change the owner of the file to jboss sudo chown jboss:jboss /home/jboss/jboss-4.2.3.GA echo Log into the jboss account sudo su jboss echo Go to the jboss home directory cd ~ echo Unzip the file jboss-4.2.3.GA unzip jboss-4.2.3.GA echo Create a symbolic link "jboss" for "jboss-4.2.3.GA". echo This allows you to change JBoss versions with minimal changes ln -s jboss-4.2.3.GA jboss

If the unzip command is not already installed, enter the following command (while logged in as a sudo-enabled user) to install it:

Sudo apt-get install unzip

The JBoss server is now basically installed. You could start the server using the following command:

/home/jboss/jboss/bin/run.sh

Dans cet exemple, cependant, vous installerez à la place un script de démarrage automatique afin que le service démarre automatiquement au démarrage de l'hôte. Le téléchargement de JBoss est fourni avec trois scripts int.d différents, mais chacun doit être modifié; vous pouvez télécharger le script jboss-init.sh, qui permettra le démarrage et l'arrêt automatiques du serveur. Exécutez ensuite les commandes indiquées dans le listing 2.