|
CruiseControl est un projet open-source offrant de multiples fonctionnalités pour l’intégration, que ce soit pour des développements Java ou .Net. Il est courant sur un projet d’être plusieurs développeurs avec des tâches de développement réparties. Dans le cycle de développement, la partie cruciale est l’intégration. C’est l’intégration qui permet de révéler les éventuelles erreurs et incompatibilités des différentes parties réalisées par chaque développeur de l’équipe.
CruiseControl permet d’automatiser cette phase d’intégration selon la succession des tâches suivantes :
- Récupération des fichiers sur le SCM (Source Code Management)
- Compilation du code source
- Création de l’archive de l’application (Ear, Jar, War, …)
- Déploiement de l’archive
- Exécution d’une suite de tests (Junit)
- Notification du résultat (Mail, rss, …)
L’architecture de CruiseControl se décompose en 2 modules :
- Reporting : c’est une application Web qui permet de visualiser les fichiers de logs, les archives et d’interagir avec le module suivant.
- Build Loop : c’est le cœur de CruiseControl qui permet de lancer les différentes tâches énoncées ci-dessus.
Voici un graphique issu du site de CruiseControl (http://cruisecontrol.sourceforge.net/) détaillant cette architecture :
L’intégration continue
Cruise Control reprend les principes du CI (Continuous Integration) : http://en.wikipedia.org/wiki/Continuous_Integration) qui est une pratique de l’XP (eXtreme Programming : http://en.wikipedia.org/wiki/Extreme_Programming). Le but de l’intégration continue réside dans le fait de vérifier que le code source modifié ne génère pas de régression. Cette pratique est à appliquer surtout lors d’un travail en équipe lorsque le code source est modifié par plusieurs collaborateurs. Il est donc nécessaire d’utiliser un système de contrôle de source (CVS, Subversion, Maven, …). Lorsque l’on parle d’intégration, cela signifie en réalité que le développeur, après la réalisation d’une tâche, effectue un build, puis teste son code. Lorsque les tests sont réussis, alors le développeur peut effectuer un "commit" de ses modifications. Ces dernières seront alors automatiquement prises en compte pour la réalisation de la compilation d’une version de l’application.
La phase de build peut se baser sur Ant et ne se contente pas seulement de la compilation des sources mais peut générer une documentation (Javadoc par exemple), …
L’intégration continue va donc bien plus loin que le fait de disposer uniquement d’une plateforme de building dédiée (night/daily-building). Le build automatique c’est bien, mais insuffisant.
Il existe ensuite plusieurs solutions pour réaliser des tests (qu’ils soient unitaires, de non régression, d’intégration, de monté en charges, …) sur vos applications. La partie des tests dans une application est primordiale. Les tests unitaires sont les plus facilement automatisables grâce à des frameworks comme JUnit, ils doivent être réalisés par les développeurs eux-mêmes. Certains diront même que les tests unitaires doivent être développés avant les développements au sein de l’application (que ce soit de l’évolution ou de la correction de bugs).
Le CI repose donc sur le fait de réaliser des tests de manière constante et non uniquement en fin du cycle de développement. Lorsqu'une tâche est terminée, un bug corrigé, la modification est immédiatement intégrée au produit complet. On évite ainsi la surcharge de travail liée à l'intégration de tous les éléments avant la livraison. Les tests automatisés facilitent grandement cette intégration : quand tous les tests passent, l'intégration est terminée.
Ce principe de base de l’XP impose que le code ne doit pas passer en Release avant que tout les UnitTests aient étés passés avec succès.
Le CI réduit de manière considérable le temps d’intégration tout simplement car les problèmes et les incompatibilités sont détectés de manière continue. CruiseControl reprend l’ensemble de ces principes du CI.
Configuration de CruiseControl
Il vous faudra tout d’abord télécharger CruiseControl à l’adresse suivante : http://cruisecontrol.sourceforge.net/download.html.
L’ajout d’un projet à CruiseControl se réalise très rapidement grâce au fichier de configuration nommé config.xml. Ce fichier se compose de plusieurs parties :
- Listeners : emplacement du fichier de statut (utilisé notamment par l’IHM pour déterminer à quelle étape nous sommes).
- Bootstrappers : informations pour la récupération des sources du SCM.
- Modificationset : comportement lors de la modification du code source du répertoire local.
- Schedule : configuration du build (temps entre 2 builds, type de scripts : Ant, Maven, Nant, …)
- Log : définition de l’emplacement des fichiers de logs
- Publishers : tâches exécutées après le build, que celui-ci ait réussi ou non.
Voici un exemple de fichier config.xml :
<!-- ########## Projet SaturneDSL ############# -->
<project name="SaturneDSL">
<property name="main.app" value="ProjetSaturne" />
<property name="main.module" value="Saturne" />
<property name="ear.file" value="SaturneDSL.ear" />
<listeners>
<currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
</listeners>
<bootstrappers>
<antbootstrapper buildfile="completel_custom_tasks.xml" target="removelocalprojectrepository cvsbootstrapper cpWliLibsToWliApp cpWebLibsToWebApps">
<property name="project.path" value=" ${cvs.local.repository}/${main.app}"/>
<property name="workshop.file.work" value="${cvs.local.repository}/${main.app}/src/${main.module}/Saturne.work"/>
<property name="cvs.property.file" value=" ${cvs.local.repository}/${main.app}/src/${main.module}/cvs.properties"/>
<property name="project.name" value="${main.app}"/>
<property name="all.projects.path" value=" ${cvs.local.repository}"/>
<property name="project.wli.libs.dir" value=" ${cvs.local.repository}/${main.app}/src/${main.module}/APP-INF/lib"/>
<property name="userlib.dir" value="userLibs"/>
<property name="project.web.libs.dir" value=" ${cvs.local.repository}/${main.app}/src/ ${main.module}/SaturneAdministrationWeb/WEB-INF"/>
</antbootstrapper>
</bootstrappers>
<modificationset quietperiod="30">
<alwaysbuild/>
</modificationset>
<schedule interval="86400"> <!-- 86400 secondes = 24h -->
<ant buildfile="projects/${main.app}/src/${main.module}/exported_build.xml">
<property name="output.dir" value="${output.dir}" />
</ant>
</schedule>
<log>
<merge file="${cvs.local.repository}/${project.name}/target/test-results.xml"/>
</log>
<publishers>
<onsuccess>
<antpublisher buildfile="completel_custom_tasks.xml" target="createartifact removelocalprojectrepository">
<property name="archive.full.path" value="${output.dir}/${ear.file}" />
<property name="base.artifact.dir" value="artifacts" />
<property name="project.name" value="${project.name}" />
<property name="project.path" value="${cvs.local.repository}/${main.app}"/>
<property name="weblogic.home" value="${weblogic.home}" />
</antpublisher>
</onsuccess>
<htmlemail>
<always address="m.vialette@completel.fr"/>
<failure address="m.vialette@completel.fr"/>
</htmlemail>
<onfailure>
<antpublisher buildfile="completel_custom_tasks.xml" target="removelocalprojectrepository">
<property name="project.path" value="${cvs.local.repository}/${main.app}"/>
</antpublisher>
</onfailure>
</publishers>
</project>
Pour obtenir plus d’informations sur le fichier config.xml, vous pouvez consulter l’aide à l’adresse suivante : http://cruisecontrol.sourceforge.net/main/configxml.html
Ce fichier de configuration permet donc d’activer et de désactiver de nombreuses fonctionnalités de CruiseControl. Il est possible de coupler CruiseControl à de nombreux autres outils :
Un outil de configuration graphique (http://cc-config.sourceforge.net/index.html) pour CruiseControl est également disponible et facilement accessible via JavaWebStart.
L’interface Web
Cette IHM vous permet de visualiser les différents projets que vous avez configurés dans le fichier config.xml. Cliquez sur le lien « Build » du projet que vous souhaitez compiler, le statut indique alors « building » en gras. Dans le cas où un projet n’a pas correctement réalisé l’ensemble des tâches, dans la colonne « Last failure » nous avons en rouge la notification de la date d’erreur. Voici un exemple de l’écran de récapitulatif des projets gérés par CruiseControl :
En cliquant sur le nom du projet, vous accédez à un écran spécifique. Cette partie vous permet de visualiser l’ensemble de builds ayant étés réalisés ainsi que le rapport des builds. En fonction de la configuration de votre projet, le rapport visible sur l’écran suivant peut également être émis par mail :
Lorsqu’un build s’est déroulé correctement, vous pouvez récupérer l’archive construite grâce au lien « Build Artifacts ». Vous accédez alors à une page Web similaire à celle-ci où vous retrouverez votre fichier généré :
Si vous souhaitez aller plus loin dans la configuration de votre projet, vous pouvez utiliser l’onglet « Control Panel » de l’écran précédant. Dans cette partie de l’application Web, JMX (Java Management Extensions : http://en.wikipedia.org/wiki/Java_Management_Extensions) est utilisé pour que l’application Web contacte le module « Build Loop ».
CruiseControl utilise un système d’incrémentation du dernier digit du label visible sur l’écran principale.
Vous pouvez également modifier la fréquence du build grâce à cet onglet. Voici un exemple du control panel :
Cruise Control Monitor
Un plugin Firefox nommé Cruise Control Monitor (http://www.md.pp.ru/mozilla/cc/) est même disponible pour accéder encore plus rapidement à certaines opérations de l’IHM Web de CruiseControl. Ce plugin s’intègre à Firefox par l’intermédiaire d’une icône en bas à droite du navigateur. Cette icône est verte lorsque tous les projets gérés par CruiseControl ont passés l’ensemble des tâches du build. Dans le cas contraire, dès qu’un projet échoue, l’icône devient immédiatement rouge. Un simple survol de l’icône vous permet de visualiser l’ensemble des projets :
Selon la configuration de CruiseControl, les projets effectuent la tâche de build toutes les N-secondes. Vous pouvez également exécuter la tâche de build de manière explicite via l’interface Web. Grâce à ce plugin Cruise Control Monitor, vous pouvez également lancer l’exécution de cette tâche par l’intermédiaire du menu contextuel du plugin :
Cependant, une petite précision doit être apportée : les options « Pause » et « Resume » ne vous permettent pas d’interrompre un build. Vous activez l’option « Pause » dans le cas où vous ne souhaitez plus qu’un build soit réalisé, que ce soit de manière automatique ou explicite. Pour réactiver le build, il vous faudra utiliser l’option « Resume ».
Il fut initialement créé pour le monde Java et ayant tellement de succès, une déclinaison pour .Net est apparue. Vous trouverez des informations sur ce projet porté pour .Net à l’adresse suivante : http://ccnet.thoughtworks.com/.
En effet, le concept de CI est valable quelque soit le langage de développement.
Conclusion
A Completel, grâce à CruiseControl nous pouvons piloter la récupération des sources d’un projet hébergé sous CVS, créer l’archive Ear, effectuer le déploiement de manière automatique sur un serveur de développement et exécuter des tests JUnit / JProcessUnit. L’envoie d’un rapport par mail permet de ne pas nous soucier de ces phases de construction d’EAR et d’intégration. En cas d’erreur, nous vérifions les fichiers journaux (logs XML) fournis par CruiseControl afin d’identifier de manière rapide la source du problème.
La mise en place d’une telle démarche assure la bonne qualité des applications.
Voici un exemple de l’infrastructure que vous pouvez utiliser avec CruiseControl :
|
