Industrialisation du développement Java Révision 2

turnmarySoftware and s/w Development

Jul 5, 2012 (5 years and 1 month ago)

656 views

Industrialisation du développement Java
Révision 2
Sandro Munda
18 mai 2010
Préface
Ce document est écrit dans le cadre de mon stage effectué chez Manex.Ce stage
met fin à mes études que j’ai effectuées à la Haute Ecole de la Province de Liège
dans le but d’obtenir le diplôme de Bachelier en Science Informatique,Finalité
Gestion.
Ce document est construit uniquement à l’aide d’outils libres.Tout d’abord,il est
écrit à l’aide du langage L
A
T
E
X2e et de sa distribution TeXlive.L’éditeur utilisé est GNU
Emacs et son mode majeur AucTeX.La disposition du document est effectuée grâce à
la classe s16 et au package s16extra,tous deux écrits en T
E
X par mes soins et distribués
sous licences bsd.L’ensemble des schémas présent dans ce document a été dessiné au
moyen du logiciel Dia.
i
Table des matières
1 Introduction 1
1.1 Présentation de l’entreprise...........................1
1.1.1 Produits..................................2
Jafar.................................2
iBats.................................2
iSeg..................................2
1.2 Cahier des charges................................3
1.2.1 Objectif..................................3
1.2.2 Organisation du travail..........................3
2 L’analyse de l’existant 4
2.1 Topologie réseau.................................4
2.2 Infrastructure de développement........................6
2.2.1 Intellij Idea 9.0..............................6
2.2.2 Subversion.................................9
Apports des scm...........................10
Architecture des scm........................10
2.2.3 Teamcity 5.0...............................12
2.2.4 Jira....................................14
2.2.5 Conclusion sur l’infrastructure de développement actuelle......14
3 Etude de la nouvelle infrastructure 16
3.1 Outils de « build java ».............................16
3.1.1 Compilation manuelle..........................16
3.1.2 Apache Ant................................18
Apache Ivy..............................19
3.1.3 Maven 2..................................20
Standardisation...........................20
Réutilisabilité............................21
Communication...........................22
Gestion des dépendances......................23
Historique..............................24
3.1.4 Gradle...................................25
Bilan du choix de l’outil de build Java...............26
3.2 Maven 2......................................26
Descripteur de projet........................26
3.3 Intégration continue...............................27
3.3.1 CruiseControl...............................27
3.3.2 Apache Continuum............................28
3.3.3 Hudson..................................29
3.3.4 Bilan du choix de l’outil d’intégration continue............29
3.4 Gestionnaire de dépôts..............................31
ii
 iii
3.4.1 Dead Simple Maven Proxy (DSMP)..................33
3.4.2 Codehaus Maven-proxy.........................33
3.4.3 Apache Archiva..............................33
3.4.4 Nexus...................................33
3.4.5 Artifactory................................34
3.4.6 Bilan du choix du gestionnaire de dépôt................34
3.5 Analyse de codes.................................35
Intellij Idea Code Inspection....................35
3.5.1 Plug-ins Maven 2.............................36
Surefire................................36
Corbetura..............................36
CheckStyle..............................36
PMD.................................36
Findbugs...............................37
JDepend...............................37
Conclusion sur les outils d’analyse de codes............37
3.5.2 Maven Dashboard Report........................37
3.5.3 Sonar...................................37
3.5.4 Conclusion sur le choix de l’outil d’analyse de codes.........38
4 Mise en place de l’infrastructure 40
4.1 Préliminaires...................................40
4.1.1 Standard LDAP.............................40
Structure d’un annuaire LDAP...................40
4.1.2 Cron....................................41
4.2 Installation de l’infrastructure de test......................42
4.2.1 VMWare ESXi Server..........................42
4.2.2 CentOS 5.................................42
Installation de CentOS 5 (x86)...................42
4.2.3 Installation des applications webs....................43
Configure du nom de domaine...................44
Configuration de Tomcat......................44
Configuration d’Apache.......................45
4.3 Utilisation et configuration d’Artifactory....................47
4.3.1 Menu Home................................47
4.3.2 Menu Artifacts..............................47
4.3.3 Menu Deploy...............................49
4.3.4 Menu Admin...............................51
Configuration générale........................51
Sécurité................................53
Services................................54
Import & Export..........................54
Advanced...............................55
4.3.5 Configuration de Maven pour utiliser Artifactory...........55
4.4 Utilisation et configuration de Sonar......................58
4.4.1 Création de la base de données.....................58
4.4.2 Installation des plug-ins.........................59
 iv
4.4.3 Déploiement de l’application.......................60
4.4.4 Ajout d’un projet à Sonar........................61
4.4.5 Page d’accueil...............................62
4.4.6 Configuration principale.........................62
Quality profiles............................62
Event categories...........................63
Manual metrics...........................63
Settings................................63
Backup................................63
My profile..............................64
Users.................................64
Groups................................64
Global roles.............................64
Project roles.............................64
4.4.7 Dashboard................................64
4.4.8 Components................................67
4.4.9 Violations drilldown...........................67
4.4.10 Time Machine..............................68
A Les méthodes agiles 73
A.1 Définition.....................................73
A.2 Panorama.....................................74
A.2.1 eXtreme Programming..........................74
Les douze travaux de l’eXtreme Programming..........75
A.2.2 Scrum...................................77
A.2.3 Différences entre l’eXtreme Programming et Scrum..........77
Chapitre
1
Introduction
L’industrialisation,au sens général du terme,désigne la fabrication de produits avec
des techniques permettant d’accroître un maximum la productivité du travail.D’un point
de vue informatique,cela consiste à gérer au mieux les ressources internes dans un contexte
donné.L’industrialisation ne doit cependant pas être confondue avec l’automatisation.En
effet,dès que l’on parle d’industrialisation d’une procédure,celle-ci a déjà été informatisée
et le but réside en son perfectionnement.
Ce travail rentre dans le cadre de mon stage de fin d’études que j’ai réalisées chez
Manex.
1.1 Présentation de l’entreprise
En 1986,l’informatique est en plein essor.Manex voit le jour grâce à Nicolas Keunen
dans le but de proposer des solutions logicielles et réseaux.En 1996,son fils,Vincent
Keunen reprend Manex et décide d’utiliser et de se spécialiser dans des technologies
« open source » et des infrastructures libres (principalement basée sur GNU/Linux).
La force de Manex réside dans leur aptitude à pouvoir adapter des composants « open
source » (Apache Jakarta,OpenCMS,Compiere,etc.) afin de répondre aux exigences
les plus pointues.La spécialisation dans les technologies « open source » permet notamment
à Manex de garantir une pérennité des solutions et une adaptabilité des plus idéales.
Le domaine d’applications de Manex reste large.L’entreprise a acquis une large expé-
rience dans ces quelques domaines:
Systèmes Internet:sites web transactionnels,applications web,système de messagerie,
échanges Business-to-Business
1
,etc.
exemple Réseau de l’Université de Liège (développement du portail des anciens).
technologies OpenCMS,J2EE,JBoss etc.
Systèmes de sécurité:Sécurisation des transferts de données et des accès,single sign
on,carte eID,etc.
exemple Médibridge:Développement d’une messagerie médicale sécurisée.
technologies JCA,PKI,certificats,signatures électroniques,etc.
Systèmes mobiles Développement d’applications pour mobiles.
1.B2B
1
Présentation de l’entreprise Introduction 2
exemple Idewe:Transfert mobile des données d’un logiciel d’audit et de reporting.
Technologies J2ME,XML,etc.
Formation Formation dans divers domaines.
exemple Formations Java pour divers hôpitaux (St Jospeh,André Renard,
Forem,etc.)
1.1.1 Produits
Jafar
Jafar
2
("Java Advanced Facilities for Audit and Reporting") a été développé suite
à une demande de Idewe
3
.Cette entreprise sollicite Manex afin de concevoir un logiciel
permettant d’automatiser et donc d’informatiser les observations des auditeurs.La solution
s’appelle Jaws.Jafar est en fait le coeur de Jaws,qui élargit son domaine d’activité tout
en reprenant ses fonctionnalités.Jafar permet donc d’aider les auditeurs et les enquêteurs
à collecter des données sur un domaine d’activité précis,de générer des rapports en fonction
de ces audits et de synchroniser en centralisant les données recueillies.
iBats
iBats ("Inter Business Automated Transport System") est un système permettant de
transporter de manière sécurisée,automatique et ouverte des documents électroniques.
En effet,la sécurité y est instaurée grâce à un système à PKI qui garantit l’authenticité,
la confidentialité,l’intégrité,la non-répudiation et la traçabilité.L’automatisation y est
établie grâce à un système qui permet d’envoyer les documents se trouvant dans une boîte
d’envoi,à intervalle régulier.Ce système gère les éventuels conflits lors de la réception du
document.Un autre aspect de cette automatisation réside dans sa mise à jour.L’argument
d’ouverture est défendu grâce à sa portabilité (grâce à la technologie Java),sa gestion
de formats (iBats permet de convertir un fichier afin que l’émetteur et le récepteur se
comprennent),sa standardisation (en effet,iBats fonctionne sur des protocoles standards
tels que SMTP,IMAP,LDAP) et de son intégration,ce qui lui permet de compléter les
fonctionnalités des logiciels de messageries habituels.
iSeg
iSeg ("iBats Secure Gateway") est un WebVPN,c’est-à-dire qu’il fournit un
moyen sûr d’accéder à des applications web ou non (ou d’autres ressources internes d’un
réseau) en utilisant un navigateur web standard.L’intérêt majeur qui repose dans ce logiciel
est qu’aucun logiciel client (autre qu’un navigateur) n’est nécessaire et que la maintenance
est faite de manière centralisée.iSeg repose sur une identification forte basée sur la carte
d’identité électronique (eID).Les applications accessibles à l’utilisateur se serviront de
l’authentification forte d’iSeg;cette fonctionnalité s’appelle le"single sign on".iSeg per-
2.http://www.jafar.biz
3.L’un des leaders principaux dans le secteur de la médecine du travail en Belgique
Cahier des charges Introduction 3
met de verrouiller le réseau en laissant uniquement un port ouvert sur le firewall (HTTPS
- 443/TCP) pour un maximum de sécurité.
1.2 Cahier des charges
1.2.1 Objectif
La base de ce travail consiste donc à industrialiser le développement Java chez Manex.
L’objectif final est d’arriver à une solution permettant d’accroître la productivité du travail
des développeurs.Pour réaliser cet objectif,il sera nécessaire de repenser à l’infrastructure
de développement.Cette infrastructure doit obéir à plusieurs points.Notamment,elle doit
permettre de:
 gérer la gestion des projets en développement;
 suivre l’évolution de chaque projet;
 automatiser les tâches répétitives et fastidieuses;
 historiser l’ensemble du développement d’un projet;
 etc.
