Chapitre 4 : Etude comparative

Ce chapitre prsente ltude comparative mene sur lensemble des outils

composants une plateforme dintgration continue, pour le choix des outils
mettre en place.

La plateforme dintgration continue prendra en charge tous les projets dEAI, Elle devrait donc
permettre :

Une gestion Uniforme de projet de dveloppement logiciel

La plateforme renseigne sur ltat davancement du projet logiciel, permet de donner des mtriques de
code chaque phase de dveloppement, depuis le codage la compilation et lexcution de tests.

Une gestion Optimise des quipes de dveloppement

La plateforme permet de pousser la coordination entre les quipes de dveloppement pour assurer un
bon suivi du projet logiciel. Elle reoit les modifications de la part des quipes de dveloppement et se
charge de les intgrer dans le projet logiciel, ce qui permet de garder une bonne traabilit rgulire
communique, aux acteurs du projet.

Une gestion de la qualit des projets logiciels

La plateforme fournit des outils de mtriques de qualit de code grce aux outils de contrle et de
suivi dindicateurs de qualit logiciel (taux de couverture de code par les tests, respect des rgles de
codage et de nommage).

1. COMPOSITION DUNE PLATEFORME DINTEGRATION CONTINUE

Une plateforme dintgration continue doit comporter obligatoirement quelques lments essentiels pour
son fonctionnement savoir :

1. Un gestionnaire dintgration continue

Cest le serveur dintgration continue qui va grer la plateforme et qui va communiquer avec les
autres composants .Cest le cur de la plateforme.

2. Un gestionnaire SCM (Source Control Manager) ou gestionnaire de version de projet

Cet outil permettra de donner la main aux dveloppeurs pour quils puissent partager leur travail avec
les autres membres de lquipe, ainsi de grer les versions du codes source avec leur modifications, et
de revenir une version antrieure an cas derreur .Il sert galement grer les diffrentes
demandes de modification en mme temps ,ce qui permet dviter les conflits de versions .

3. Un outil de Build pour grer lapplication

Loutil de construction dapplication (de Build) vient pour gnrer automatiquement des projets
logiciels destins tre testes ou dploys par la suite.

4. Un outil de test

Cet outil de test vient pour vrifier la fiabilit du package gnre par loutil de construction ou de
Build .Il teste le code et gnr des rapports qui seront visibles partir de linterface du serveur
dintgration continue.

-6-
5. Un Gestionnaire de dpendances

Cet outil permet de grer au mieux ses dpts et ses dpendances. Il permet de disposer de ses
propres dpts de dpendances pour grer plus aisment les diffrentes versions de librairies que
vous aurez pu crer au sein de votre projet. Permet dans un deuxime temps de simplifier la
maintenance du code et surtout du processus de compilation.

2. COMPARATIF DES SERVEURS DINTEGRATION CONTINUE

Dans cette partie nous allons comparer diffrents serveurs dintgration continue notamment :

HUDSON.
CRUISE CONTROL.
TEAMCITY.
Quick Build.
Continuum.
JENKINS.

2.1 F AMILLES DE CRITERES

Pour avoir une tude significative, je me suis bas sur diffrents critres dvaluation qui seront
catgoriss en 9 familles :

Familles Dfinition

Fonctionnalits Qui nous permettra de not loutil par ses

intrinsques fonctions internes, propres et qui sont
indispensable.

Accessibilit Les outils seront nots sur leur IHM et leur

accessibilit via WEB ou Application, et la
possibilit de grer simultanment plusieurs
accs.

Modularit Cette famille de critres nous aidera mieux

nots les outils sur la faon avec laquelle ils
configurent les BUILDS, et les POST-BUILD.

Scurit On prcisera lexistence dune gestion des

habilitations pour chaque outil, ainsi que
laccs travers une authentification LDAP.

L'ergonomie Grace cette famille nous allons savoir si

loutil propose une modification de la charte
graphique.

Le reporting Cette famille nous donnera une ide sur la

faon dont les outils gnrent les rapports,
Sils gnrent la JAVADOC ? Sils proposent
du reporting spcifiques ?

-7-
 Les extensions Dans cette famille qui est dailleurs la plus
