Réseaux sociaux et réseautage professionnel

Il y a environs 2 ans un jeune collègue m’a parlé de Viadéo. Je me suis intéressé au concept des réseaux sociaux professionnels et j’ai trouvé les 3 acteurs : Viadéo , LinkedIn , Xing. Je propose dans cet article une rétrospective de mon utilisation de ces réseaux.

On peut se demander pourquoi irait-on sur ces réseaux qui à priori semblent n’être qu’un logiciel web de carnet d’adresse. En plus de la fonction de carnet d’adresse, ces réseaux permettent à des gens ayant des intérêts professionnels communs de ce rencontrer virtuellement d’abords mais bien concrètement ensuite avec une affaire ou un emplois à la clé. Cependant la dimension relationnelle est bien ce qui fait le moteur d’un réseautage réussi. Ainsi l’utilisateur qui ne cherche qu’un emplois où un collaborateur ne va pas trouver dans ces réseaux sociaux une réponse immédiate. Pour cela il y a les sites d’emplois comme Monster par exemple. Les réseaux sociaux nécessitent du temps et comme un jardin il faut l’entretenir.

Tout d’abord il faut se fixer un objectif à moyen terme au moins. En effet le reseau aura toute sa valeur si il contient le bon contact qui vous fournira le service dont vous aurez besoin au bon moment. Si vous êtes ou aller êtes en recherche d’emplois, vous pouvez vous rapprocher de contacts dans votre domaines de compétences dans le secteur du recrutement. J’ai remarqué que beaucoup de recruteurs utilisent Viadéo comme base de données pour leurs missions. Être “référencés” auprès de ces personnes peut vous offrir des opportunités. Pour ma part je préfère avoir comme contact sur ces réseaux des gens que je pourrais recommander, donc des gens que je “connais”. Pour cela je préfère faire connaissance avec la personne lors d’un entretien où je “recrute” le recruteur. Après l’entretien qu’il soit positif ou non pour le poste en lice, vous proposerez au recruteur de devenir votre contact sur le réseau. Le plus important est de bien prendre la mesure de ce qu’un contact direct représente dans le réseau. Un contact direct peut potentiellement voir vos autres contacts. L’ami de mon ami n’est pas forcément mon ami donc il faut être prudent et ne pas oublier qu’un réseau a de la valeur que si il est un tant soit peu “fermé”.

Ensuite il faut entretenir son réseau. Pour cela il est utile d’étre déjà à la base doté d’un sens relationnel. Si ce n’est pas le cas, cela s’apprend. Il faut par exemple demander des nouvelles des membres de son réseaux. Viadéo fournit déjà une rubrique “news” où s’affiche l’activité du réseau. Mais il ne faut pas hésiter à être actif. Quand par exemple un membre met à jour son profil, vous pouvez prendre contact pour demander si il est à l’écoute du marché ou si il a obtenu une promotion…Un contact qui vous entend souvent pensera à vous quand une opportunité se présentera!

Le choix de réseaux dépendra de divers critères. Le premier est le coût car si l’inscriptin est gratuite, l’accès aux fonctions de recherche et de mise en relation sont payante. LinkedIn est le plus cher des 3. Viadeo est plus convivial et offre une bonne visibilité dans les moteur s de recherche. Enfin Xing le moins cher des 3 et il existe une version du site adapté aux téléphones portables permettant un réseautage en mobilité. Un point positif pour Xing est le support de l’import et de l’export des contacts.

Réseaux sociaux et réseautage professionnel

Il y a environs 2 ans un jeune collègue m’a parlé de Viadéo. Je me suis intéressé au concept des réseaux sociaux professionnels et j’ai trouvé les 3 acteurs : Viadéo , LinkedIn , Xing. Je propose dans cet article une rétrospective de mon utilisation de ces réseaux.

On peut se demander pourquoi irait-on sur ces réseaux qui à priori semblent n’être qu’un logiciel web de carnet d’adresse. En plus de la fonction de carnet d’adresse, ces réseaux permettent à des gens ayant des intérêts professionnels communs de ce rencontrer virtuellement d’abords mais bien concrètement ensuite avec une affaire ou un emplois à la clé. Cependant la dimension relationnelle est bien ce qui fait le moteur d’un réseautage réussi. Ainsi l’utilisateur qui ne cherche qu’un emplois où un collaborateur ne va pas trouver dans ces réseaux sociaux une réponse immédiate. Pour cela il y a les sites d’emplois comme Monster par exemple. Les réseaux sociaux nécessitent du temps et comme un jardin il faut l’entretenir.