1.2.2 Organisation du travail
Le développement dans l’entreprise repose sur base d’une méthodologie de travail
d’équipe appelée « méthode agile ».Historiquement,Manex a débuté en suivant les
concepts de l’eXtreme Programming pour ensuite rejoindre ceux de Scrum.La conver-
sion s’est faite plutôt naturellement.Les deux méthodes sont assez semblables bien que
des différences (exposées en annexe,à la sous-section A.2.3) existent.
Mon travail s’articule en différentes phases.La première concerne l’analyse de l’existant
durant laquelle je me suis intéressé aux différents outils qui composent l’ensemble de l’in-
frastructure de développement de l’entreprise.En vue d’améliorer l’infrastructure en place,
je me suis également documenté sur d’autres domaines afin de proposer des solutions plus
optimales.La deuxième phase est une phase de comparaison et certains de ces outils ont
été substitués à d’autres tandis que de nouveaux se sont ajoutés.Par exemple,les outils
de compilation Make et Ant ont été abandonnés au profit de Maven 2.Par ailleurs,
l’ensemble de tous ces outils est défini au fur et à mesure.Ces deux phases constituent une
partie conséquente de mon travail.Une phase de « pré-mise en place » a alors été effectuée
sur un serveur test que j’ai entièrement installé et configuré.Une fois opérationnelle,j’ai
repensé à l’organisation des serveurs de manière à centraliser l’infrastructure de dévelop-
pement.En guise d’illustration,j’ai converti le projet CRC — une application basée sur
la bibliothèque GWT (Google Web Toolkit) qui gère les repas de l’hôpital du Bois de
l’Abbaye.
Chapitre
2
L’analyse de l’existant
Ce chapitre cible l’existant dans l’entreprise.Cette partie est importante afin de cibler
les problèmes.Premièrement,je décris la topologie réseau actuelle.Celle-ci changera au
fur et à mesure du travail pour permettre d’accueillir la nouvelle infrastructure de déve-
loppement.
2.1 Topologie réseau
Dans le réseau interne,on retrouve tout d’abord l’intranet utilisateurs.Celui-ci se
compose de tous les utilisateurs (ordinateurs,imprimantes en réseau,portables,etc.) com-
muns.Ensuite,on retrouve l’espace intranet serveurs.Cet espace comprend les machines
qui hébergent toutes les applications accessibles uniquement en interne.Ces machines sont
au nombre de quatre.Le premier serveur,mxisrv1 héberge OpenLDAP.Ce programme
utilise le protocole LDAP qui permet d’interroger et de modifier un annuaire.Tous les
serveurs et toutes les applications (à condition qu’elles supportent cette fonctionnalité) se
connectent sur OpenLDAP afin de procéder à l’identification d’un utilisateur.Cela per-
met donc d’avoir notamment une identification et une gestion des permissions avancées et
centralisées.Le rôle de mxisrv2,une seconde machine,est d’effectuer des backups.Quant
au serveur mxisrv3,il est un peu spécial.Effectivement,il tourne sous Mac OS X.Il hé-
berge notamment un « build agent » distant pour l’application Teamcity.Pour finir avec
la partie des serveurs internes,mxisrv4 sert de monitoring.Ce dernier est assuré grâce
à l’application Nagios,anciennement appelée Netsaint.La dernière division du réseau
est certainement celle qui possède le plus de risques concernant la sécurité.C’est pourquoi
elle est placée dans une DMZ.La DMZ est un réseau isolé accessible de l’intérieur et de
l’extérieur.Les serveurs qui se situent dans ce réseau publient divers services sur Internet
(web,mail,etc.) sous le contrôle strict d’un firewall externe.On y retrouve des applications
clientes,mais aussi l’ensemble de l’infrastructure de développement.Ce dernier point est
particulièrement intéressant,car c’est ici que notre nouvelle infrastructure se retrouvera.
Sept serveurs composent cette DMZ.Le Tableau 2.1 décrit chaque serveur,ainsi que leurs
applications respectives.A note que cette description correspond à mon arrivée chez Ma-
nex.Durant mon stage,cette infrastructure a changé.Les changements seront décrits plus
tard.
4
Topologie réseau L’analyse de l’existant  5
Table 2.1 – Description de la DMZ
Nom
Description
mx1srv1 Postfix,Mailman,SpamAssassin,WebMail
mx1srv2
Serveur Web - HTTP,MySQL,PostgreSQL,Postfix,SNMP
mx1srv3 Serveur DNS,HTTP,Postfix,SNMP,VPN
mx1srv4
Machine de test
mx1srv5 Machine de test
mx1srv6
Infrastructure de développement
mx1srv7 Infrastructure de développement
Figure 2.1 – Infrastructure réseau de Manex
Infrastructure de développement L’analyse de l’existant  6
2.2 Infrastructure de développement
Avant de pouvoir introduire une nouvelle infrastructure,une analyse complète de l’in-
frastructure existante est nécessaire.Ainsi,les problèmes sont soulevés et les solutions
apportées au fur et à mesure de l’étude.Cette phase est indispensable.
2.2.1 Intellij Idea 9.0
Le choix dans est fastidieux.Nous pourrions programmer à l’aide d’un simple éditeur
de texte.Bien que moins courants,des éditeurs avancés existent.Entre autres Emacs avec
son mode jde fait très bien le travail d’un IDE.Cependant,cela est moins courant bien
que viable sans problème
1
.
Note
Je conseille d’au moins essayer un outil tel que Emacs.Fort repoussant à sa première
approche,l’addiction se fait au fur et à mesure de son utilisation,de sa découverte.
La solution la plus courante reste l’IDE.Manex a choisi l’IDE Intellij Idea 9.0.Cet
outil est proposé par la société Jetbrains
2
.Depuis la version 9.0,la société propose une
version sous licence libre (Apache 2.0) de son IDE:Community Edition.Cependant,
les fonctionnalités proposées par cette version ne sont pas suffisantes pour les programmes
développés chez Manex.C’est pourquoi la version Ultimate est utilisée.Cette dernière a
une licence commerciale et est payante.Le tableau 2.2 propose un petit comparatif des
deux éditions
3
Table 2.2:Comparaison des éditions d’Intellij Idea 9.0
Community Edition
Ultimate Edition
Historique local
Maven
Ant
Intégration JUnit
Intégration TestNG
GUI builder
Code spell checker
Compatibilité des projets Eclipse
1.Surtout si on utilise des outils des compilations tel que Maven,décrit plus tard dans ce document
2.http://www.jetbrains.com
3.Ce tableau est fortement inspiré de celui fait par Jetbrains:http://www.jetbrains.com/idea/
features/editions_comparison_matrix.html
Infrastructure de développement L’analyse de l’existant  7
Java ME
IDE communicatif
Task management
Diagramme de classes UML
Code coverage
Dependency structure matrix
Support Android
Détection du code dupliqué
Recherche et remplacement structuré
JSP debugger
Javascript debugger
Historique local
Maven
Ant
Intégration JUnit
Intégration TestNG
GUI builder
Code spell checker
Compatibilité des projets Eclipse
Java ME
IDE communicatif
Task management
Diagramme de classes UML
Code coverage
Dependency structure matrix
Support Android
Détection du code dupliqué
Recherche et remplacement structuré
JSP debugger
Javascript debugger
Support des langages
Java
Groovy
XML
Regexp
Scala
Infrastructure de développement L’analyse de l’existant  8
Clojure
Ruby/JRuby
Python
SQL
HTML,XHTML,CSS
XSL,XPath
Freemarker/Velocity
JavaScript/ActionScript
PHP
Logiciels de gestion des versions
CVS
Subversion
Git
Team Foundation Server
ClearCase
Perforce
StarTeam
Visual SourceSafe
Frameworks et technologies
OSGi
Grails
Rails
JSP
Servlet 3.0
JavaServer Faces 1.0,2.0
EJB 3.0,3.1
Web Beans
Bean validation
Flex,Air
GWT 1.X,2.0
Struts 1.2,2
Spring 2.5,3.0
JBoss Seam
Hibernate
JPA 1.0,2.0
JAX-WS,Apache AXIS
Infrastructure de développement L’analyse de l’existant  9
REST WebServices
Tapestry
Google App Engine
Frameworks et technologies
Tomcat
GlassFish v2,v3
JBoss
WebLogic
WebSphere
Geronimo
Resin
Le choix de l’Entreprise Edition est donc justifié dans notre cas.Nous aborderons
quelques points cités
4
dans le tableau 2.2 au fur et à mesure de ce document.
Note
Il existe des licences gratuites pour l’édition Ultimate destinées aux étudiants.
2.2.2 Subversion
Dans le monde professionnel,la perte de fichiers sensibles tels que les codes sources des
logiciels,les fichiers de paramètres ou tout autre document conduit souvent un désastre
dans le domaine de l’entreprise.L’informatique,bien que la stabilité ne soit pas un objectif
insurmontable,n’est pas l’abri de pannes en tout genre.Il a donc fallu penser à des solutions
permettant la sauvegarde des documents souhaités sur des supports stables et fiables.
Un premier résultat facilement accessible est de programmer une tâche"cron"qui
sauvegarde les documents souhaités sur une destination fiable.À chaque sauvegarde,la
possibilité de conserver les différentes versions est possible si,chaque sauvegarde,le dossier
de destination est différent.Cependant,cette solution nous conduit gaspillage considérable
de l’espace de stockage.
La solution serait alors d’utiliser un outil tel que rsync.Ce logiciel est la plus part du
temps disponible de base sur les systèmes UNIX.Il minimise les données entre les mises à
jour en se basant sur l’encodage delta
5
,qui permet de ne garder que les différences entre
versions.En d’autres mots,d’effectuer une sauvegarde incrémentale.rsync génère un
fichier qui contient ces différences grâce à l’outil diff.Ces changements sont généralement
relativement petits,ce qui réduit fortement le temps de transfert.Cette solution,très
puissante et très répandue dans le but de créer des miroirs,ne possède cependant pas une
série de concepts que nous permettent les scm.
4.Il serait pratiquement impossible d’expliquer en détail l’ensemble des points du comparatif.
5.Egalement appelé delta compression
Infrastructure de développement L’analyse de l’existant  10
Apports des scm
Les scm sont quant à eux bidirectionnels.Le trafic se fait donc dans les deux sens.
Les scm apportent un lot de mots de vocabulaire.Pour commencer,il est nécessaire de
récupérer une « copie locale »
6
.Une copie locale est le répertoire dans lequel l’utilisateur
travaille.Pour la récupérer,on effectue un « check out ».Il s’effectue généralement une
seule fois par projet.L’opération complémentaire est l’ « update ».Elle effectue les mises
à jour nécessaires sur la copie locale dans le but d’être synchronisée avec le dépôt
7
distant.
Le « commit » est l’inverse,il permet de répercuter les changements d’une copie locale vers
le dépôt.Pour effectuer un commit sur un répertoire qui n’est pas sous le contrôle d’un
gestionnaire de version (« unversioned »),on se sert de la commande import.« revert »
est une commande qui permet d’annuler tous les changements d’un fichier ou d’un dossier.
Ces quelques mots de vocabulaire illustrent toute la puissance des scm.
En résumé:
 un même fichier peut être édité par plusieurs personnes sans perte de données.Les
