Nous avons mis en place l’intégration continue dans sa forme primitive. Elle permet de lancer la construction du projet régulièrement afin de s’assurer que tout compile parfaitement. SI l’intégration continue est essentielle dans un environnement collaboratif, il existe d’autres outils à disposition du chef de projet ou du responsable Software Factory pour renforcer l’esprit d’équipe et l’échange d’information. En fonction de la taille de l’équipe il conviendra de bien choisir la fréquence et le canal de diffusion de l’information.
Le canal le plus courant est .. la parole. C’est une évidence mais qui trouve sa limite quand l’équipe dépasse 3 à 5 personnes ou quand elle est distribuée géographiquement. Des dispositifs comme la messagerie instantanée peuvent alors prendre le relais ou bien la messagerie électronique quand le décalage horaire entre les membres de l’équipe empêche la communication en temps réel. Communiquer mais pour dire quoi ? Dans le cas particulier d’échange d’information du genre “tiens j’ai envie d’ajouter une classe ici pour faire ceci ou cela”, l’esprit d’initiative de chacun sera mis à contribution. Par contre il y a un certain nombre de cas où il est tout à fait possible d’automatiser le flux d’information.
Signaler les modifications des sources
Les modifications de sources est le premier cas. Il est important que tout membre de l’équipe sache les évolutions qui surviennent dans les sources du projet. Cette idée de propriété collective du code prônée par Extreme Programming permet à tous d’avoir un regard sur l’ensemble du code. Nous allons donc mettre en place un envoi de mail automatique dés qu’une modification survient dans le référentiel de source.
L’implémentation de cette fonctionnalité avec subversion peut se faire par le biais des “hook” qui sont des scripts appeler par subversion quand des opérations sont effectuée comme par exemple à chaque commit. Il suffit d’installer le paquet subversion-tools qui fournit le script /usr/share/subversion/hook-scripts/commit-email.pl. Aller dans le répertoire qui contient le référentiel de source pour effectuer les actions suivantes:
- renommer le fichier <mon_repo>/hooks/post-commit.tmpl en post-commit
- activer le droit d’execution au fichier post-commit
- ajouter les adresses mails à la fin de la commande qui se trouve à la fin du fichier pos-commit : il sera bon d’utiliser une liste de diffusion
Cette configuration est spécifique au référentiel, donc si on a dans le même référentiel plusieurs projets, des mails vont être envoyés aux adresses quelque soit le projet sur lequel intervient le commit.
Subversion peut soit utiliser sendmail ou un serveur smtp. Cela se configure dans le fichier /usr/share/subversion/hook-scripts/mailer/mailer.conf:
- renommer le fichier /usr/share/subversion/hook-scripts/mailer/mailer.conf.example en mailer.conf
- dans le fichier mailer.conf décommenter soit mail_command soit smtp_hostname,smtp_username, smtp_password
Cette configuration basique peut être améliorée en ajoutant des filtres sur les projets, les utilisateurs etc.
Rapport de construction
Tandis que les mails de commit permettent un suivi très fin des activités sur le projet, le rapport de construction donne une vision un peu plus haute en étant moins fréquente et en offrant potentiellement des rapports d’audit de code.
Continuum est fournit avec plusieurs connecteurs (mail, IRC, MSN…) pour notifier le résultat des constructions. L’envoi de mail est le connecteur le plus facile à utiliser ne nécessitant qu’une adresse mail principale que l’on pourra choisir comme une liste de diffusion.
Continuum utilise le protocole SMTP pour envoyer les mails, il faudra configurer le serveur dans le fichier <continuum>/conf/jetty.xml
Le site vitrine du projet
Ce canal de communication permet de faire la promotion du projet au sein de l’organisation ou même au niveau de tout interne en offrant toutes les informations sur le projet pour toutes les audiences: utilisateurs, développeurs, assurance qualité. Le site du projet est l’élément primordiale de la documentation d’un projet gérée avec Maven. Il s’agit même pour moi de l’unique source de toute documentation sur un projet puisqu’il offre la documentation technique du projet ainsi que tout les rapports d’audit sur le code.
La mise en place du site vitrine suppose au moins l’existence d’un serveur web. Le choix du serveur web se fait naturellement en prenant apache qui s’installe avec synaptique : choisir le paquet apache2.
Notre environnement de développement devant simuler au environnement réelle multi-developpeur, nous allons mettre en place le site vitrine comme si il devait être déployer à distance. Une fois le serveur apache installé,il faut choisir le chemin (local à l’hôte de apache) vers le site du projet. Pour simplifier ce choix nous allons dire que le site ira dans /urs/share/doc accessible par //localhost/doc/etc/ mais il est possible de choisir un autre chemin en ajoutant un alias dans le fichier /etc/apache2/sites-enabled/000-default
Pour avois un site minimal il suffit d’ajouter au projet le fichier suivant <mon_projet>/src/site/site.xml contenant
<?xml version="1.0" encoding="UTF-8"?>
<project name="Maven">
<bannerLeft>
<name>Maven</name>
<src>//maven.apache.org/images/apache-maven-project.png</src>
<href>//maven.apache.org/</href>
</bannerLeft>
<bannerRight>
<src>//maven.apache.org/images/maven-small.gif</src>
</bannerRight>
<body>
<links>
<item name="Apache" href="//www.apache.org/" />
<item name="Maven 1.x" href="//maven.apache.org/maven-1.x/"/>
<item name="Maven 2" href="//maven.apache.org/"/>
</links>
<menu ref="reports"/>
</body>
</project>
Cette simple configuration permet d’obtenir un site de documentation que vous pouvez tester en lançant
mvn site
Aller voir le résultat dans <mon_projet>/target/site
Nous reviendrons plus en détails sur les possibilités de génération du site par maven. Pour l’instant essayons d’automatiser la génération du site en chargeant l’intégration continue de mettre à jour le site. A ce stade le projet mis en place est minimaliste et la génération de son site est très rapide. Cependant, un véritable projet contenant plusieurs dizaine ou centaines de milliers de lignes de code peut voir sont temps de génération dépasser la demie-heure. C’ets pourquoi il est préférable de séparer les constructions dites de “pure build” qui doivent vérifier que le projet compile et devant intervenir dès que possible, des constructions plus lourdes qui peuvent se faire un fois par jour, la nuit par exemple. La génération du site fait partie du build nocturne.
Pour ajouter un build nocturne dans continuum, il faut d’abord ajourer une planification. Contnuum est livré avec une seule planification qui permet de lancer un build toutes les heures. Nous allons ajouter une planification pour le build nocturne. Dans le menu de gauche sélectionner “planification”. Puis cliquer sur “ajouter”.
Nous pouvons maintenant ajouter la construction qui va utiliser cette planification. Dans le menu du gauche choisir “Groupe de projet” pour sélectionner ensuite le groupe qui nous intéresse, puis le projet sur lequel on veut ajouter la construction du site.
A ce stade le build va échouer au moment du déploiement. Il nous faut définir dans le projet vie le pom.xml l’endroit où maven doit déployer le site. Pour cela ajouter les ligne suivante dans le fichier pom.xml:
<distributionManagement>
<site>
<id>public.site</id>
<name>public site served by apache</name>
<url>scp://localhost/usr/share/doc/${pom.groupId}/${pom.artifactId}</url>
</site>
</distributionManagement>
Pour les besoins de l’article nous utilisons la méthode de transfert SCP pour être le plus général possible. Dans un environnement réel, le site étant sans doute hébergé sur une autre machine que celle du serveur d’intégration continue. Ce choix nous permet d’aborder la question de la sécurité. Seule l’intégration continue est officiellement autorisée à déployer le site vitrine. L’identifiant du site (<id>) permettra de définir pour un site donné les paramètres de connexion (login et mot de passe) pour accéder à l’url.
Le répertoire qui va accueillir le site vitrine est /usr/share/doc. Par défaut ce répertoire n’est accessible en écriture que par l’utilisateur “root”. Nous allons élargir le droit au groupe “root” dans le quel on va ensuite mettre un nouvel utilisateur “continuum”. Pour cela ouvrir un terminal en admiinistrateur et changer les droit sur /user/share/doc :
>sudo sh
>nautilus
Maintenant nous allons définir un utilisateur “continuum” ayant le droit d’écrire dans le répertoire /usr/share/doc. Dans Ubuntu allr dans le menu System > Administration/Utilisateurs et groupes> pour ouvrir l’outil intitulé “réglage des utilisateurs”.. Cliquer sur “Déverrouiller” pour pouvoir créer un utilsateur “continuum” et définit son mot de passe.Puis toujours dans l’outil “réglage des utilisateurs” cliquer sur “gérer les groupes. Choisir le groupe “root” puis sélectionner l’utilisateur “continuum” afin de l’jouter dans le groupe “root”. Maintenant nous avons un utilisateur privilégié qui va pouvoir écrire dans le répertoire /usr/share/doc.
Afin d’indiquer à maven l’utilisateur et le mot de passe à utiliser pour faire le deploiement par le méthode SCP, nous utilisons le fichier settings.xml qui permet de definir le paramétrage spécific. L’installation de maven ayant été faite par Ubuntu via le paquet maven, il faut modifier le fichier /usr/share/maven2/conf/settings.xml pour y ajouter le paramétrage associé au site “public.site”
<server>
<id>public.site</id>
<username>continuum</username>
<password>continuum</password>
</server>
Nous avons successivement mis en place des mécanismes automatisant les flux d’informations suivants:
- alerte des modifications des sources
- alertes des constructions
- documentation du projet
Dans un prochain article nous approfondirons les possibilités offertes par la génération du site.