Tout d’abord il faut se fixer un objectif à moyen terme au moins. En effet le reseau aura toute sa valeur si il contient le bon contact qui vous fournira le service dont vous aurez besoin au bon moment. Si vous êtes ou aller êtes en recherche d’emplois, vous pouvez vous rapprocher de contacts dans votre domaines de compétences dans le secteur du recrutement. J’ai remarqué que beaucoup de recruteurs utilisent Viadéo comme base de données pour leurs missions. Être “référencés” auprès de ces personnes peut vous offrir des opportunités. Pour ma part je préfère avoir comme contact sur ces réseaux des gens que je pourrais recommander, donc des gens que je “connais”. Pour cela je préfère faire connaissance avec la personne lors d’un entretien où je “recrute” le recruteur. Après l’entretien qu’il soit positif ou non pour le poste en lice, vous proposerez au recruteur de devenir votre contact sur le réseau. Le plus important est de bien prendre la mesure de ce qu’un contact direct représente dans le réseau. Un contact direct peut potentiellement voir vos autres contacts. L’ami de mon ami n’est pas forcément mon ami donc il faut être prudent et ne pas oublier qu’un réseau a de la valeur que si il est un tant soit peu “fermé”.

Ensuite il faut entretenir son réseau. Pour cela il est utile d’étre déjà à la base doté d’un sens relationnel. Si ce n’est pas le cas, cela s’apprend. Il faut par exemple demander des nouvelles des membres de son réseaux. Viadéo fournit déjà une rubrique “news” où s’affiche l’activité du réseau. Mais il ne faut pas hésiter à être actif. Quand par exemple un membre met à jour son profil, vous pouvez prendre contact pour demander si il est à l’écoute du marché ou si il a obtenu une promotion…Un contact qui vous entend souvent pensera à vous quand une opportunité se présentera!

Le choix de réseaux dépendra de divers critères. Le premier est le coût car si l’inscriptin est gratuite, l’accès aux fonctions de recherche et de mise en relation sont payante. LinkedIn est le plus cher des 3. Viadeo est plus convivial et offre une bonne visibilité dans les moteur s de recherche. Enfin Xing le moins cher des 3 et il existe une version du site adapté aux téléphones portables permettant un réseautage en mobilité. Un point positif pour Xing est le support de l’import et de l’export des contacts.

Un environnement de developpement Java: mise en place d’Archiva

Un concept fondamental de maven est celle du dépôt de librairie qui met à disposition des projets toutes les librairies dont ils dépendent. Cela permet de ne jamais copier une librairies tiers dans l’arborescence du projet comme on peut le voir dans certains projets fait avec ant. Avec maven on ne met dans le serveur de source uniquement des…sources et tout ce qui est fabriqué à partir de sources doit être mis à disposition dans un dépôt de librairie : le repository. Il y a 2 types de repository: l’un local à l’utilisateur qui est en train de faire un build, l’aute dit distant qui permet à tout utilisateur de bénéficier de librairies produites par d’autre build. Le repository local va accueillir une copie des librairies (dites artefacts) provenant des repository distants mais il ne  s’agit là que d’un mécanisme technique pour accélérer le build. Grâce à maven sur la machine de l’utlisateur une librairies n’est jamais dupliquée entre les projets: tous vont utiliser la librairie qui se trouve dans le repository local.

Le repository distant peut être multiple: une organisation va avoir son  dépôt maven 2 pour accueillir ces propres librairies issues de ces propres projets. Mais ces projets vont sans doute utiliser des librairies tierces en provenance d’internet ne serait-ce que pour avoir les librairies dont dépend maven 2 lui-même. L’accès du build à internet pose un premier problème à certains réseaux d’entreprises. Il faut alors avoir un miroir interne des librairies publiques. En plus la simple fonction de mirroir, le repository distant doit aussi être celui qui contient les différentes librairies interne produite par l’organisation. Dans de larges projets ou quand la gestions des dépendances doit être contrôlée par projet entier, il faut que le serveur de librairies ait une gestion des droits. Par exemple un projet donné va utiliser un repository qui ne va lui fournir que des librairies autorisées. Un autre projet aura droit à d’autres librairies. On peut répondre à ce besoin par l’utilisation de plusieurs repository mais on utilisera avantageusement Archiva qui est un serveur de repository.