conflits sont également pris en charge par le scm.À l’aide de cette fonctionnalité,
plusieurs développeurs peuvent facilement travailler simultanément sur un même pro-
jet;
 une erreur qui engendre des dégâts conséquents est vite arrivée.Grâce à l’historisation
des versions,il est aisé de revenir à une ancienne révision en un temps extrêmement
rapide;
 l’historisation des changements permet de responsabiliser les développeurs sur les
sources « commitées »;
 etc.
Architecture des scm
Modèle centralisé Le modèle centralisé dispose d’un seul dépôt qui contient l’ensemble
de tous les fichiers,de leurs versions et de toutes les branches.Les branches permettent
de gérer plusieurs versions d’un projet en parallèle.La figure 2.2 illustre l’architecture du
modèle centralisé.CVS,Subversion,Perforce,...utilisent tous le modèle centralisé.
Modèle décentralisé (ou distribué) La grande différence avec le modèle centralisé est
que chaque développeur possède son propre dépôt.Chacun d’entre eux contient l’ensemble
des versions des fichiers.La figure 2.3 illustre l’architecture du modèle distribué.Git,
Mercurial,Bazaar,...utilisent tous cette architecture.
6.Egalement appelée working copy
7.On utilise régulièrement le terme « repository »
Infrastructure de développement L’analyse de l’existant  11
Figure 2.2 – Modèle centralisé
Figure 2.3 – Modèle distribué
Infrastructure de développement L’analyse de l’existant  12
2.2.3 Teamcity 5.0
Une entreprise telle que Manex est souvent amenée à concevoir des logiciels volumi-
neux.De plus,la solution est conçue non pas par un seul développeur,mais par plusieurs.
Un problème récurrent se retrouve sur une partie de code qui fonctionnait parfaitement
et qui,quelque temps plus tard,pose un problème dû à une modification sur une autre
partie.Il est évident que plus tôt le problème est détecté,plus facile sera la correction.
La solution la plus basique qu’il soit est de tester le plus régulièrement possible toutes
les fonctionnalités de la solution.Ce n’est certainement pas envisageable sur de gros pro-
grammes d’autant plus que cela amène à une perte de temps considérable.Entre en jeu
alors un acteur du génie logiciel:l’intégration continue.Son but principal remédie par-
faitement au problème énoncé:elle assure qu’un projet ne régresse pas.Cet ensemble de
pratique se réfère aux méthodes agiles
8
,utilisées par Manex (scrum).
L’intégration continue se combine à la notion de test unitaire permettant de s’assurer
du bon fonctionnement d’une partie d’un code.De nombreux frameworks existent afin
de faciliter la mise en oeuvre de ceux-ci.Conventionnellement,la famille de frameworks
XUnit (la lettre X étant remplacée par les initiales du langage utilisé) s’impose en étant le
standard.Le père de cette grande famille est SUnit,framework de test unitaire modelisé
par Kent Beck et destiné au langage Smalltalk.Cependant,d’autres frameworks existent
et méritent largement le détour.TestNG en est un exemple parfait.
Manex s’est penché sur la solution Teamcity,également développé par la société
JetBrains.Ce choix est justifié par l’intégration entre Intellij Idea et Teamcity.En
effet,Teamcity est capable de compiler directement les fichiers ipr,extension des projets
d’Intellij Idea.De plus,Teamcity est capable d’utiliser les profils d’inspection de code
(plus de 600 règles d’inspection) d’Intellij Idea afin d’analyser le projet.Cependant,la
fonctionnalité la plus intéressante est certainement le pre-tested commit.Elle permet
d’effectuer un commit sur un scm uniquement si les règles de validation prédéfinie grâce
au profil sont passées.La figure 2.4 illustre l’approche classique.La figure 2.5 l’approche
du pre-tested commit.
8.Une introduction aux méthodes agiles,plus particulièrement l’eXtreme Programming et Scrum,
est disponible en annexe
Infrastructure de développement L’analyse de l’existant  13
Figure 2.4 – Scénario standard
Figure 2.5 – Pre-tested commit
Infrastructure de développement L’analyse de l’existant  14
Dans le but d’avoir plusieurs unités de compilation,Teamcity dispose d’ « agents ».
Ces agents sont en fait des unités de compilation,il est ainsi possible de faire tourner
plusieurs builds simultanément.Toutefois,compiler demande des ressources importantes.
C’est pourquoi il est possible de placer ces agents à distance
9
.
Teamcity possède lui aussi plusieurs licences.Tout d’abord,il existe une licence ap-
plicable pour les projets non commerciaux et open source.Cette licence,« Open Source
License » ne possède aucune restriction des fonctionnalités.Ensuite vient la « Professio-
nal Server License » destinée aux projets propriétaires,que se soit commercial ou non.
Cette licence possède des restrictions d’utilisation,mais elle reste totalement gratuite.Ces
restrictions sont:
 un maximum de vingt utilisateurs;
 un maximum de vingt builds;
 un maximum de trois agents;
 authentification basique seulement (donc,pas de support LDAP).
La licence spécialement conçue pour les entreprises est « Entreprise Server License ».
Cette licence retire la restriction du nombre d’utilisateurs et du nombre de builds.Ce-
pendant,un maximum de trois agents est toujours restreint.Par agent supplémentaire
souhaité,il faudra payer un complément.
2.2.4 Jira
Quand un développeur ou un utilisateur fait face à un bug d’une application,il est
intéressant de pouvoir être averti afin de le régler au plus vite.Une solution instinctive
est la communication orale du bug.Il n’est pas difficile de concevoir que ce n’est pas une
solution viable sur de gros projets,dotés d’un nombre conséquent de bugs.
Un peu plus évolué,utiliser une boîte e-mail destiné à recevoir une liste de bugs de
manière à avoir le suivi souhaité.Ce procédé amène cependant à une organisation médiocre
et dépourvue de tout contrôle.Effectivement,rien ne nous assure que la boîte de réception
ne contiendra que des suivis de bugs.Par ailleurs,ce système reste très limité.
Viennent alors les logiciels de suivi de problèmes,mieux connus sous le nom anglais
« bug tracking system».À l’heure actuelle,le marché est inondé de ce type de logiciels et
difficile est le choix.Certains d’entre eux étendent même leurs fonctionnalités en proposant
des outils se rapportant à la gestion de projets,à la gestion des incidents,etc.
C’est le cas de l’outil Jira développé par la société Atlassian
10
.Cet outil est proposé
lui en plusieurs licences:Commercial,Academic,Non-profits and Open Source
projects.Ces licences possèdent les mêmes fonctionnalités.Le choix s’est justifié assez
naturellement,Jira de par son plug-in Greenhopper intègre parfaitement Scrum,la
méthode agile choisie par Manex.
2.2.5 Conclusion sur l’infrastructure de développement actuelle
Cette infrastructure est loin d’être mauvaise,c’est pourquoi ces outils ne sont pas à
9.On emploie généralement le mot « remote »
10.http://www.atlassian.com
Infrastructure de développement L’analyse de l’existant  15
exclure de la nouvelle infrastructure dont je suis amené à proposer.Les avantages et in-
convénients doivent être posés clairement.Ces derniers dépendent de plusieurs paramètres.
Notamment,on retrouve le prix des logiciels utilisés ainsi que leurs conditions d’utilisation.
Ensuite,l’attente des développeurs de Manex influence également les choix à prendre.
Chapitre
3
Etude de la nouvelle infrastructure
Ce chapitre illustre la partie du travail qui a demandé le plus de réflexions sur les
choix des outils que j’allais proposer à Manex.Ce choix ne peut être fait à l’aveugle
sans se plonger dans la documentation de chacune des alternatives afin de pouvoir fixer
les avantages et les inconvénients de chaque solution.D’autant plus que la difficulté ne
s’arrête pas là.Les choix des solutions doivent dépendre de plusieurs critères capitaux:
 la licence:Manex s’est spécialisée dans des solutions « open source ».Le budget de
l’entreprise est quelque chose qui ne peut être négliger;
Note
Ètant adhérent aux logiciels libres,je me suis vite senti dans mon élément.J’ai pu
alors proposer ce type de logiciels sans problème,dans la limite du possible.Effective-
ment,certains de mes choix n’ont pas pu suivre cette philosophie.Bien entendu,une
justification est mise en avant de chacun des choix au fur et à mesure du document.
 l’intégration des logiciels entre-eux:Il serait avantageux d’avoir une infrastructure de
développement qui s’intègre au mieux.Ainsi,que l’intervention « homme - machine »
soit réduit à son maximum afin de ne pas perdre du temps inutilement;
3.1 Outils de « build java »
Commençons par définir ce qu’est un « build ».Ce mot est tiré de l’anglais et signi-
fie « construire » en français.À sa plus simple fonctionnalité,cela reprend l’ensemble des
tâches à effectuer afin d’obtenir un produit exploitable.Au fur et à mesure de l’évolution,
de nombreux ajouts ont été effectués.Par exemple,un outil évolué permet d’exécuter des
tests unitaires,de générer des rapports basés sur l’analyse du code ou encore déployer
l’application sur un dépôt (par exemple un « jar ») ou un serveur d’applications (« war »).
L’avantage de ce genre d’outil se fait sentir assez naturellement.Ils permettent d’obte-
nir un gain de temps considérable en automatisant les tâches fastidieuses,répétitives et
ennuyantes.
3.1.1 Compilation manuelle
16
Outils de « build java » Etude de la nouvelle infrastructure  17
La compilation manuelle est la manière la plus simple de procéder afin de construire
son application.Sur de petits projets,cette solution est en effet viable,mais rares sont les
applications au nombre faible de fichiers:la perte de temps devient de plus en plus signi-
ficative quand le projet devient relativement important.En effet,même si la modification
n’est portée qu’à un seul endroit,l’ensemble des fichiers de l’application est recompilé.Cela
prend rapidement un temps considérable vu le nombre de fois où l’on invoque le processus
de compilation en cours de développement.D’autre part,les lignes de commandes sont
souvent longues et fastidieuses cependant,une solution envisageable est d’écrire un script
afin d’automatiser ce mécanisme pour obtenir l’artefact souhaité.
Pour résoudre ces problèmes,il nous faut ce qu’on appelle un"moteur de production":
un logiciel capable d’automatiser l’ensemble des tâches à effectuer pour obtenir l’application
exploitable.Le célèbre outil Make issu des systèmes unix répond parfaitement à ce besoin.
Son intérêt principal est qu’il permet,grâce à son fichier « Makefile » (par défaut),de gérer
les dépendances entre les différentes sources et ne compiler que ce qui est nécessaire avant
de faire intervenir l’éditeur de liens.
1
Make date de 1977,il se fait vieux.Bien qu’il soit tout à fait possible de construire
une application Java avec Make,ll reste moins adapté.Cela se justifie d’une part par la
maintenance complexe des fichiers « Makefile » qui ne cesse d’accroître selon la complexité
du projet.D’autres parts,Make est un outil dépendant de l’OS.Cela va à l’encontre de
la technologie Java.Ci-dessous se trouve un exemple très basique de fichier Makefile.
1 JC = javac
2 JFLAGS = -g
3
4.SUFFIXES:.java.class
5.java.class:
6 $(JC) $(JFLAGS) $*.java
7
8 CLASSES =\
9 a.java\
10 b.java\
11 c.java\
12 d.java
13
14 default:classes
15
16 classes:$(CLASSES:.java=.class)
17
18 clean:
19 $(RM) *.class
 les lignes 1 et 2 définissent respectivement le compilateur et les options de compila-