importante, on notera loutil sur ses limites
dintgration, tel que son intgration avec
dautres outils (outils de qualimtrie, outils
de gestion de dpts, outils de gestion de
versions), ainsi que la richesse de ses
plugins.

Organisation On traitera ici, la simplicit dorganisation et

dadministration de chaque outil. Par ailleurs
on vrifiera la bonne documentation de
loutil, de plus, lampleur de sa
communaut.

Installation et Sur cette famille on notera loutil sur son

cots mcanisme dploiement, et son cot
dachat.

TABLEAU 1 : FAMILLES DE CRITERES POUR L ' ETUDE DES SERVEURS I C

2.2 S YSTEME DE NOTATION

Le systme de notation que nous allons utiliser est constitu de 3 notes :

1. Le poids, de chaque critre, qui modlise limportance de ce dernier par rapport aux exigences
dEURAFRIC. Et qui est attribu comme suit :
1=Faible ; 3=Moyenne ; 5=Forte Importance

2. Une note, pour reprsenter ladquation de chaque outil par rapport un critre spcifique. Et
qui sera attribue comme suit :

Note (Faisabilit / Adquation) Risque

4 = Existe en natif / Trs forte Aucun

3 = Existe mais en passant par un plugin / Forte Faible

2 = Manque de dtails sur le besoin ou non dfini dans la documentation du

Moyen
produit / moyenne

1 = N'existe pas en natif mais extensible / Faible Elev

0 = Impossible faire / trs faible Bloquant

3. Une note qualifiante, qui est sous forme de formule et qui est attribue chaque outil, pour
la fin nous permettre dmerger, distinguer loutil le plus adquat aux exigences dEURAFRIC.

La formule de la note qualifiante est :

-8-
 N
NQx ( Poidsi * Notei )
i 1
La formule qui nous permettra de distinguer loutil gagnant de cette valuation est :

G MAX ( NQ ; NQ ; NQ ; NQ ; NQ )
H CC TC CT JK

Hudson =H
Cruise Control = CC
Team City = TC
Continuum = CT
Jenkins = JK

-9-
 2.3 M ATRICE D EVALUATION

SFE - Etude comparative des outils d'intgration continue 16-mai-12

Poids: 1=Faible, 3=Moyenne, 5=Forte Importance Rang 1 4 3 5 2

Total 413 344 365 300 408

CRUISE APACHE
Familles Critres Poids HUDSON TEAMCITY Jenkins
CONTROL Continuum

Fonctionnalits
1
intrinsques

1,01 Rcupration des sources de deux SCM principaux que sont CVS 5 4 4 4 4 4
et SVN
Configuration du lancement automatique de l'excution des
1,02 3 4 2 4 1 4
commandes standards Maven suite un commit

1,03 Gnration des archives de type JAR/EAR/WAR 3 4 4 4 4 4

1,04 Dploiement sur diffrents serveurs de tests 3 4 4 4 4 4

1,05 Notification des rsultats d'excution des tches 5 4 4 4 4 4

76 70 76 67 76
2 Accessibilit

2,01 Proposer une IHM accessible travers le Web en HTTP & HTTPS 5 4 4 4 2 4
L'IHM doit pouvoir tre accessible par plusieurs personnes
2,02 5 4 4 4 4 4
simultanment

40 40 40 30 40

- 23 -
 CRUISE APACHE
Familles Critres Poids HUDSON TEAMCITY Jenkins
CONTROL Continuum
3 Modularit

3,01 Faciliter la dfinition des diffrentes configurations de Build pour 1 4 4 4 4 4

un mme projet

3,02 Possibilit d'excuter des goals personnaliss 5 4 2 4 4 4

3,03 Permettre de lancer des actions Post-Build. 3 4 4 4 0 4

Les actions doivent pouvoir tre lances mme si le Build a

3,04 3 3 4 4 0 3
chou.

45 38 48 24 45
4 Scurit
4,01 Permettre de dfinir un ensemble de rles pour un projet donn. 3 4 4 4 4 4
4,02 Limiter la visibilit d'un projet certaines personnes seulement 5 4 4 4 4 4
Connexion des utilisateurs l'IHM de configuration du serveur
4,03 3 1 2 1 1 1
d'intgration via LDAP.

35 38 35 35 35
5 Ergonomie