Nouc choisissons la version standalone d’archiva. Après avoir décompresser l’archive, aller modifier le fichier <archiva_dir>/conf/jetty.xml afin de spécifier le port http 9090 au lieu de 8080 déjà utilisé par continuum. Modifier aussi le port https en 9443 au lieu de 8443. Installer ensuite archiva en tant que service à l’aide des commandes suivantes

sudo ln -s /home/thierry/Programmes/apache-archiva-1.2-M1/bin/archiva /etc/init.d/archiva

sudo update-rc.d archiva defaults 80

sudo /etc/init.d/archiva start

Maintenant nous allons créer un repository virtuel dédié à notre projet. Le principe est d’avoir une entrée unique dans la définition du repository distant pour tous les artefacts possibles afin de simplifier la configuration dans le projet et de déporter le recensement des repository distant dans archiva. Pour ce faire on déclare dans le projet un seul repository en mettant dans le fichier pom.xml

<repositories>
<repository>
<id>project</id>
<name>Archiva Managed Unified Repository</name>
<url>//localhost:9090/archiva/repository/vroom/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>

Cette déclaration dit que le projet doit aller chercher es dépendances dans le repository qui porte le même nom que le projet. En fait il s’agira d’un repository virtuel qui va regrouper tous les repository autorisé pour le projet. Nous le créeront plus tard. Pour l’instant définissons le repository de déploiement des artefacts produit. Ainsi dans la section <distributionManagement> du fichier pom.xml ajouter les déclarations suivantes:

<snapshotRepository>
<id>snapshots</id>
<url>//localhost:9090/archiva/repository/vroom-snapshots</url>
</snapshotRepository>
<repository>
<id>internal</id>
<url>//localhost:9090/archiva/repository/vroom-internal/</url>
</repository>

On voit que le nom du repository de déploiement ne respecte pas la convention mais archiva utilise l’identifiant du repository comme suffixe de l’url. Je propose donc un contournement <nom_repo>-snaphots en <nom_repo>-internal. Dans déclaration on indique 2 repository distincts pour les snapshots et les versions finales. Dans le cadre de notre article l’usage dun repository pour le projet peut paraître surfait mais cette pratique prend son sens quand on veux regrouper dans un repository des projets ayant un lien et que l’on ne veux pas partager avec d’autres projets.

Maintenant on peut créer le repository virtuel pour le projet vroom qui va regrouper

  • les repository des ibrairies tierces
  • les repository du projet (ou du groupe)

Tout d’abord il faurt créer les repository spécifiques au projet. Aller dans le menu de gauche pour sélectionner repositories puis cliquer sur l’icone Add. Voici une capture montrant la création du repositoy vroom-internal :

Archiva repository creation Archiva repository creation snapshot

Enfin il reste à les regrouper dans le repository virtuel: aller dans le menu de gauche pour sélectionner Repositories Group. Dans le champs n haut à droite saisir vroom comme identifiant puis cliquer sur Add group. Dans le groupe qui vient d’être créé, ajouter les repository réels: il suffit à ce stade d’ajouter tous les repository pour mettre dans le groupe les repository par défaut de continuum (internal et snapshots) ainsi que les 2 spécifiques au projet vroom (vroom-internal et vroom-snapshots).

Archiva virtual repository

Archiva offre un mécanisme de gestion de droit, il nous faudra créer un utilisateur ayant le rôle Observer pour la lecture et Manager pour le déploiement d’artefact. Comme nous utilisons un repository virtuel il est judicieux de choisir un rôle Global Repository Observer afin de ne pas avoir à ajouter de droits à chaque fois qu’on ajoute un nouveau repository réel dans le repository virtuel. Les identifiants et mots de passes sont à renseigner dans le fichier settings.xml :

<server>
<id>snapshots</id>
<username>thierry</username>
<password>xxxxxxx</password>
</server>
<server>
<id>internal</id>
<username>thierry</username>
<password>
xxxxxxx</password>
</server>
<server>
<id>project</id>
<username>thierry</username>
<password>
xxxxxxx</password>
</server>
</servers>

En plus de la centralisation des repository, archiva peut aussi servir de proxy.Nous allons rediriger toute les requêtes vers des repository externes (les différents plugin de maven vont être téléchargé par ce biais) vers archiva qui va alors les stocker pour les prochaines fois. Cela est extrêmement bénéfique quand un autre utiisateur (local à la machine ou dans l’intranet de l’entreprise) lance le même build. Pour cela il faut indiquer un repository virtuel comme miroir dans le fichier settings.xml