tion;
 la ligne 4 permet d’ajouter à la liste des extensions connues par Make les extensions
«.java » et «.class »;
 la ligne 5 spécifie que chaque fichier dont l’extension est «.java » sera transformé en
fichier «.class » grâce à la commande se trouvant à la ligne 6;
1.Make est un outils extrêmement puissant.Plus de détails sont disponibles sur http://www.gnu.
org/software/make/manual/make.html
Outils de « build java » Etude de la nouvelle infrastructure  18
 les lignes 8,9,10,11 et 12 déclare la liste des fichiers Java;
 la ligne 14 spécifie le point d’entré à l’outil Make;
 la ligne 14 déclare une macro.La syntaxe d’une macro se déclare ainsi:$(m:s1 = s2).
Cela se traduit par « déclarer la macro nommé m et remplacer tout s1 par s2 ».Ici,
cela à pour effet de remplacer tous les fichiers dont l’extension est «.java » se trouvant
dans CLASSES par l’extensions «.class »;
 la ligne 16 défini la cible clean afin de nettoyer le répertoire de travail;
 concernant la ligne 17,$(RM) est une macro pré-définie par make qui remplace la
commande « rm -f ».
3.1.2 Apache Ant
En vue de résoudre les problèmes soulevés à la sous-section 3.1.1,une alternative est
proposée:Apache Ant.Ce logiciel,développé à la base pour Tomcat,est développé en
Java ce qui lui assure une très grande portabilité (à condition de posséder une machine
virtuelle Java soit disponible sur le système).Le fichier de configuration d’une application
utilisant Ant se base sur XML (« build.xml » par défaut),ce qui soulage certainement les
détracteurs des tabulations avec l’outil Make.
1 <project name="sample"default="compile"basedir=".">
2 <description >just a simple example build file </description >
3 <property name="src"value="src"/>
4 <property name="build"value="build"/>
5 <property name="dist"value="dist"/>
6
7 <target name="init">
8 <mkdir dir="${build}"/>
9 </target >
10
11 <target name="compile"depends="init">
12 <javac srcdir="${src}"destdir="${build}"/>
13 </target >
14
15 <target name="dist"depends="compile">
16 <mkdir dir="${dist}/lib"/>
17 <jar jarfile="${dist}/lib/sampleProject.jar"basedir="${
build}"/>
18 </target >
19
20 <target name="clean">
21 <delete dir="${build}"/>
22 <delete dir="\${dist}"/>
23 </target >
24 </project >
 la ligne 1 indique le nom du projet,la cible par défaut à appeler ainsi que la base du
répertoire de travail;
 la ligne 2 décrit basiquement le projet;
 les lignes 3,4 et 5 déterminent les propriétés du build;
 les lignes 7,8 et 9 définissent la cible « init » et créent le répertoire « build »;
Outils de « build java » Etude de la nouvelle infrastructure  19
 les lignes 11,12 et 13 définissent la cible « compile »,dépendante de la cible « init »
et qui appelle la tâche « javac ».Cette dernière est chargée de compiler les sources
dans le répertoire « src » à destination du répertoire « build »;
 la ligne 15 définit la cible « dist »,dépendante de la cible « compile »;
 la ligne 16 crée le répertoire « dist/lib »;
 la ligne 17 appelle la cible « jar » afin de créer le jar « dist/lib/sampleProject.jar »
en plaçant à l’intérieur l’ensemble du répertoire « build »;
 pour finir,les lignes 20,21,22 et 23 définissent la cible « clean » afin d’éffacer les
répertoires « build » et « dist ».
L’outil Ant dispose d’une vaste panoplie de tâches.L’ensemble des tâches standards
ainsi que leurs documentations est disponible sur http://ant.apache.org/manual/tasksoverview.
html.
Sa popularité lui permet d’être intégré dans de nombreux outils,comme la plupart
des IDE,les outils d’intégrations continues,etc.Malgré tous ses atouts fort intéressants,
Apache Ant possède des lacunes.Tout d’abord,il n’existe pas une DTD pour le des-
cripteur du projet.Cela empêche donc d’avoir une convention dans les scripts,ce qui
amène rapidement à une complexité non négligeable.De plus,il ne permet pas de gérer les
dépendances directes aux bibliothèques nécessaires à une application.
Apache Ivy
Ce dernier problème est résolu par l’extension Ivy,développé par la même Fondation.
Son fichier de configuration (« ivy.xml » par défaut),également écrit en xml,permet donc
de récupérer les bibliothèques nécessaires à un projet.La figure 3.1 montre un exemple de
« ivy.xml »,précisant les dépendances aux bibliothèques commons-lang et commons-
cli.
1 <ivy -module version="2.0">
2 <info organisation="apache"module="hello -ivy"/>
3 <dependencies>
4 <dependency org="commons -lang"name="commons -lang"rev
="2.0"/>
5 <dependency org="commons -cli"name="commons -cli"rev="
1.0"/>
6 </dependencies>
7 </ivy -module>
Listing 3.1 – Exemple d’un fichier de configuration:ivy.xml
1 <project xmlns:ivy="antlib:org.apache.ivy.ant"name="example -
ivy"default="run">
2 <target name="resolve"description="ant and ivy example">
3 <ivy:retrieve/>
4 </target>
5 </project>
Listing 3.2 – Exemple d’un fichier Ant avec utilisation d’Ivy
La combinaison des deux outils Ant et Ivy permet de remédier à un problème majeur
d’Ant:la gestion des dépendances.De plus,Ivy est capable de générer des rapports clairs
Outils de « build java » Etude de la nouvelle infrastructure  20
sur les dépendances utilisées par un projet.Cependant,tous les défauts d’Ant ne sont pas
résolus.
3.1.3 Maven 2
Maven introduit une nouvelle manière de spécifier le build d’un projet.Que ce soit
Make,Ant ou encore Ant + Ivy,tous demandent un fichier décrivant la manière de
procéder afin d’aboutir au résultat voulu.Quant à l’approche de Maven,il demande sim-
plement une description du projet.C’est grâce à cette description qu’il est capable d’ef-
fectuer un build.Pour pouvoir réaliser cela,Maven se base sur un pattern:« Convention
over Configuration »
2
.Ce pattern permet de réduire le nombre de fichiers de configuration
en se basant sur des conventions et en proposant un paramétrage par défaut.
Il serait judicieux de parler des autres avantages qu’offre cet outil au concept nouveau.
Standardisation
Tout d’abord,il permet d’homogénéifier la structure des différents projets:il pro-
pose ainsi une certaine normalisation.Cette caractéristique permet aux développeurs de
se familiariser plus rapidement à un projet qu’il ne connait pas.
La figure 3.1 illustre la structure standard des répertoires d’un projet.
Figure 3.1 – Structure standard des répertoires avec Maven
A la racine du répertoire se trouve un fichier xml « pom.xml ».pom signifie « Project
Object Model ».De plus,il peut apparaître différents fichiers texte:« README.txt »,
« LICENSE.txt »,etc.
2.Aussi connu sous le nom de Coding by Convention
Outils de « build java » Etude de la nouvelle infrastructure  21
Ensuite,deux sous répertoires:« src » et « target ».Les seuls autres répertoires qui
pourraient apparaître ici sont des répertoires de meta-données.Par exemple:«.svn ».
Le répertoire « target » contient les fichiers de sortie du build.
Le répertoire « src » contient l’ensemble des sources du projet.Il contient lui aussi
des sous répertoires:« main » contenant les sources qui serviront à la construction de
l’artefact,« test » contenant les tests unitaires et « site » contenant les fichiers du site web
qui peut être généré par Maven.
Les répertoires « src » et « test » disposent chacun d’un sous répertoire « java » conte-
nant la hiérarchie des packages « Java » de l’application.De plus,le sous répertoire « re-
sources » pouvant contenir les ressources diverses de l’application.
La standardisation de Maven 2 ne s’arrête pas sur la structure des répertoires d’un pro-
jet.Elle agit également sur le nommage des artefacts.Chaque dépendance est nommée par
un groupId,un artifactId,une version et optionnellement un classifier.Le grou-
pId représente l’entité qui a créé l’artefact.Par exemple pour la bibliothèque Hibernate,
le groupId est « org.hibernate ».L’artifactId représente le nom à proprement dit de la
bibliothèque.Pour n’avoir que le core d’Hibernate,l’artifactId est « hibernate-core ».
Ensuite,la version spécifie,comme son nom l’indique,la version de l’artefact souhaité.Par
exemple,« 3.3.2.GA».Le classifier permet de spécifier la plateforme de la dépendance.
Il arrive que certaine dépendance ne soient nécessaires que sous une certaine plateforme.
Il est donc inutile de l’utiliser si le build ne s’effectue pas sur la plateforme renseignée.
Conventionnellement,chaque artefact est donc nommé de la façon suivante:
artifactId-version-[classifier].extension.
3
Avec l’exemple d’Hibernate-core cela
donne:« hibernate-core-3.3.2.GA.jar ».Le groupId ne se trouve donc pas directement
dans le nomde l’artefact.Il permet de spécifier le chemin d’accès à l’artefact dans le dépôt.
Ainsi,toujours pour Hibernate-core,l’artefact sera situé dans le répertoire « org/hiber-
nate/».
Réutilisabilité
Le commencement d’un nouveau projet est toujours fastidieux.Il est souvent néces-
saire d’y consacrer un temps assez conséquent afin de le configurer:une perte de temps
récurrente.Afin de résoudre le problème,le concept d’archétype est introduit par Maven
et plus particulièrement,par le plug-in archetype.Un archétype est en fait un patron
(template) qui permet de créer un projet Maven.
Le tableau 3.1 décrit la gestion des archétypes par le plugin archetype.
3.Les élements entre crochets sont facultatifs
Outils de « build java » Etude de la nouvelle infrastructure  22
Table 3.1 – Liste des goals du plugin archetype
Goal
Description
archetype:create Obsolète - il faut utiliser generate (existe par
compatibilité).
archetype:generate
Crée un projet Maven à partir du catalogue
d’archétypes (une liste d’archétypes par défaut
existe).
archetype:create-from-project Récupère l’archétype à partir d’un projet exis-
tant.
archetype:crawl
Crée un catalogue XML (par défaut
« archetype-catalog.xml ») à partir d’un
dépôt.
Dans le cadre de la société Manex,la plupart des projets utilisent le framework Spring
et se conforme au modèle mvc (plus particulièrement Spring mcv).
Chaque projet se compose d’au moins deux modules:core et web.
core Inspiré du modèle Core JE22 Pattern,contient notamment les dao,les modèles
de données (« data model ») etc.Les dao offrent un niveau d’abstraction en encapsulant
tous les accès aux données.La figure 3.2 décrit le pattern dao.
Figure 3.2 – Diagramme de classe décrivant le pattern DAO
Un modèle de données est un modèle abstrait qui décrit la façon dont les données sont
représentées dans un système d’information.
web Ce répertoire contient l’application web destinée à être déployée (war).
Communication
Lorsque le nombre de développeurs qui travaillent sur un projet s’accroît,la commu-
nication joue un rôle de plus en plus important.Maven propose de créer un site web
hautement personnalisable,notamment au moyen de nombreux plug-ins.
Outils de « build java » Etude de la nouvelle infrastructure  23
Par exemple,le site peut contenir différentes sortes de rapports:
javadoc génère la javadoc du projet.
pmd génère un rapport PMD.
surefire-report génère un rapport basé sur les résultats des tests unitaires.
project-info-reports génère les rapports standards de Maven.
...
Codehaus
4
propose une liste de plug-ins supplémentaires.Dashboard est un plugin
permettant de centraliser les rapports"standards"de Maven (cobertura,clover,checkstyle,
pmd,findbugs,...).L’image 3.3 illustre l’architecture de ce plug-in.
Figure 3.3 – Architecture du plugin dashboard
Gestion des dépendances
Les dépôts Maven sont utilisés pour stocker des plug-ins et des bibliothèques.Maven
télécharge automatiquement les dépendances nécessaires lorsqu’il ne les trouve pas en local
ou encore,quand le plug-in invoqué n’est pas trouvé.
Le dépôt central de Maven est disponible sur http://repo1.maven.org/maven2.Ma-
ven propose la possibilité d’utiliser un miroir,en configurant le fichier «/.m2/settings.xml »
de la sorte:
1 <settings >
2...
3 <mirrors >
4 <mirror >
4.http://codehaus.org
Outils de « build java » Etude de la nouvelle infrastructure  24
5 <id>id-mirror </id>
6 <name >name -of-mirror </name >
7 <url >url -of-mirror </url >
8 <mirrorOf >*</mirrorOf >
9 </mirror >
10 </mirrors >
11...
12 </settings >
La figure 3.4 illustre le scénario le plus basique où la dépendance se trouve dans le
dépôt local.Quant à la figure 3.5,celle ou la dépendance ne se trouve pas localement,mais
sur un dépôt distant.
Figure 3.4 – Scénario quand la dépendance se trouve localement
Figure 3.5 – Scénario quand la dépendance se trouve à distance
Historique
Maven 1 Créé en 2002 comme sous-projet du projet Jakarta Alexandria.Il fut
ensuite intégré au projet Turbine d’Apache.En 2003,il est considéré comme un projet
à part entière.La première version de cet outil a eu difficile à s’instaurer dans le monde
Java
5
Maven 2 En 2005,la version 2 de l’outil sort.Cette version n’est pas rétrocompatible,
mais améliora de façon impressionnante le logiciel.Au contraire de sa version 1,la deuxième
version perce dans le monde de l’entreprise et beaucoup d’entres-elles ont migré d’Ant à
Maven 2.Manex se prépare à faire de même.Pour faciliter la conversion,Maven 2
5.Le leader du projet,« Jason Van Zyl » a reconnu que Maven 1 était une expérimentation lors de la
conférence Devoxx.
Outils de « build java » Etude de la nouvelle infrastructure  25
supporte des « builds » Ant grâce à Maven Ant Tasks.En soi,ce n’est pas la meilleure
façon de faire,mais cela permet de convertir les anciens projets avec un gain de temps
considérable.Cependant,Maven 2 est critiqué par la communauté sur bon nombre de
points.Le principal défaut est certainement la complexité de son noyau.D’une part à
cause de certains choix d’architecture,mais aussi à l’utilisation du framework Plexus
(permettant notamment d’appliquer le pattern IoC,l’injection de dépendances,etc.) assez
complexe.Ceci amène à ce que la communauté ne s’occupe que très peu de l’évolution du
code de Maven,hormis par le biais des plug-ins,très nombreux.
Maven 3 À l’heure où ce document est écrit,Maven 3 n’est pas encore sorti officiel-
lement (une version « beta-1 » est disponible),mais il ne devrait pas tarder.Le principal
apport annoncé est la réécriture complète du noyau.Le projet abandonne le framework
Plexus au profit de Google Guice afin de gérer les injections de dépendances.
3.1.4 Gradle
Gradle est un outil avancé reprenant les avantages de l’ensemble des outils cités
précédemment.Contrairement aux autres outils,il permet d’écrire les descripteurs de build
en Groovy.Ce dernier est un langage orienté objet destiné à la plateforme Java.Il a été
inspiré par de nombreux autres langages tels que Smalltalk,Perl,Python ou encore
Ruby.Le listing 3.3 illustre un exemple basique de configuration d’un projet.
1 usePlugin ’java’
2
3 sourceCompatibility = 1.6
4 version = ’1.0’
5 manifest.mainAttributes(
6 ’Implementation -Title’:’Gradle example’,
7 ’Implementation -Version’:version
8 )
9
10 repositories {
11 mavenCentral()
12 }
13
14 dependencies {
15 compile group:’commons -collections’,name:’commons -
collections’,version:’3.2’
16 testCompile group:’junit’,name:’junit’,version:’4.+’
17 }
18
19 uploadArchives {
20 repositories {
21 flatDir(dirs:file(’repos’))
22 }
23 }
Listing 3.3 – Exemple de fichier build.gradle écrit en Groovy
 la ligne 1 précise à Gradle que les sources sont écrites en Java;