5,01 Modifier la charte graphique de l'outil d'intgration 1 1 2 1 4 1

1 2 1 4 1
6 Reporting
Gnrer et afficher les rapports qualit directement dans l'outil
6,01 5 3 2 4 1 3
d'intgration ou via un outil tiers.

15 10 20 5 15

- 24 -
 CRUISE APACHE
Familles Critres Poids HUDSON TEAMCITY Jenkins
CONTROL Continuum
7 Extensions
Prise en compte dans l'outil d'intgration d'applications autres
7,01 1 3 2 4 4 3
que JAVA.
7,02 Intgration avec les IDE. 3 3 2 4 4 3
7,03 Intgration avec des outils de qualimtrie tel que SONAR 5 3 2 2 2 3
Intgration avec des outils de gestion de dpendance telle que
7,04 5 3 2 2 2 3
NEXUS.
7,05 Excution de commandes Maven 2 ou 3 en fonction du projet. 5 4 2 4 0 4
7,06 Compilation en Java 1.4, 5 ou 6 en fonction du projet. 5 4 4 2 4 4
7,07 Si l'outil dispose d'une multitude de plugins ? 5 4 2 2 2 4
102 68 76 66 102
8 Organisation
Simplicit d'organisation pour la cration des diffrentes tches
8,01 3 4 2 4 4 4
de Builds.
8,02 Administration de l'outil la plus rduite possible. 5 3 4 2 1 3

27 26 22 17 27
Installation et
9
cot
9,01 Dploiement dans un conteneur de servlets (Tomcat , JBoss) 3 4 4 4 4 4
9,02 Cot de licence d'acquisition non prohibitif 5 4 2 3 4 4
32 22 27 32 32
10 Evolution
10,01 Bonne documentation 5 4 3 2 2 4
10,02 Grand nombres d'utilisateurs 5 4 3 2 2 3
40 30 20 20 35
Total 413 344 365 300 408
TABLEAU 2 : MATRICE D ' EVALUATION DES SERVEURS IC

- 25 -
 2.4 S HORT L IST
Fonctionnalits
intrinsques
120

Evolution 100 Accessibilit

80

60

Installation et cots 40 Modularit

20 HUDSON
0 TEAMCITY
Jenkins

Organisation Scurit

Extensions Ergonomie

Reporting

F IGURE 1 : S HORT L IST DES SERVEURS IC

2.5 S OLUTION RETENUES

3 solutions mergentes de cette valuation HUDSON ; JENKINS ; TEAMCITY Nous retiendrons

donc HUDSON qui a le plus de point et qui est le plus adquat nos besoins. Cet outil semble le
plus adapt nos besoin vis--vis des fonctionnalits quil propose, de son excellente ergonomie et
de sa configuration simple et intuitive.

De plus, daprs de nombreux retour dexpriences, on a pu sapercevoir quune majorit dexperts

conseillent lutilisation de HUDSON ou de son jumeaux JENKINS.

3. COMPARATIF DES GESTIONNAIRES DE DEPENDANCES

Dans cette partie nous allons comparer 2 gestionnaires de dpendances notamment :

Archiva
Nexus

3.1 F AMILLE DE CRITERES

Pour avoir une tude significative, je me suis bas sur diffrents critres dvaluation qui seront
catgoriss en 6 familles :

Familles Dfinition

26
 Interface On notera chaque outil sur sa maniabilit
utilisateur et ce que son interface propose.

Reporting Cette famille nous donnera une ide sur la

faon dont les outils gnrent les rapports.

Support de Cette famille de critres nous aidera

Build savoir pour chaque outil, quels outils de
Build utilise-t-il.

Scurit On prcisera lexistence dune gestion des

habilitations pour chaque outil, ainsi que
laccs travers une authentification LDAP.

Intgration IC Grace cette famille nous allons savoir si

loutil sintgre des serveurs IC, tel que
(HUDSON, CONTINUUM, JENKINS, )

Base de De cette familles on distinguera loutil qui

donnes peut fonctionner sans BD, ou si lon peut
interroger sa base de donne.

TABLEAU 3 : FAMILLES DE CRITERES POUR L ' ETUDE DES GESTIONNAIRES DE DEPENDANCES

3.2 S YSTEME DE NOTATION

Le systme de notation que nous allons utiliser est constitu de 3 notes :