<mirror>
<id>archiva.mirror</id>
<url>//localhost:9090/archiva/repository/mirror</url>
<mirrorOf>*,!project</mirrorOf>
</mirror>

Dans cette déclaration on dit que pour tous les repository autre que project (qui lui est définit dans le projet comme un repository archiva), maven va utiliser le repository archiva appelé mirror. Dans archiva il faudra créer le repository mirror comme repository virtuel (groupe) qui contiendra les repository standard de continuum : internal et snapshot.

Archiva mirror repository

Nous avons vu comment utiliser archiva pour centraliser l’administration des repository distant ainsi que pour mettre en cache les artefacts issus des repository distants pour les partager via archiva avec les autres builds.

Un environnement de developpement Java: mise en place d’Archiva

Un concept fondamental de maven est celle du dépôt de librairie qui met à disposition des projets toutes les librairies dont ils dépendent. Cela permet de ne jamais copier une librairies tiers dans l’arborescence du projet comme on peut le voir dans certains projets fait avec ant. Avec maven on ne met dans le serveur de source uniquement des…sources et tout ce qui est fabriqué à partir de sources doit être mis à disposition dans un dépôt de librairie : le repository. Il y a 2 types de repository: l’un local à l’utilisateur qui est en train de faire un build, l’aute dit distant qui permet à tout utilisateur de bénéficier de librairies produites par d’autre build. Le repository local va accueillir une copie des librairies (dites artefacts) provenant des repository distants mais il ne  s’agit là que d’un mécanisme technique pour accélérer le build. Grâce à maven sur la machine de l’utlisateur une librairies n’est jamais dupliquée entre les projets: tous vont utiliser la librairie qui se trouve dans le repository local.

Le repository distant peut être multiple: une organisation va avoir son  dépôt maven 2 pour accueillir ces propres librairies issues de ces propres projets. Mais ces projets vont sans doute utiliser des librairies tierces en provenance d’internet ne serait-ce que pour avoir les librairies dont dépend maven 2 lui-même. L’accès du build à internet pose un premier problème à certains réseaux d’entreprises. Il faut alors avoir un miroir interne des librairies publiques. En plus la simple fonction de mirroir, le repository distant doit aussi être celui qui contient les différentes librairies interne produite par l’organisation. Dans de larges projets ou quand la gestions des dépendances doit être contrôlée par projet entier, il faut que le serveur de librairies ait une gestion des droits. Par exemple un projet donné va utiliser un repository qui ne va lui fournir que des librairies autorisées. Un autre projet aura droit à d’autres librairies. On peut répondre à ce besoin par l’utilisation de plusieurs repository mais on utilisera avantageusement Archiva qui est un serveur de repository.

Nouc choisissons la version standalone d’archiva. Après avoir décompresser l’archive, aller modifier le fichier <archiva_dir>/conf/jetty.xml afin de spécifier le port http 9090 au lieu de 8080 déjà utilisé par continuum. Modifier aussi le port https en 9443 au lieu de 8443. Installer ensuite archiva en tant que service à l’aide des commandes suivantes

sudo ln -s /home/thierry/Programmes/apache-archiva-1.2-M1/bin/archiva /etc/init.d/archiva

sudo update-rc.d archiva defaults 80

sudo /etc/init.d/archiva start

Maintenant nous allons créer un repository virtuel dédié à notre projet. Le principe est d’avoir une entrée unique dans la définition du repository distant pour tous les artefacts possibles afin de simplifier la configuration dans le projet et de déporter le recensement des repository distant dans archiva. Pour ce faire on déclare dans le projet un seul repository en mettant dans le fichier pom.xml

<repositories>
<repository>
<id>project</id>
<name>Archiva Managed Unified Repository</name>
<url>//localhost:9090/archiva/repository/vroom/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>

Cette déclaration dit que le projet doit aller chercher es dépendances dans le repository qui porte le même nom que le projet. En fait il s’agira d’un repository virtuel qui va regrouper tous les repository autorisé pour le projet. Nous le créeront plus tard. Pour l’instant définissons le repository de déploiement des artefacts produit. Ainsi dans la section <distributionManagement> du fichier pom.xml ajouter les déclarations suivantes:

<snapshotRepository>
<id>snapshots</id>
<url>//localhost:9090/archiva/repository/vroom-snapshots</url>
</snapshotRepository>
<repository>
<id>internal</id>
<url>//localhost:9090/archiva/repository/vroom-internal/</url>
</repository>

On voit que le nom du repository de déploiement ne respecte pas la convention mais archiva utilise l’identifiant du repository comme suffixe de l’url. Je propose donc un contournement <nom_repo>-snaphots en <nom_repo>-internal. Dans déclaration on indique 2 repository distincts pour les snapshots et les versions finales. Dans le cadre de notre article l’usage dun repository pour le projet peut paraître surfait mais cette pratique prend son sens quand on veux regrouper dans un repository des projets ayant un lien et que l’on ne veux pas partager avec d’autres projets.

Maintenant on peut créer le repository virtuel pour le projet vroom qui va regrouper

  • les repository des ibrairies tierces
  • les repository du projet (ou du groupe)

Tout d’abord il faurt créer les repository spécifiques au projet. Aller dans le menu de gauche pour sélectionner repositories puis cliquer sur l’icone Add. Voici une capture montrant la création du repositoy vroom-internal :

Archiva repository creation Archiva repository creation snapshot

Enfin il reste à les regrouper dans le repository virtuel: aller dans le menu de gauche pour sélectionner Repositories Group. Dans le champs n haut à droite saisir vroom comme identifiant puis cliquer sur Add group. Dans le groupe qui vient d’être créé, ajouter les repository réels: il suffit à ce stade d’ajouter tous les repository pour mettre dans le groupe les repository par défaut de continuum (internal et snapshots) ainsi que les 2 spécifiques au projet vroom (vroom-internal et vroom-snapshots).

Archiva virtual repository

Archiva offre un mécanisme de gestion de droit, il nous faudra créer un utilisateur ayant le rôle Observer pour la lecture et Manager pour le déploiement d’artefact. Comme nous utilisons un repository virtuel il est judicieux de choisir un rôle Global Repository Observer afin de ne pas avoir à ajouter de droits à chaque fois qu’on ajoute un nouveau repository réel dans le repository virtuel. Les identifiants et mots de passes sont à renseigner dans le fichier settings.xml :

<server>
<id>snapshots</id>
<username>thierry</username>
<password>xxxxxxx</password>
</server>
<server>
<id>internal</id>
<username>thierry</username>
<password>
xxxxxxx</password>
</server>
<server>
<id>project</id>
<username>thierry</username>
<password>
xxxxxxx</password>
</server>
</servers>

En plus de la centralisation des repository, archiva peut aussi servir de proxy.Nous allons rediriger toute les requêtes vers des repository externes (les différents plugin de maven vont être téléchargé par ce biais) vers archiva qui va alors les stocker pour les prochaines fois. Cela est extrêmement bénéfique quand un autre utiisateur (local à la machine ou dans l’intranet de l’entreprise) lance le même build. Pour cela il faut indiquer un repository virtuel comme miroir dans le fichier settings.xml

<mirror>
<id>archiva.mirror</id>
<url>//localhost:9090/archiva/repository/mirror</url>
<mirrorOf>*,!project</mirrorOf>
</mirror>

Dans cette déclaration on dit que pour tous les repository autre que project (qui lui est définit dans le projet comme un repository archiva), maven va utiliser le repository archiva appelé mirror. Dans archiva il faudra créer le repository mirror comme repository virtuel (groupe) qui contiendra les repository standard de continuum : internal et snapshot.

Archiva mirror repository

Nous avons vu comment utiliser archiva pour centraliser l’administration des repository distant ainsi que pour mettre en cache les artefacts issus des repository distants pour les partager via archiva avec les autres builds.

Un environnement de developpement Java: la communication

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:

  1. renommer le fichier <mon_repo>/hooks/post-commit.tmpl en post-commit
  2. activer le droit d’execution au fichier post-commit
  3. 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:

  1. renommer le fichier /usr/share/subversion/hook-scripts/mailer/mailer.conf.example en mailer.conf
  2. 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

Continuum - mail notifier settings continuum - mail de notification

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”.

continuum_planification_settings.1226397751.png continuum_ightly_build_definition.1226350137.png

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.

continuum_project_information.1226350099.png continuum_site_build_definition.1226398348.png

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

add_root_group_write_on_doc.1226401611.png

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:

  1. alerte des modifications des sources
  2. alertes des constructions
  3. documentation du projet

Dans un prochain article nous approfondirons les possibilités offertes par la génération du site.