Maven 2 Etude de la nouvelle infrastructure  26
 la ligne 3 renseigne sur la compatibilité des sources Java.Ici,elles sont écrites pour
être supportées par la version 1.6 d’une JVM;
 la ligne 4 indique la version du projet;
 les lignes 5,6,7 et 8 fixent des attributs dans le fichier « MANIFEST ».Ici est
indiquée le nom du projet ainsi que sa version;
 les lignes 10,11 et 12 permettent d’indiquer sur quel repository récupérer les dépen-
dances nécessaires au projet;
 les lignes allant de la 14 à la 17 indiquent quelles dépendances sont nécessaires.Ici
est indiqué une dépendance vers la commons-collections et JUnit;
 enfin,les lignes 19,20,21 et 22 définissent comment sera déployé l’artefact.
Gradle possède de nombreux avantages ou plus exactement,résout les désavantages
des outils de build tels que Make,Ant ou encore Maven 2.Effectivement,parmi les désa-
vantages de Maven 2,on retrouve sa verbosité.Grâce à son langage Groovy,Gradle ne
peut être accusé de cet inconvénient.D’autant plus que ce langage est bien plus puissant
que l’XML,utilisé par son rival.
Bilan du choix de l’outil de build Java
Compte tenu de la description de chacun de ses outils,il en va de soit que Gradle
à l’air d’être la solution adaptée.Cependant,cet outil souffre d’un gros inconvénient:sa
pérennité.En effet,cet outil,bien que très bien conçu,à du mal à s’imposer dans le monde
des entreprises.Maven a également subi le même sort dans sa première version comme
énoncé dans le bref historique consacrée à l’outil (3.1.3.5).Toutefois,cela se justifie par une
autre raison.Principalement dû à ses gros changements entre les versions du projet sans
compatibilité ascendante.Il est important de suivre la tendance afin de viser une solution
à long terme.
De plus,en raison de la popularité de Maven 2,une grosse majorité des projets ont
pris l’initiative de supporter ce nouvel outil.Bien plus que Gradle.L’intégration de
l’infrastructure se fera donc plus efficacement avec l’outil Maven.
Bien que cela suffit à justifier l’utilisation de l’outil Maven,il serait mauvais de perdre
de vue la sortie de Maven 3,imminente.Grâce aux annonces faites par Sonatype,la
société qui l’édite,Maven 3 est promis à un bel avenir grâce aux solutions mises en place
dans le but de faire face aux reproches de la communauté.La version Beta confirme déjà
en grande partie ses engagements.
3.2 Maven 2
Suite au bilan obtenu à la section 3.1,il serait intéressant de détailler l’utilisation de
l’outil Maven 2.Premièrement,je vais détailler la conception d’un fichier POM.Ensuite,
...
Descripteur de projet
Intégration continue Etude de la nouvelle infrastructure  27
La description d’un projet se réalise grâce aux fichiers POM.Un fichier POMs’appelle
conventionnellement « pom.xml ».On en retrouve généralement un par module.Comme
cité à la section 3.1.3.2,Manex a l’habitude d’utiliser notamment un module core et un
module web (pour une application web).Chacun de ces modules disposeront donc de leur
propre « pom.xml ».
Le Listing??montre un exemple très sommaire d’un fichier POM.
 les lignes 1,2,3 et 4 permettent de rendre le pom valide selon un xsd;
 la ligne 5 permet de préciser la version du pom.A ce jour,la dernière étant la 4.0.0;
 les lignes 6,7,8 et 9 donne des renseignements aux projets.De plus amples détails
sont donnés à??;
 les lignes allant de 10 à 22 permettent de configurer le compilateur avec la version