1. Le Rang : de chaque critre, qui modlise limportance de ce dernier par rapport aux
exigences dEAI. Et qui est attribu comme suit :
1=Faible ; 3=Moyenne ; 5=Forte Importance

2. Une note, pour reprsenter ladquation de chaque outil par rapport un critre
spcifique. Et qui sera attribue comme suit :

Note (Adquation)
5 = Forte
3 = Moyen
1 = Faible

4. Une note qualifiante, qui est sous forme de formule et qui est attribue chaque outil,
pour la fin nous permettre dmerger, distinguer loutil le plus adquat aux exigences
dEAI.

La formule de la note qualifiante est :

27
 N
NQx ( Rang * Notei )
i
i 1

La formule qui nous permettra de distinguer loutil gagnant de cette valuation est :

G MAX ( NQ ; NQ )
Archiva Nexus

3.3 M ATRICE D EVALUATION

SFE - Etude comparative des gestionnaires de

16/05/2012
dpendances
Poids: 1=Faible, 3=Moyenne, 5=Forte Importance Rang 2 1
Total 252 284

Familles Critres Poids ARCHIVA NEXUS

Interface
1
utilisateur
1,01 IU configurable 5 3 5
1,01 Suppression artefact 5 5 5
1,02 Copie d'artefact 3 3 1
1,03 Voir l'information d'un artefact 3 5 3
1,04 Dplacement d'artefact 3 1 3

2 Reporting
2,01 Rapport des problmes d'artefacts 5 5 5
2,02 Statistiques du dpt 5 5 1
2,03 Statistiques des artefacts 5 1 5
2,04 Journaux d'audit 5 5 5

Support de
3
Build
3,01 Maven 2 5 5 5
3,02 Maven 1 1 5 5
3,03 Maven 3 5 5 5

28
4 Scurit
4,01 Autorisation par dpt 5 5 5
Capable d'utiliser l'authentification
4,02 5 1 5
LDAP

5 Intgration IC
Prise en charge des serveurs
5,01 d'intgration telle que (HUDSON, 5 1 5
TeamCity, Continuum)

6 Base de donne
6,01 BD disponible pour interrogation 3 5 1
Total 252 284
TABLEAU 4 : MATRICE D ' EVALUATION DES GESTIONNAIRES DE DEPENDAN CES

3.4 S OLUTION RETENUE

Comme le dmontre la matrice dvaluation, loutil le plus adquat la gestion des dpendances
est Nexus.

4. COMPARATIF DES GESTIONNAIRES DE VERSIONS

Dans cette partie je vais comparer 2 SCM (Source Control Manager) notamment :

SVN
CVS

Tout dabord je rappel cest quoi un gestionnaire de version , Un logiciel de gestion de versions est
un logiciel de gestion de configuration permettant de stocker des informations pour une ou
plusieurs ressources informatiques permettant de rcuprer toutes les versions intermdiaires des
ressources, ainsi que les diffrences entre les versions. Pour la gestion de versions, nous avons
utilis jusqu' prsent deux logiciels qui ont fait leurs preuves : CVS et SVN. Nous porterons
notre description sur SVN.

4.1 E VALUATION
Subversion (en abrg SVN) est un systme de gestion de versions, distribu sous licence Apache
et BSD. Il a t conu pour remplacer CVS. Ses auteurs s'appuient volontairement sur les mmes
concepts (notamment sur le principe du dpt centralis et unique) et considrent que le modle
de CVS est le bon, et que seule son implmentation est en cause.

Subversion a donc t crit afin de combler certains manques de CVS. Voici les principaux apports
:

29
 Les commits, ou publications des modifications sont atomiques. Un serveur Subversion
utilise de faon sous-jacente une base de donnes capable de grer les transactions
atomiques (le plus souvent Berkeley DB) ;
Subversion permet le renommage et le dplacement de fichiers ou de rpertoires sans en
perdre l'historique ;
Les mtadonnes sont versionnes : on peut attacher des proprits, comme les
permissions, un fichier, par exemple.

Du point de vue du simple utilisateur, les principaux changements lors du passage Subversion,
sont :