1.6 de Java.De plus,il précise que les sources sont encodées en UTF-8.
3.3 Intégration continue
Le sujet a déjà été introduit à la sous-section 2.2.3.Le choix du logiciel Teamcity est
majoritairement justifié par la prise en compte d’un fichier.ipr.Ce fichier est en fait le
descripteur de projet XML construit par Intellij Idea.Grâce à cette fonctionnalité,il
est extrêmement rapide et simple de créer un nouveau build sur Teamcity.Effectivement,
il suffit de lui renseigner le descripteur et tout est déjà configuré.
Cet avantage n’est bien entendu pas négligeable.Cependant,il ne faut pas perdre
de vue que les.ipr sont propres à Intellij Idea et qu’aucune standardisation n’existe
pour ce descripteur.L’utilisation de ce fichier amène donc à une fermeture,ce qui n’est
généralement pas une bonne chose.
Depuis l’arrivée de l’outil de build Maven 2,les choses ont changé.Effectivement,
Maven 2 s’impose de plus en plus comme étant un standard.De plus,Maven 2 est un
logiciel libre distribué sous licence Apache 2.0.De ces faits,de nombreux outils supportent
les projets Maven 2,comme Teamcity.
Teamcity est propriétaire et payant.Il reste à démontrer que payer pour cet outil est
justifié dans le cas de Manex.Explorons quelques alternatives que propose le marché et
en particulier,celle gratuite.
3.3.1 CruiseControl
CruiseControl est le pionnier des outils d’intégration continue.Il est développé en Java
et distribué sous licence BSD-Style.Longtemps il a été la mascotte des outils de CI dans
le monde des entreprises.Il est capable de supporter des projets « buildé » à l’aide de ligne
de commande,Make,Ant,Maven 1,Maven 2,et bien d’autres encore.CruiseCon-
trol est également extensible au moyen de nombreux plug-ins.
La création de projet est relativement difficile.Du moins plus que beaucoup d’autres
alternatives.En fait,la configuration se fait dans un fichier XML.Elle est donc plus vite
sujette à l’erreur.La configuration de CruiseControl peut être vue comme un avantage
Intégration continue Etude de la nouvelle infrastructure  28
pour certains utilisateurs.D’autres prendront la configuration comme une pénible étape
à franchir.Pour ces utilisateurs,des logiciels graphiques ont été développés.Configu-
rationGUI est une application Java WebStart et Swing.Elle peut être directement
embarquée dans CruiseControl ou bien téléchargée séparément.CCScrape est une
autre alternative,elle aussi disponible par Java WebStart.
L’architecture générale du logiciel se décompose en trois modules:
 Cycle de build:ce module est le coeur de CruiseControl.Il est notamment res-
ponsable de déclencher le cycle des builds au moyen de triggers.Ces triggers sont
capables de faire un poll
6
sur un scm.
 Rapport JSP:ce module permet à l’utilisateur de parcourir les résultats des builds
et accéder à leurs artefacts via une interface web.
 Dashboard:la dashboard résume l’état de l’ensemble des builds du système.
La Figure 3.6 schématise cette architecture.
Figure 3.6 – Architecture de CruiseControl
3.3.2 Apache Continuum
Apache Continuum est développé sous licence Apache 2.0 et est donc également
libre.Comme pour CruiseControl,il est disponible en tant qu’application standalone
(en utilisant Jetty),soit en fichier «.war » destiné à être déployé dans un conteneur
de servlet,par exemple Tomcat.Cet outil supporte également de nombreux outils,en
particulier pour Maven 2.
À la différence de CruiseControl,Continuum fonctionne comme un serveur qui
peut être partagé par de multiples projets.Ce n’est pas le cas de CruiseControl.Ce
dernier impose que chaque projet maintienne son propre « build loop ».Continuum est
donc un serveur centralisé.Il centralise non seulement tous les projets ainsi que leurs builds
respectifs,mais aussi d’autres ressources telles que la Javadoc,les artefacts,etc.
Continuum est capable d’ajouter un nouveau projet uniquement grâce au fichier
6.Un poll est traduit par « sondage ».Toutefois le terme anglais est beaucoup plus répandu.
Intégration continue Etude de la nouvelle infrastructure  29
« pom.xml ».Pour récupérer les sources du projet sur un scm,il se base sur les balises
scm contenues dans le pom.Le Listing 3.4 illustre un exemple de balise scm.
1 <project xmlns="http://maven.apache.org/POM/4.0.0"
2 xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance"
3 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http:
//maven.apache.org/xsd/maven -4.0.0.xsd">
4...
5 <scm>
6 <connection>scm:svn:https://svn.manex.biz/my-project</
connection>
7 <url>https://websvn.manex.biz/my-project</url>
8 </scm>
9...
10 </project>
Listing 3.4 – Exemple de balise scm dans un « pom.xml »
 La ligne 5 et 8 ouvre les balises qui permettent de spécifier un scm.
 La ligne 6 spécifie l’url du scm.Ici,le scm utilisé est Subversion.
 La ligne 7 indique l’url d’un browser scm.Ce dernier est capable d’effectuer des fonc-
tionnalités avancées telles qu’afficher le code source avec la colorisation syntaxique,
de comparer deux versions d’un même fichier,etc.Ici,WebSVN a été choisi.
Bien entendu,il est possible de configurer le scmdirectement dans l’interface de Conti-
nuum si cette information ne se trouve pas dans le fichier pom.
L’intégration avec Maven 2 est une bonne chose dans le cas de Manex.Toutefois,
l’intégration avec Ant est aussi puissante.Il est juste nécessaire de lui spécifier le scm
ainsi que le descripteur de build (généralement « build.xml ») et Continuum se charge du
reste.
Contrairement à CruiseControl,la configuration se fait directement dans l’interface
Web.Il n’est plus ici question de travailler directement sur des fichiers XML.Cela a pour
avantages d’être beaucoup plus intuitif et simple et donc,d’éviter un bon nombre d’erreurs.
3.3.3 Hudson
Hudson est également développé en Java et possède une licence libre.Ce logiciel est
créé par « Kohsuke Kawaguchi »
7
.
Difficile est de parler d’Hudson après avoir parlé d’ Apache Continuum.En effet,
pratiquement toutes les fonctionnalités dans l’un se retrouvent dans l’autre.Afin de choisir
l’outil qui sera utilisé,procédons directement au bilan.
3.3.4 Bilan du choix de l’outil d’intégration continue
Ce comparatif est loin d’être exhaustif.Il existe de nombreux outils d’intégration conti-
nue.Une première sélection a été faite sur la licence.Il n’était pas question que je propose à
7.A l’heure actuelle,Kohsuke Kawaguchi vient de partir de chez Sun/Oracle
Intégration continue Etude de la nouvelle infrastructure  30
Manex de remplacer Teamcity par un autre logiciel propriétaire.Deuxièmement,il était
préférable que cet outil soit développé en Java.De plus,l’outil Maven 2 doit être supporté
au mieux.Nous avons donc retenu trois solutions.CruiseControl se justifie par le fait
qu’il a été le pionnier des outils d’intégration continue.Ensuite viennent Continuum et
Hudson.Ceux-ci sont loin d’être facile à départager.
Note
Le but ici n’est pas de comparer tous les outils d’intégration continue existants.Ce
travail a déjà été fait et est disponible sur:http://confluence.public.thoughtworks.
org/display/CC/CI+Feature+Matrix.Je conseille de s’y intéresser pour faire le choix le
plus adapté à la situation.
CruiseControl a été vite mis de côté.D’une part,cela se justifie par sa complexité.
D’autres parts,celui-ci se fait vieux et d’autres alternatives plus intéressantes existent au-
jourd’hui.Restent ensuite Apache Continuum et Hudson.Pour ma part,j’ai préféré
utiliser Hudson.Premièrement,je l’ai trouvé plus intuitif et plus simple tout en étant ex-
trêmement puissant.De plus,il dispose d’une plus grande communauté que son « rival ».
Il en devient même de plus en plus une référence dans ce domaine.Cela nous assure proba-
blement une meilleure pérennité.Cet argument est d’autant plus important dans le monde
des entreprises.De plus,ce dernier dispose d’un choix impressionnant de plug-ins ce qui lui
permet d’évoluer rapidement vers une solution optimale aux besoins requis.L’argumenta-
tion sera de plus en plus valable sur le choix d’Hudson par la suite.Particulièrement au
moment de l’intégration de l’ensemble de la nouvelle infrastructure.
Pour l’instant,l’infrastructure se présente comme la Figure 3.7 le montre.À noter que
Maven A et Maven B représentent deux installations différentes de l’outil.
Figure 3.7 – Infrastructure actuelle 1
Note
La Figure 3.7 illustre l’utilisation d’ Intellij Idea en tant qu’IDE.Manex est fort
Gestionnaire de dépôts Etude de la nouvelle infrastructure  31
attaché à ce logiciel et il n’était pas question de le remplacer.J’adhère personnellement à
ce choix malgré que celui-ci reste propriétaire dans sa version Ultimate.
3.4 Gestionnaire de dépôts
Le choix de l’outil Maven amène à un nouveau problème.Pour le comprendre,il faut
se mettre à la place d’une équipe de développement.Tous les développeurs effectuent un
check out sur un scm afin de récupérer les sources d’un projet Maven.Vu que le projet
ne contient plus les bibliothèques nécessaires à l’application,chacun des développeurs est
amené à les télécharger (bien entendu automatiquement grâce à Maven) sur un dépôt
distant si la dépendance n’est pas trouvée localement («.m2/repository »).Cela demande
donc une utilisation considérable de la bande passante,mais surtout une perte de temps.
Une première solution serait de disposer d’un endroit centralisé (serveur ftp,svn,etc.)
contenant la liste de toutes les dépendances.Ainsi,lorsqu’un développeur a besoin d’une
d’entre elles,il la télécharge et l’installe au moyen de la commande montrée au Listing 3.5.
1 mvn install:install -file -DgroupId=xxx -DartifactId=xxx -
Dversion=xxx -DgeneratePom=true -Dpackaging=jar -Dfile=xxx
Listing 3.5 – Installation manuelle d’une dépendance
Cette solution apporte une solution parfaitement adaptée à l’utilisation de la bande
passante.De plus,disposer d’un endroit centralisé regroupant l’ensemble des bibliothèques
permet de réduire le risque de conflit entre les versions d’une même bibliothèque.Cepen-
dant,cela prend toujours autant de temps.
Entrent en jeu alors les gestionnaires de dépôts.Ils agissent tels des proxys entre Maven
et le dépôt disposant de la dépendance nécessaire.Ainsi,si la dépendance nécessaire à un
projet ne se trouve pas dans le dépôt local («.m2/repository »),Maven la récupère sur le
gestionnaire de dépôts.Si ce dernier la possède,il l’envoie sinon,il la télécharge et l’ajoute
à sa base de données.La bande passante est donc mieux préservée puisque le gestionnaire
est généralement installé dans le réseau local,ce qui implique des taux de transfert très
rapide.L’architecture classique sans gestionnaire de dépôts est représentée à la Figure??.
La Figure??représente l’architecture avec un gestionnaire de dépôts.
Plusieurs alternatives existent.La concurrence se fait rude et difficile est le choix.Un
comparatif
8
s’impose afin de répondre au mieux aux besoins de Manex.
8.Un tableau comparant Archiva,Artifactory et Nexus est disponible sur http://docs.codehaus.
org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix.Ce dernier est fort complet,mais
possède tout de même quelques petites erreurs.
Gestionnaire de dépôts Etude de la nouvelle infrastructure  32
Figure 3.8 – Scénario classique sans gestionnaire de dépôts
Figure 3.9 – Scénario classique avec gestionnaire de dépôts
Gestionnaire de dépôts Etude de la nouvelle infrastructure  33
3.4.1 Dead Simple Maven Proxy (DSMP)
dsmp est utilisé en tant que proxy.Il autorise Maven à accéder aux dépôts distants.
Ainsi,il reste possible de récupérer les dépendances nécessaires sur un dépôt distant même
si les postes clients ne peuvent pas accéder à Internet.Toutefois,dsmp n’est pas exactement
un gestionnaire de dépôt car,il ne permet pas de stocker les fichiers récupérés.
3.4.2 Codehaus Maven-proxy
Maven-proxy fonctionne en standalone ou sous forme de war déployable sur n’im-
porte quel « servlet container ».Il est conçu pour ne remplir que la fonction de proxy entre
Maven et les dépôts distants.La différence fondamentale avec dsmp est qu’il permet
de stocker les fichiers récupérés.Ils ne disposent seulement pas d’outil d’administration.
Par conséquent,il n’est notamment pas possible de gérer des permissions avancées sur les
utilisateurs de cette application.
3.4.3 Apache Archiva
Comme souvent Apache Archiva peut fonctionner en standalone (serveur Jetty)
ou distribué sous forme de war.Les artefacts sont stockés dans une base de données.Par
défaut,Archiva utilise la base de données Derby.Cette dernière est créée également par
Apache.Toutefois,il est possible d’utiliser d’autres bases de données telles que MySQL,
PostgreSQL,etc.
Archiva propose une interface conviviale.Il dispose d’un support réseau utilisant la
technologie WebDAV
9
.Malheureusement,cet outil ne supporte pas rest
10
.WebDAV
est réputé pour être plus lourd et lent que Rest.
3.4.4 Nexus
Nexus est maintenu par Sonatype.Cette société édite également Maven.Comme
pour Maven 2,Nexus utilise le framework Plexus.Ces points forts résident d’une part
par sa légèreté.En effet,cette application ne requiert que de 28 Mo de ram après sont
installation par défaut.A titre comparatif,Archiva en utilise 128.
Nexus utilise le système de fichier afin de sauvegarder les fichiers du dépôt.Aucune
base de données n’est donc nécessaire.De plus,il dispose de son propre indexeur de fichiers:
« Nexus-indexer » réputé pour être plus performant que l’indexeur Apache Lucene utilisé
notamment par Archiva.
Le problème de Nexus est qu’il offre une version professionnelle et qu’uniquement
celle-ci supporte une authentification des clients par ldap.
9.WebDAV (rfc 2518) permet d’étendre le protocole http.Il permet de récupérer,déposer,synchro-
niser et publier des fichiers sur un serveur distant.
10.Rest est un style d’architecture pour les systèmes distribués.
Gestionnaire de dépôts Etude de la nouvelle infrastructure  34
3.4.5 Artifactory
Artifactory est quant à lui développé par la société JFrogs.Il possède de nombreux
points communs avec Archiva.
Notamment,on retrouve un stockage des fichiers dans une base de données Derby (par
défaut) qui peut également être changée.De plus,le pattern IoC est géré par le framework
Spring.Artifactory utilise le même indexeur que Nexus,plus performant que celui
d’Apache.Enfin,Artifactory possède plus ou moins la même consommation mémoire
qu’Archiva sur une installation de base.
Il est très facile de configurer cet outil.Il dispose d’une interface Web très complète et
intuitive conçue principalement en Ajax.
Artifactory permet de gérer une authentification par LDAP.Toutefois,les groupes
ne sont pas supportés dans la version « open-source ».Cette fonctionnalité est disponible
en add-on et est payante.
L’upload de fichiers se fait grâce à Http/Rest.Il supporte également le protocole
WebDAV.
3.4.6 Bilan du choix du gestionnaire de dépôt
dsmp et Maven-proxy sont rapidement mis de côté.Ceux-ci ne sont pas de mauvais
outils,mais offrent des fonctionnalités fortes limitées.D’une part,DSMP ne permet pas de
stocker les fichiers téléchargés.Cela pose un problème au niveau de la vitesse de téléchar-
gement et de la consommation de la bande passante.Ce n’est pas le cas de Maven-proxy.
Cependant,cet outil reste fort limité en fonctionnalité par rapport à d’autres gestionnaires
de dépôts tels qu’ Archiva,Nexus ou encore Artifactory.
Nexus a été longtemps en retard par rapport à ses concurrents.Ce n’est plus le cas au-
jourd’hui.Il reste un très bon outil.Cependant,de nombreuses fonctionnalités intéressantes
ne sont disponibles que dans la version payante.Utiliser le système de fichier n’est pas une
mauvaise chose,mais il est préférable d’utiliser une base de données dans le cas de Manex.
Toutes les applications ayant besoin d’un stockage de données utilisent PostgreSQL.
Note
Le blog officiel de Nexus a publié un article qui compare son outil avec Artifactory.
Les reproches fait sur Artifactory ne sont pas tous vrais.Ce manque de professionna-
lisme a également influencé mon choix.L’article officiel est disponible sur http://www.
sonatype.com/people/2009/01/contrasting-nexus-and-artifactory/.La réponse faite
par JFrogs est disponible sur http://blogs.jfrog.org/2009/01/contrasting-artifactory-and-nexus.
html.
Il est difficile de choisir entre Archiva et Artifactory.Ces deux outils sont de très
bonnes qualités et disposent de nombreux points communs.Artifactory semble tout de
Analyse de codes Etude de la nouvelle infrastructure  35
même plus complet,surtout au niveau de la gestion des artefacts.
De plus,l’intégration avec d’autres outils sera plus efficace avec l’outil de JFrogs.Le
choix se porte donc sur l’outil Artifactory.
Avec l’arrivée d’Artifactory,l’infrastructure en cours de développement est un peu
modifiée.La Figure 3.10 illustre l’infrastructure actuelle:
Figure 3.10 – Infrastructure actuelle 2
3.5 Analyse de codes
Plus un bug est découvert tard et plus sa correction est coûteuse.De nombreuses
façons existent afin de raccourçir le temps de détection d’un bug.On retrouve notamment
les tests unitaires,l’intégration continue,etc.Mais avant d’utiliser ces techniques,il serait
plus optimal d’établir une politique de qualité du code.Pour ce faire,des critères peuvent
être vite mis en place.Par exemple,imposé que le code soit bien documenté ou encore,
qu’il respecte les standards (Java,conventions internes à l’entreprise,etc.).Choisir une
méthode agile permet de respecter ce genre de suggestions.Les outillages techniques mis
en place ne substituent pas la méthode choisie,ils sont complémentaires.
Intellij Idea Code Inspection
IntelliJ Idea fournit plus de 600 règles d’inspections,très utiles lors du développe-
ment.Effectivement,chacun de ces règles est définie comme étant une information,un
warning ou une erreur.Ainsi il apparaît directement dans l’éditeur de code un carré bleu,
jaune ou rouge sur la ligne suivant le type d’alerte défini.Toutefois,utiliser ces règles d’ins-
pections est utile pendant le développement,mais ne peut être intégrée autre pars.Par
Analyse de codes Etude de la nouvelle infrastructure  36
exemple,il faut utiliser Teamcity pour pouvoir bénéficier de cet analyse de codes dans un
logiciel d’intégration continue.En d’autres mots,il faut se fermer sur des technologies pour
pouvoir bénéficier de cet outil.D’autres alternatives ouvertes et plus répandues existent.
3.5.1 Plug-ins Maven 2
Maven 2 apporte son lot de plug-ins permettant de faire de l’analyse de codes.Ceux-ci
se basent sur des outils bien connus dans le monde Java.Une brève introduction à ces
outils est décrite ci-dessous.Il existe pour chaque outil décrit un plug-in permettant de
l’utiliser directement dans Maven 2.
Surefire
Le plug-in Surefire est utilisé pendant la phase de test du cycle de vie de Maven 2.
Il est compatible avec les frameworks unitaires les plus fréquents:JUnit,TestNG,etc.
Ce plug-in ne possède qu’un goal:surefire:test.Il permet de générer le rapport en
« plain text » ou en format xml.Toutefois,il existe le plug-in Surefire Report permet
de générer un rapport basé sur les résultats du plug-in Surefire au format html.Le goal
surefire-report:report permet de générer ce rapport.
Corbetura
Corbetura est un outil Java qui permet de calculer le pourcentage de code couvert
par des tests unitaires.Cette information est capitale.Effectivement,ce n’est pas parce
qu’il y a beaucoup de tests unitaires que ceux-ci couvrent l’ensemble du projet.Certaines
parties critiques peuvent se retrouver peu ou pas testées.
CheckStyle
Checkstyle est un outil qui aide le développeur à écrire du code standard.Ce
standard peut être celui établi par Sun (http://java.sun.com/docs/codeconv/html/
CodeConvTOC.doc.html),par Apache Turbine (http://turbine.apache.org/common/
code-standards.html),etc.Les règles définies sont toutes paramétrables dans un fichier
xml.Il est donc possible de créer son propre standard.La liste de ces règles est disponible
sur http://checkstyle.sourceforge.net/availablechecks.html
PMD
pmd est un outil qui permet de scanner du code Java et de détecter ses bugs potentiels,
ses « dead code » (variable non utilisée,paramètre non utilisé,etc.),ses parties de code
non optimales,ses expressions trop complexes,etc.cpd est l’outil qui permet de détecter
les morceaux de code dupliqué.Il fait partie de l’outil pmd.
Analyse de codes Etude de la nouvelle infrastructure  37
Findbugs
Findbugs permet de détecter les bugs potentiels d’un projet.Pour ce faire,il se base
sur des « bug patterns ».Findbugs utilise une analyse statique pour détecter les bugs dans
le bytecode.Cela signifie qu’il n’est pas nécessaire d’exécuter le programme pour détecter
ces bugs.
JDepend
JDepend permet d’analyser le code pour en calculer des métriques sur la qualité
du design de chaque package du projet.Ces métriques se rapportent à l’extensibilité,la
réutilisabilité et la maintenabilité du code.
Conclusion sur les outils d’analyse de codes
L’ensemble des outils cités précédemment n’ont pas les mêmes objectifs.Choisir l’un
ou l’autre ne serait pas la bonne manière de procéder.Ces outils sont complémentaires
et rien ne nous empêche de les utiliser tous en même temps.Toutefois,cela prendrait un
temps considérable d’analyser chaque rapport un à un.Pour résoudre ce problème,des
applications comme Maven Dashboard Report,Sonar,...ont été développées.
3.5.2 Maven Dashboard Report
A la section 3.1.3.3,le plug-in dashboard destiné à Maven site a été brièvement
abordé.La figure 3.3 rappelle l’architecture de ce plugin.
Lorsqu’un projet se compose de plusieurs modules,ceux-ci possèdent leur propre site
et donc,leur propre rapport d’analyse.Il n’est donc pas possible,dans ce cas,d’avoir un
rapport qui reprend l’ensemble du projet et par conséquent d’avoir une analyse ensembliste.
Ce plug-in permet d’unifier dans un et un seul rapport l’ensemble de tous les rapports
générés par tous les plug-ins installés.De plus,ce plugin offre la possibilité d’historiser les
statistiques des différents outils.
Toutefois,ce plug-in n’a pas l’objectif de regrouper l’ensemble des analyses de plusieurs
projets.Ce plug-in sera donc utile dans le cas où l’on souhaite surveiller la qualité d’un
seul projet à la fois.
3.5.3 Sonar
Sonar est un outil libre développé initialement par la société Hortis.Depuis novembre
2008,c’est la société suisse SonarSource qui se charge de son développement.Cet outil
fait place à une large communauté,ce qui lui permet d’être fortement supporté.Ce logiciel
permet d’une part d’effectuer ses analyses basée sur de nombreux outils (notamment ceux
cités précédemment) sur un projet,mais également sur plusieurs projets.
D’un point de vue architecturale,Sonar se décompose en trois couches principales qui
Analyse de codes Etude de la nouvelle infrastructure  38
rappellent le modèle mvc:
 Plug-in Maven pour Sonar (Controller)
 Base de données qui stocke et historise les analyses (Model)
 Le serveur Web qui agrège les résultats et les affiche (View)