Les numros de rvision sont dsormais globaux (pour l'ensemble du dpt) et non plus
par fichier : chaque patch a un numro de rvision unique, quels que soient les fichiers
touchs. Il devient simple de se souvenir d'une version particulire d'un projet, en ne
retenant qu'un seul numro ;
svn rename (ou svn move) permet de renommer (ou dplacer) un fichier ;
Les rpertoires et mtadonnes sont versionns.
Une des particularits de Subversion est qu'il ne fait aucune distinction entre un label, une branche
et un rpertoire. C'est une simple convention de nommage pour ses utilisateurs. Il devient ainsi
trs facile de comparer un label et une branche ou autre croisement.

4.2 S OLUTION RETENUE

Cest donc sans surprise que nous choisissons SVN (Subversion). Notre choix fut simple tant
donn le gouffre technologique entre ces deux gestionnaires de versions. Et de plus cest le
gestionnaire utilis par EAI.

5. COMPARATIF DES ENVIRONNEMENT DE DEVELOPPEMENT INTEGRE

(IDE)
Jai ralis une prslection des IDE afin de ne pas se disperser avec un comparatif trop large. Les
environnements retenus sont donc NetBeans et Eclipse. Cela est principalement d au fait que ce
sont les IDE Java connus pour tre les plus performants et les plus largement utiliss.

5.1 C RITERES DE COMPARAISON

1. Fonctionnalits
Les deux outils cits prcdemment possdent les fonctionnalits et besoins dsirs. En effet,
ils grent :

La compilation et le dploiement dapplications web ;

Linterfaage avec un gestionnaire de versions ;
Un dbogueur permettant de dtecter des bogues dans lapplication (il peut aussi servir
tester cette dernire).

30
 2. Connaissance
Ce critre savre dterminant dans le choix de lIDE qui sera utilis. Eclipse est
lenvironnement de dveloppement java prconis par nos enseignants et sur lequel nous
avons t form. Certaines personnes de lquipe possdent, nanmoins, une forte
exprience sur NetBeans du fait de leurs travaux en entreprise.

Le fait que lIDE Eclipse soit connu par la totalit de lquipe, linstar de son concurrent
NetBeans, est un avantage indniable en ce qui concerne le choix de lenvironnement qui sera
utilis.

3. Ergonomie
Pour ce critre dergonomie, nous recherchons une application qui puisse sinstaller
rapidement et tre facile prendre en main. Mais il faut aussi que celui-ci dispose dune
interface agrable et permettant de pouvoir rapidement effectuer toutes les actions ncessaire
rapidement. NetBeans sort ici vainqueur dans le sens o il dispose dune interface plus
intuitive et dun rel programme dinstallation. Il propose toutes les fonctionnalits en one-
clic ce qui permet de pouvoir raliser toutes les actions, dont lquipe a besoin, trs
rapidement.

5.2 S OLUTION RETENUE

Aprs ralisation de ce workbench :

Gratuit
10
5
NetBeans
Connaissance 0 Fonctionnalits
Eclipse

Ergonomie

F IGURE 2: W ORKBENCH DES ENVIRON NEMENTS DE DEVELOPPEMENT

LIDE choisi est donc la plateforme Eclipse.

31
 6. RAPPEL DES SOLUTIONS RETENUES
On a vu les solutions retenues pour certain composants de la plate-forme tel que : (Gestionnaire
de version ; Serveur dintgration continue ; Gestionnaire de dpendances ; IDE). Il reste 2 outils,
et qui sont (loutil danalyse de code et de qualimtrie ; loutil de Build, loutil de test), pour ces 2
derniers il y avait un choix direct suite des retours dexpriences de la part dune majorit de
dveloppeur et de chef de projet, quils soient interne ou externe EAI.

Ci-dessous un rappel sur les solutions qui ont taient retenues :

Composant Solution retenue

Gestionnaire de versions SVN (Subversion)

Outil de qualimtrie Sonar

Serveur dintgration continue HUDSON

Gestionnaire de dpendances NEXUS

Outil de Build Maven

Outil de test Junit

IDE Eclipse

7. CONCLUSION
Dans ce chapitre jai prsent ltude qui a tait faites pour le choix des
solutions mettre en place pour le fonctionnement adquat de la plate-
forme, je dcris pour chaque composant les familles de critres sur lesquels
les outils ont tait valu.

32
33