Le schéma à la Figure??illustre cette architecture.
Figure 3.11 – Architecture de Sonar
Les principales fonctionalitées de base sont listées ici et décrite??REFERENCEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEe.
 Dashboard des différents projets;
 Détection rapide du code à risque;
 Mesure quantitatives:nombre de classes,de commentaires,de code dupliqué,etc;
 Mesure qualitatives:taux de réussite des tests unitaires,complexité du code,etc;
 Historiques des analyses;
 Gestion de profils pour les règles de codage;
 Visualisation du code source avec une mise en évidence sur les violations des règles;
 Identification des points faibles d’un projet;
 Support des plugins:autres outils d’analyse,intégration avec d’autres outils,etc.
3.5.4 Conclusion sur le choix de l’outil d’analyse de codes
Teamcity possède une très bonne intégration avec Intellij Idea.Etant donné que
le choix de l’outil d’intégration continue à été porté sur Hudson,les règles d’inspections
de l’ide ne peuvent pas être directement utilisés.Cette solution est donc naturellement
éliminée bien qu’elle sera toujours utilisée pendant le développement.
Maven Dashboard souffre de quelques désavantages.Le problème majeur est cer-
tainement que les analyses sont ciblées par projet.Cela nous empêche donc de comparer
l’ensemble des projets entre-eux.
Sonar est certainement l’outil le plus complet du moment,bien plus que Maven Da-
shboard Plugin.Il dispose d’une interface Web conviviale et clair.De plus,l’application
est extensible au moyen de nombreux plug-ins.Certains d’entre-eux en vaut largement le
détour.Une description de ceux-ci est disponible??REFERENCEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE.
De plus,l’outil ne s’arrête pas à l’analyse d’un projet mais permet de faire des relations
Analyse de codes Etude de la nouvelle infrastructure  39
entre-eux.Cela permet notamment de voir le projet le plus à risque.
Le choix est donc sans surprise,j’utiliserai à présent Sonar en tant qu’outil d’analyse
de code.L’infrastructure se présente donc pour l’instant comme le montre la Figure 3.12.
Figure 3.12 – Infrastructure actuelle 3
Chapitre
4
Mise en place de l’infrastructure
Avant de procéder à l’installation des outils choisis,il faut mettre en place un envi-
ronnement de test afin d’éviter d’éventuels problèmes.Une fois l’infrastructure installée et
opérationnelle,il faudra penser également où seront installés définitivement les outils.
De plus,ce chapitre comporte une section « généralité » permettant d’expliquer le
fonctionnement de diverses choses.
4.1 Préliminaires
4.1.1 Standard LDAP
Historiquement,le protocole dap est créé pour permettre l’accès aux annuaires basé
sur la norme x.500.Cette dernière est définie par UIT-T en 1988.dap est basé sur le
modèle osi.ldap est alors créé en 1993 afin de se baser sur le modèle tcp/ip,nécessaire
pour accéder à Internet.
Structure d’un annuaire LDAP
Les données d’un annuaire ldap suivent une structure hiérarchique.Cette structure est
le dit.Chaque noeud de l’arbre représente une entrée dans l’annuaire.Le dit de Manex
est représenté à la Figure 4.1.
Chaque entrée dispose d’un identifiant unique appelé dn.Mon dn est affiché au listing
4.1.
1 uid=sandro.munda,ou=People,dc=manex,dc=biz
Listing 4.1 – Exemple d’un DN
Une entrée représente un objet concret (une personne,un serveur,une imprimante,
etc.) ou un objet abstrait (une zone géographique,une catégorie de personne,etc.).Les
abréviations dc,cn,uid...sont décrits dans le tableau 4.1.
40
Préliminaires Mise en place de l’infrastructure  41
Figure 4.1 – Annuaire LDAP de Manex
Table 4.1 – Explication des termes LDAP
Abréviation
Signification
dc Domain Component
ou
Organization Unit
cn Common Name
uid
User IDentification
4.1.2 Cron
Une expression cron est issu du monde unix.Un cron permet d’effectuer une tâche à
interval régulier.Il possède sa propre syntaxe,expliquée brièvement ici
1
Chaque ligne contient cinq champs séparés par un espace ou une tabulation.
Figure 4.2 – test
Afin de spécifier plusieurs valeurs pour un champ,les opérateurs suivants sont dispo-
nibles:
 «  » indique toutes les valeurs valides;
 « M N » indique un intervale compris entre M et N,par exemple « 1 5 »;
 « MN=X ou « =X indique un saut de X valeur dans l’intervale,par exemple =15
dans le champ minute signifie 0;15;30;45;
1.La syntaxe de cron est parfois adaptée selon les logiciels.Je présente ici la plus courante.
Installation de l’infrastructure de test Mise en place de l’infrastructure  42
 « A;B;C;:::;Z » indique plusieurs valeurs,par exemple « 0;30 ».
4.2 Installation de l’infrastructure de test
4.2.1 VMWare ESXi Server
La phase de test débutera par l’installation d’une machine de test.Pour ce faire,Ma-
nex a mis à ma disposition un serveur:mx1srv4.J’ai donc commencé par installer un
nouveau système d’exploitation dessus.Le choix s’est porté sur VMWare ESXi Server
permettant de faire de la virtualisation.Ce système hôte basé sur le noyau Linux est
en fait réduit et optimisé afin d’être le plus performant possible.La Figure 4.3 illustre
l’architecture d’un serveur basé sur VMWare ESXi.
Figure 4.3 – Architecture VMWare ESXi Server
La différence fondamentale avec une autre version de VMWare est qu’il ne s’exécute
pas au-dessus d’un système d’exploitation installé au préalable puisqu’il possède le sien.
Cela permet d’obtenir un gain important de performance.
4.2.2 CentOS 5
CentOS est un système d’exploitation basé sur le noyau monolithique Linux.Plus
particulièrement,ce système est en fait un clone 100 % compatible avec le système Red
Hat.La grande différence entre les deux est que Red Hat offre un support commercial.
CentOS se base lui sur un support communautaire.
Installation de CentOS 5 (x86)
L’installation se présente sous forme de quatre cd-rom.Seul le premier nous intéresse,
car les trois autres sont constitués de paquets divers de la distribution.
La configuration du réseau se fait manuellement.Une adresse ip publique est attribuée
à la machine virtuelle.Le masque de sous-réseau est « 255.255.255.224 » (le serveur fait
partie de la dmz).Le serveur dns se trouve sur « 212.166.60.228 ».
Tous les serveurs de Manex suivent le même partitionnement.Le Tableau 4.2 montre
le schéma de ce partitionnement.
Installation de l’infrastructure de test Mise en place de l’infrastructure  43
Table 4.2 – Partitionnement des serveurs Manex
Périphérique
Point de montage
Système de fichier
Description
/dev/sda1/boot ext3 contient les fichiers né-
cessaires au boot
/dev/sda2
/
ext3
racine du système de fi-
chier
/dev/sda3 n/a swap partition swap
/dev/sda5
/var
ext3
partition contenant les
fichiers qui évoluent
dans le temps (qui sont
susceptibles de grandir)
Les packages installés sur le serveur sont ceux repris dans la catégorie « Base ».Cela
permet d’avoir une installation de CentOS la plus minimaliste possible.
L’authentification des utilisateurs sur le serveur se fait par l’intermédiaire d’un serveur
ldap.Lors du premier démarrage,une application console s’ouvre afin de configurer le
serveur.Cette application peut être appelée ultérieurement avec la commande setup.
Setup propose notamment la configuration de l’authentification par ldap.L’adresse
est ldaps://ldap.manex.biz sur le port 636.Le dn base est:« dc=manex,dc=biz ».
4.2.3 Installation des applications webs
Artifactory,Hudson et Sonar sont toutes des applications j2ee déployable no-
tamment sur Tomcat.Toutes sont disponibles sous forme de war.Chaque application
sera installée dans le dossier «/var/www/manex.biz » du serveur.Ce chemin est choisi par
convention.Toute application qui est susceptible de contenir des fichiers qui sont réguliè-
rement modifiés est placé dans/var.Il faut configurer Tomcat pour qu’il se charge du
déploiement de chaque application.Pour ce faire,il faut configurer le fichier « server.xml »
situé dans le répertoire de configuration de Tomcat.Dans mon cas,il se trouve dans
«/usr/share/tomcat5/conf ».
L’installation s’est faite au départ sur le serveur mx1srv7.Cependant,l’ensemble des
applications de l’infrastructure actuelle se trouve sur mx1srv6.On y retrouve notamment
Jira,Teamcity,Subversion,etc.La machine est assez puissante pour contenir les trois
nouvelles applications.L’ensemble de l’infrastructure de développement chez Manex sera
donc centralisée sur un seul serveur et mieux encore,sur un conteneur.
Note
Les logiciels d’intégration continue peuvent être gourmand en ressources dû à leurs
builds.Des précautions sont donc à prendre afin de ne pas saturer la machine.Plus loin
dans ce document sera expliqué comment rencontrer ce problème.
Installation de l’infrastructure de test Mise en place de l’infrastructure  44
Configure du nomde domaine
Chaque application est accessible via l’url « nom_de_l_application.manex.biz »
où nom_de_l_application représente bien entendu le nom de l’application.Pour ce
faire,il faut configurer le nom de domaine.Le serveur dns se trouve sur mxisrv1.
ACOMPLETERRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
Configuration de Tomcat
Comme déjà dit,la configuration se fait principalement dans le fichier « server.xml ».
La configuration des trois applications est fort semblable.Le cas d’Artifactory est pris
comme exemple.
L’élément Host représente un « vhost » qui permet d’accéder à l’application déployée