Mémoire DUT 2013 - Ibrahima KANE - 2SI

REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE INFORMATIQUE
Centre de Dakar
MEMOIRE DE FIN DE CYCLE
Pour lobtention du :
DIPLOME UNIVERSITAIRE DE TECHNOLOGIE EN INFORMATIQUE
(DUTI)
Thme :
Thme :
Mise en place dune plateforme dintgration continue 2SI

Lieu de stage :
Priode de stage :
15 mai 2013 - 30 juillet 2013
Prsent par : Encadr par : Matre de stage :

Ibrahima KANE M. FARSSI M. Maguette Path GUEYE
Anne universitaire : 2012 2013

REPUBLIQUE DU SENEGAL
***** * * ********
UNIVERSITE CHEIKH ANTA DIOP DE DAKAR
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT GENIE INFORMATIQUE
Centre de Dakar
MEMOIRE DE FIN DE CYCLE
Pour lobtention du :
DIPLOME UNIVERSITAIRE DE TECHNOLOGIE EN INFORMATIQUE
(DUTI)
Thme :
Thme :
Mise en place dune plateforme dintgration continue 2SI

Lieu de stage :
Priode de stage :
15 mai 2013 - 30 juillet 2013
Prsent par : Encadr par : Matre de stage :

Ibrahima KANE M. FARSSI M. Maguette Path GUEYE
Anne universitaire : 2012 2013

ESP 2013
Ibrahima KANE - Mmoire de Fin de Cycle DUT -- Mise en place dune plateforme dintgration continue 2SI 3
DEDICACES
A la mmoire de ma trs chre mre,
La dfunte et la regrette Fatou Thiam DIOP
ESP 2013
REMERCIEMENTS
Avant toute chose je remercie Dieu pour la grce quil ma faite en renouvelant son souffle de vie
en moi jusqu ce jour.
Jadresse mes plus sincres remerciements :
Mes parents pour lamour quils mont port ;
Mes frres et surs pour leurs soins bienveillants,
Mon "neveu et grand-frre", Mama Talla Faye ;
Madame DIONE Directrice Gnral de 2SI et Monsieur Mamadou FAYE Directeur
Technique qui mont accord la chance deffectuer mon stage de fin de cycle au sein de 2SI;
Monsieur Maguette Path GUEYE, mon matre de stage pour sa disponibilit, ses
conseils et sa sympathie, jai beaucoup appris vos cts ;
Les dveloppeurs de 2SI pour leurs conseils et leur soutient ;
Lensemble du personnel de 2SI pour toute lattention quils mont accord, mention
spciale la table Nekk , une famille qui ma accueille et trs vite intgr (Diodio, Matar,
Bineta, Pape Dine, Sonko, Coatch )
Monsieur FARSSI, Chef du dpartement Gnie Informatique et galement mon
professeur encadreur ;
Monsieur Mamour Amadou Ba, chercheur au laboratoire informatique de lESP,
pour les correctifs quil a apport mon mmoire
Monsieur Ibra DIOUM responsable pdagogique du cycle DUT informatique pour sa
disponibilit et ses conseils ;
Monsieur Ahmath Bamba MBACKE professeur lEcole Suprieure Polytechnique
pour ses conseils et orientations;
Mes camarades de promotions;
Toutes les personnes qui de prs ou de loin ont contribu la ralisation de ce travail.
ESP 2013
Table des matires
Avant-propos ........................................................................................................................ 11
Introduction .......................................................................................................................... 12
Chapitre I : PRESENTATION GENERALE
I.Prsentation de lESP ........................................................................................................ 14
I.1. Historique ......................................................................................................... 14
I.2 Organisation ........................................................................................................ 14
I.2.1 Le dpartement Gnie Informatique.................................................. 14
I.2.2 Les autres dpartements ...................................................................... 15
I.3 Objectif et missions ............................................................................................. 15
II. Prsentation de la structure daccueil ........................................................................... 16
II.1 Situation et coordonns ................................................................................... 16
II.2 Description ....................................................................................................... 17
II.3 Organisation ..................................................................................................... 17
II.3.1 La Direction tudes et Ingnierie Logicielle ................................... 17
II.3.2 La Direction Automation .................................................................. 16
II.3.3 La Direction Services Valeur Ajoute .......................................... 18
II.3.4 La Direction Web et Multimdia ..................................................... 18
II.3.5 Le Centre de Formation Professionnelle et de Perfectionnement . 18
III. Prsentation du sujet .................................................................................................... 19
Chapitre II : ETUDE DE LEXISTANT
I. Cycle de dveloppement 2SI ..................................................................................... 22

II. Prsentation des outils et technologies existants ....................................................... 23
II.1 Java Enterprise Edition ................................................................................... 23
II.2 La technologie des EJB .................................................................................... 23
II.3 Le Framework ZK ........................................................................................... 24
II.4 Le Framework Hibernate ................................................................................ 24
ESP 2013
II.5 JBoss Application Server ................................................................................. 24

II.6 Apache Subversion ........................................................................................... 25
III. Critiques de lexistant .................................................................................................. 25
IV. Proposition dune solution : lintgration continue (IC) .......................................... 26
IV.1 Lintgration en trois en tapes ..................................................................... 29
IV.2 Le rle des dveloppeurs dans lIntgration Continue ................................ 29
IV.2.1. Lintgration locale ....................................................................... 29
IV.2.2. Les bonnes pratiques du dveloppeur ......................................... 30
IV.2.3. Les diffrents types de build ........................................................ 33
IV.2.3.1 Le build priv ..................................................................... 33
IV.2.3.2 Le build dintgration de jour .......................................... 33
IV.2.3.3 Le build dintgration de nuit ......................................... 34
V. Proposition dune architecture de la plateforme .................................................. 34
Chapitre III: CHOIX ET PRESENTATION DES OUTILS ET TECHNOLOGIES UTILISES
I. Le gestionnaire de version : Subversion ..................................................................... 36
II. Loutil de build : Apache Maven ................................................................................ 37
II.1 Project Object Model (POM) .......................................................................... 38
II.2 Convention plutt que configuration ............................................................. 38
II.3 Cration dun archetype pour les projets JEE 2SI ................................... 39
II.3 Cycle de vie dun projet maven ...................................................................... 40
III. Le gestionnaire de dpt de rfrentiels Maven : Nexus ..................................... 42
IV. Le serveur dintgration continue : Jenkins ......................................................... 43
V. Loutil de qualimtrie : Sonar ................................................................................ 45
VI. Le Framework de test unitaire : JUnit .................................................................. 47
Conclusion .......................................................................................................................... 48
Bibliographie / Webographie ............................................................................................ 49
Glossaire ............................................................................................................................. 50
ESP 2013
Table des figures
Figure I.1 : Position de 2SI sur Google Maps ........................................................................ 16

Figure I.2 : Organigramme de 2SI ......................................................................................... 17
Figure I.3 : schma illustrant un software factory ................................................................ 19
Figure II.1 : Schma du cycle de dveloppement 2SI ........................................................ 22
Figure II.2 : Courbe dvolution des bogues dans le processus de dveloppement ............ 26
Figure II.3 : Schma de comparaisons Avant et Aprs la mise en place de lIC ............... 28
Figure II.4: Lintgration continue en un schma ................................................................ 32
Figure II.5 : Diagramme illustrant les diffrents types de build ......................................... 33
Figure II.6: Les diffrents composants de la plateforme ...................................................... 34
Figure III.1 : Cycle de vie dun projet maven ....................................................................... 41
Figure III.2: Principe de fonctionnement de Nexus .............................................................. 43
ESP 2013
MISE EN PLACE DUNE PLATEFORME DE GESTION ET
DAUTOMATISATION DE LA PRODUCTION DE PROJETS LOGICIELS :
INTEGRATION CONTINUE, AUTOMATISATION DES TESTS, ET MESURE
DE LA QUALITE DU CODE SOURCE.
ESP 2013
Avant-propos
Lcole suprieure polytechnique (E.S.P) forme en deux annes dtudes des techniciens
suprieurs, et en trois ans des ingnieurs dans plusieurs spcialits.
Dans le cadre de leur formation les tudiants de fin de chaque cycle sont tenus deffectuer
un stage pratique au sein dune entreprise ou dun service informatique.
Ce stage est effectu dans le but :
De fournir aux tudiants la possibilit de mettre en uvre les connaissances thoriques acquises tout
au long de leur formation.
Dinitier les futurs techniciens suprieurs aux ralits du milieu professionnel et de leur
permettre de se faire la main sur des projets denvergures. Au terme de ce stage un mmoire doit
tre rdig sur un problme qui a t tudi durant ce stage.
Pendant la dure du stage, il nous a t confi la mise en place dune plateforme dintgration
continue cest--dire qui permettrait de vrifier chaque modification de code source que le rsultat
des modifications ne produit pas de rgression dans l'application dveloppe.
ESP 2013
INTRODUCTION
Quand on dveloppe un logiciel, on peut facilement faire des modifications sans se rendre
compte quelles introduisent des bugs dans certains cas particuliers. Cest ce quon appelle des bugs
de rgression, en ce sens quon introduit de nouveaux bugs la suite dune volution fonctionnelle.
Comme il nest pas humainement possible de tester systmatiquement tous les cas dutilisation
possible, ces bugs peuvent se retrouver dploys en production, avec tous les problmes que cela
comporte.
Une des notions importantes, quand on fait du dveloppement, est de savoir que plus un bug est
dtect tt, plus il sera facile corriger. Les gros soucis arrivent quand on fait du surdveloppement
par-dessus un bug de rgression ; il devient trs difficile de faire un retour en arrire sur le code
incrimin, car cela impliquerait de supprimer des fonctionnalits. Il faut alors corriger ce nouveau
code, en essayant de trouver une aiguille dans une botte de foin.
Dans le domaine de lingnierie logicielle, la seule matrise des comptences ne suffit pas,
elle seule, pour garantir la russite dun projet. En plus dune bonne mthodologie de gestion, la
ralisation doit sappuyer sur un cadre concret o des outils sont mis disposition des dveloppeurs.
Bien que ces outils ne participent pas directement la valeur ajoute du projet, ils garantissent un
environnement de dveloppement stable et born qui permet de maximiser la scurit du projet.
Cest pourquoi nous sommes convaincus quun tel environnement est au moins aussi
important que le dveloppement du projet lui-mme.
Ainsi, dans le cadre de notre stage au 2SI, nous avons mis en place toute linfrastructure ncessaire
pour concevoir une plateforme dintgration continue.
Celle-ci permettrait lentreprise de raliser des projets dans les meilleures conditions.
ESP 2013
CHAPITRE I :
PRESENTATION GENERALE
La prsentation gnrale permet davoir une ide globale du sujet, mais

aussi une prsentation de la structure dans laquelle nous avons ralis
ce travail.
ESP 2013
PRESENTATION GENERALE
CHAPITRE I
I. Prsentation de lESP
I.1. Historique
LEcole Suprieure Polytechnique de Dakar (ESP) est un tablissement public caractre

administratif dot de la personnalit juridique et de lautonomie financire. Lcole Suprieure
Polytechnique fait partie intgrante de luniversit Cheikh Anta DIOP de Dakar (UCAD).
Elle a t cre par la loi n 94-78 du 24 novembre 1994. A lorigine, lESP regroupait en son sein :
La division industrielle de lEcole Nationale Suprieure Universitaire de Technologie (ENSUT)
LEcole Polytechnique de This (EPT)
La section technique industrielle de lEcole Normale Suprieure dEnseignement Technique
et Professionnel (ENSETP)
A la suite de diverses rformes intervenues, notamment la revitalisation de lENSETP, la
cration de lUniversit de This et le rattachement de lInstitut Suprieure de Gestion
lESP, lEcole Suprieure Polytechnique est seulement compose prsentement de la division tertiaire
de lex ENSUT.
I.2. Organisation
Etablissement public vocation rgionale, sous la tutelle du Ministre de lEducation, lEcole

Suprieure Polytechnique est rattache lUniversit Cheikh Anta DIOP de Dakar.
Elle assure des formations dans six dpartements qui la composent. Ces formations se font en cours
du soir comme en cours du jour, aussi bien en formation initiale quen formation continue
pour le compte des entreprises, socits et particuliers. Ces six dpartements sont :
I.2.1 Le dpartement Gnie Informatique :
Ce dpartement forme des techniciens suprieurs, assistants ingnieurs, des ingnieurs en

informatique, tlinformatique et en tlcommunication. Les tudiants y mnent des activits
de recherche dans les domaines mentionns ci-dessous visant au perfectionnement
permanent, l'adaptation et la participation l'volution scientifique et technologique. On y
ESP 2013
procde des expertises dans le cadre de la formation l'intention des entreprises publiques et
prives.
I.2.2 Les autres dpartements
LESP comprend en plus du dpartement Gnie Informatique les dpartements suivants :
Le dpartement gnie Mcanique
Le dpartement Gnie Civil
Le dpartement Gnie Electrique
Le dpartement Gnie Chimique et Biologie Applique
Le dpartement Gestion
I.3. Objectifs et missions
LESP a pour objectif et missions de :

Former tant sur le plan thorique que pratique des :
Techniciens Suprieurs
Ingnieurs Technologues
Ingnieurs de Conception
Managers en Gestion dEntreprises
Docteurs
Dispenser un enseignement suprieur en vue de prparer aux fonctions d'encadrement
dans :
la Production
la Recherche Applique
les Services
Organiser des enseignements et des activits de recherche visant
au perfectionnement permanent
l'adaptation et la participation
l'volution scientifique et technologique
lvolution conomique et managriale
Procder des expertises l'intention des entreprises publiques et prives
Pour plus de dtails, on peut se rfrer au site officiel de lESP (www.esp.sn).

ESP 2013
II. Prsentation de la structure daccueil :
II.1. Situation et coordonns :
Sicap Amiti 3 Villa N4250
Rue 111, Alle Seydou Nourou Tall
Dakar, Sngal
BP 14179 - Dakar, Pytavin
SENEGAL
Tlphone : (221) 33 865 11 50
Tlcopie : (221) 33 864 51 84
Site web : www.ssi.sn
Google Maps
Figure I.1 : Position de 2SI sur Google Maps

ESP 2013
II.2. Description :
2SI (Stratgies et Solutions Informatiques) est une Socit de Services en Ingnierie Informatique
(SSII) spcialise dans lingnierie logicielle et les automatismes. Elle est, en Afrique de lOuest, lun
des prestataires majeurs de solutions et de services innovants dans le domaine des TIC destins aux
entreprises, aux administrations et aux organisations.
Cre en 2001 au Sngal, 2SI a ouvert une filiale au Mali depuis Janvier 2007 et compte des
rfrences en Gambie, en Guine Bissau, en Guine Conakry, et au Burkina Faso.
Mise en place par des ingnieurs polytechniciens, 2SI dispose aujourdhui une quipe dune trentaine
de personnes dont une vingtaine dingnieurs et de techniciens suprieurs.
En quelques annes, 2SI est devenue le partenaire privilgi de ses clients dans les mtiers de
lingnierie logicielle et des automatismes grce lexpertise reconnue de ses quipes et la qualit
des services offerts.
II.3. Organisation :
2SI est divise en quatre directions et compte aussi un centre de formation professionnelle.
La Direction Gnrale
Le Centre de Formation
La Direction tudes et La Direction Services La Direction Web et
La Direction Automation Professionnelle et de
Ingnierie Logicielle Valeur Ajoute Multimdia
Perfectionnement
Figure I.2 : Organigramme de 2SI
II.3.1 La Direction tudes et Ingnierie Logicielle
Spcialise dans ldition et l'intgration de solutions logicielles, la Direction tudes et

Ingnierie Logicielle intervient principalement dans la mise en place de solutions logicielles sur
mesure.
Grce son savoir-faire dans la mise en place de systmes bass sur les technologies web avec
ESP 2013
des choix technologiques forts (J2EE, PHP, Oracle, RIA), 2SI est en mesure de conforter sa position
de SSII haut potentiel.
II.3.2 La Direction Automation
La Direction Automation est spcialise dans les domaines de la conception et la

ralisation de solutions pour la gestion de laccueil et lautomatisation des changes
entre le grand public et les entreprises, lintgration de solutions de scurit lectronique, la
tlphonie sur IP et le contrle commande.
II.3.3 La Direction Services Valeur Ajoute
La Direction des Services Valeur Ajoute propose des solutions qui rpondent aux exigences du
grand public (tlchargements de biens en ligne, services dinfos pratiques, divertissement etc.),
de professionnels (communication interne, promotion, publicit etc.), et qui correspondent une
ncessit pour les entreprises, dintgrer des technologies innovantes dans leurs systmes
dinformation ou logiciels dapplications (consultation de compte, message dalarme, gestion
relation clients, etc.). Ces services tournent principalement autour du mobile (SMS, MMS,
WAP, etc.)
II.3.4 La Direction Web et Multimdia
Aujourdhui, Internet est le mdia qui illustre le mieux la croissance technologique. Cest un outil de
communication et de marketing incontournable rpondant aux attentes dun march sans cesse
volutif et exigeant.
Cest ainsi que la Direction Web et Multimdia de 2SI propose des prestations internet adaptes
la cration de sites web, le dveloppement d'applications web spcifiques, des solutions multimdia
interactives grce aux Technologies appliques sur le Web (HTML, PHP, ASP, JSP, JAVA, XML,
Flash, AJAX, FLEX, JOOMLA).
II.3.5 Le Centre de Formation Professionnelle et de Perfectionnement
Le Centre de Formation Professionnelle et de Perfectionnement, CF2P est un centre ddi aux

entreprises, aux administrations publiques et aux organismes pour la formation et le renforcement
de la capacit de leur capital humain dans le domaine de linformatique, du management, de la
communication, des finances, etc.
ESP 2013
III. Prsentation du sujet
Une usine logicielle (Software Factory en anglais) est un ensemble doutils pr-configurs, de
frameworks, de conventions, de processus, de documentations et de modles de projets qui structurent
les dveloppeurs et leurs dveloppements.
Lobjectif est dautomatiser au maximum la production et la maintenance des applications afin
damliorer leur qualit et le "time to market" scub-foundation.org
Notre travail consiste renforcer lusine logicielle existant 2SI en mettant en place une plateforme
dintgration continue.
Figure I.3 : schma illustrant un software factory
La problmatique
L'intgration d'un projet est constitue de diffrentes tapes souvent laborieuses et consommatrices
de temps. Parmi ces tapes, nous retrouvons gnralement les phases de gnration de code, de
compilation, d'excution d'outils de qualit de code, d'excution d'outils de tests unitaires et
fonctionnels, des phases de validation et de vrification d'lments transverses comme les licences,
de dploiement, .
Cette phase d'intgration est d'autant plus critique si celle-ci est faite en fin de projet avant la livraison,
rvlant de nombreux problmes et mettant alors malheureusement la russite du projet en pril.
L'ensemble de ces problmes sont supprims travers la mise en place d'une plateforme dintgration
continue qui va consister mettre en place un ensemble d'outils afin d'automatiser le processus
ESP 2013
d'intgration. Celui-ci est excut chaque changement dans l'environnement d'infrastructure du
projet et produit un ensemble de rsultats que les membres de l'quipe de dveloppement peuvent
visualiser chaque instant.
Les Objectifs :
Les objectifs que nous nous fixons dans la mise en place de cette plateforme sont entre autres :
Dtection rapide d'une anomalie logicielle et diminution du cot tardif d'une correction
logicielle
Suivi de la qualit du code logiciel
Version dploye et disponible en continue
Automatisation de la livraison
Disposer de modles de projets pour chaque type dapplications (notion darchtype) avec,
chaque fois, une structure standardise (configuration, scripts dalimentations, scurit).
Avoir des tches automatises pour lensemble des processus du cycle de vie du projet
(compilation, packaging, test, livraison).
Gestion automatique des dpendances / librairies / versions.
Gestion des diffrents environnements et de leurs configurations (Test / Dveloppement / Pr
production / Production).
Une documentation complte qui permet nimporte quel dveloppeur de se mettre
rapidement au travail. Ceci afin de grer la croissance des quipes de dveloppement et le
turn-over.
En particulier notre mmoire devra servir dun premier guide pour les dveloppeurs leur
permettant dapprhender lintgration continue avant dapprofondir dans lutilisation des
diffrents outils.
ESP 2013
CHAPITRE II :
ETUDE DE LEXISTANT
Cette tude de lexistant nous permet de faire le bilan sur le

fonctionnement des outils dj existant dans lenvironnement de
dveloppement de 2SI, afin de pouvoir y apporter des amliorations.
ESP 2013
ETUDE DE LEXISTANT
CHAPITRE II
I. Cycle de dveloppement 2SI
Figure II.1 : Schma du cycle de dveloppement 2SI
De faon succincte ce schma reprsente le fonctionnement du cycle de dveloppement 2SI.

Manuellement trois projets sont initialiss au lancement dun nouveau projet : un projet EJB 3.0 et
un projet web avec le Framework ZK qui vont constituer les modules dun troisime projet EAR.
Pour grer la connexion avec la base de donnes centralise, on utilise le Framework Hibernate, et
un serveur dapplication JBOSS AS 5.1 pour excuter l'application.
Pour permettre laccs au code source toute lquipe un dpt SVN est initialis, partir duquel les
ESP 2013
dveloppeurs peuvent faire des mises jour.
II. Prsentation des outils et technologies existants
II.1. Java Enterprise Edition
Dans la plupart de ses projets, 2SI utilise la spcification JEE pour Java Enterprise Edition, ou Java
EE (anciennement J2EE), qui est une spcification pour la technique Java de Sun plus
particulirement destine aux applications dentreprise. Ces applications sont considres dans une
approche multi-niveaux. Dans ce but, toute implmentation de cette spcification contient un
ensemble dextensions au framework Java standard (JSE, Java Standard Edition) afin de faciliter
notamment la cration dapplications rparties.
II.2. La technologie des EJB
Pour grer la couche mtier de ses applications 2SI utilise la technologie des EJB (pour Enterprise
Java Bean) qui a t introduite en 1998 pour offrir aux programmeurs un outil qui facilite la
conception et le dploiement d'une couche mtier.
En 2006, la version EJB 3.0 a pour objectif de simplifier l'utilisation et le dploiement de cette
technologie en se basant sur quatre principes :
Les fichiers XML de dploiement sont remplacs par des annotations places directement
dans le code des EJB.
Pour assurer les interactions entre les EJB et le serveur d'application dans lequel ils sont
installs, le programmeur n'est plus oblig d'implmenter de nombreuses interfaces (au sens
java du terme).
Tous les paramtres de dploiement sont dots de valeurs par dfaut qui suffisent dans la
plupart des cas.
Les mouvements de donnes vers ou partir d'une base de donnes relationnelle vont tre
raliss par le biais de POJO (Plain Old Java Object).
ESP 2013
II.3. Le Framework ZK
Pour grer linterface graphique de ses applications 2SI utilise ZK (Zero Kode) qui est un framework
open source web 2.0, proposant une interaction utilisateur (UI) riche. ZK permet tout autant de dfinir
rapidement des interfaces graphiques via une syntaxe XML ou un diteur Wysiwyg que de manipuler
directement les objets en Java.
ZK est un moteur bas sur le principe de lAjax et sur un systme dvnements. Il ne gre que la
partie Vue du modle MVC, on peut donc lintgrer dans un framework (Hibernate, Struts, etc.).
II.4. Le Framework Hibernate
Hibernate est un framework open source grant la persistance des objets en base de donnes
relationnelle.
Hibernate apporte une solution aux problmes d'adaptation entre le paradigme objet et les SGBD en
remplaant les accs la base de donnes par des appels des mthodes objet de haut niveau.
Hibernate prsente aussi un langage de manipulation des objets mapps connus sous le nom HQL. Il
sagit de faire des select, Update et Delete avec des oprations de somme, comptage (count), de calcul
de moyenne, etc. HQL prsente aussi des limites telles que lutilisation des oprations dUnion.
Dans sa couche la plus proche de la base de donnes, Hibernate utilise JDBC (JDBC Template) pour
dialoguer avec la base de donnes.
II.5. JBoss Application Server
Pour le dploiement des applications dans les environnements de test les dveloppeurs de 2SI utilisent
le serveur dapplication JBoss AS qui est un serveur d'applications Java EE libre, entirement crit
en Java, publi sous licence GNU LGPL. tant crit en Java, JBoss Application Server peut tre
ESP 2013
utilis sur tout systme d'exploitation fournissant une machine virtuelle Java (JVM).
JBoss Application Server implmente entirement l'ensemble des services Java EE.
II.6. Apache Subversion
Pour avoir un dpt unique et centralis des codes sources des projets en cours de dveloppement les
dveloppeurs de 2SI utilisent Subversion (en abrg svn) qui est un logiciel de gestion de versions,
distribu sous licence Apache et BSD. La mise en place de cet dpt centralis permet tous les
membres de lquipe de dveloppement davoir une copie jour du projet et de mettre jour sa copie
modifi au niveau du serveur par un commit.
Subversion fonctionne sur le mode client-serveur, avec :
un Serveur informatique centralis et unique o se situent :
les fichiers constituant la rfrence (le 'dpt' ou 'rfrentiel', ou 'repository' en anglais)
un logiciel serveur Subversion tournant en 'tche de fond'
des postes clients sur lesquels se trouvent :
les fichiers recopis depuis le serveur, ventuellement modifis localement depuis,
et un logiciel client, sous forme d'excutable standalone (ex: SmartSVN) ou de plug-
in (ex:TortoiseSVN, Eclipse Subversive) permettant la synchronisation, manuelle
et/ou automatise, entre chaque client et le serveur de rfrence.
III. Critiques de lexistant
Le premier souci que nous relevons dans lactuelle usine logicielle de 2SI est le temps et leffort que
ncessite linitialisation dun nouveau projet et la gestion des librairies dpendants du projet. En effet
au dmarrage dun projet, le chef de projet cre trois types de projets, un projet EJB en rcuprant
quelques packages dans les projets prcdents ce qui ncessite n un grand travaille de renommage
pour garder une cohrence dans la configuration, un autre projet de type ZK en rcuprant au
dlments rutilisables dans les projets antrieures, et pour finir un troisime projet de type EAR qui
runit les deux prcdents. Il serait prfrable, puisquil ya certaines bibliothques, des fichiers de
configurations et certains modules qui reviennent dans tous les projets, quon les runisse pour en
faire un squelette de projet partir duquel nous gnrerons les nouveaux projets.
La gestion des dpendances est effectue de faon manuelle par le chef de projet, ce qui est fastidieuse
comme mthode et pas trs performante lorsque nous savons quil ya des outils qui permettent de
ESP 2013
grer automatique les dpendances dans le projet.
Les fichiers de configurations sont dpendants du poste de travail du dveloppeur, ce qui peut
entrainer que le code quil crit ou le module tourne sur son poste et pas sur celui des autres membres
de lquipe au moment de lintgration, sils nont pas les mmes configurations (versions diffrents
de librairies, chemins daccs diffrents, ). Ce qui fait perdre de temps et peut entrainer un retard
sur le dlai de livraison du produit si on ne parvient pas trouver lerreur temps.
Et aussi comme les tests unitaires ne sont pas effectus sur les codes crits par le dveloppeur la
scurit du projet est fortement menace parce que des bogues peuvent souvent tre dtects
tardivement.
Le constat indniable que nous retenons est, plus une erreur est dtecte tard et plus le cot de la
correction sera lev !
Voici un graphique qui rsume bien la situation.
Source :
Fabian Piau
http://fabianpiau.com/
Figure II.2 : Courbe dvolution des bogues dans le processus de dveloppement
IV. Proposition dune solution : lintgration continue (IC)
LIntgration Continue est une mthode agile1. Plus prcisment, elle fait partie des 12 mthodes
deXtreme Programming2. Elle se base sur les principes agiles suivants :
Fabriquer souvent (build) ;
Tester souvent (test) ;
Intgrer souvent (integrate).
1
Les mthodes Agiles sont des procdures de conception de logiciel qui se veulent plus pragmatiques que les mthodes
traditionnelles. En impliquant au maximum le demandeur (client), ces mthodes permettent une grande ractivit ses
demandes, et amliorent sa satisfaction. La notion de mthode agile a t officialise en 2001 par un document Manifeste
ESP 2013
Agile (Agile Manifesto) sign par 17 personnalits impliques dans l'volution du gnie logiciel, et gnralement auteurs
de leur propre mthode.
2
En informatique et plus particulirement en gnie logiciel, Extreme Programming (XP) est une mthode agile, plus
particulirement oriente sur l'aspect ralisation d'une application, sans pour autant ngliger l'aspect gestion de projet. XP
est adapt aux quipes rduites avec des besoins changeants. XP pousse l'extrme des principes simples.
Nous voulons parvenir avec la solution propose 3 :
Maintenir un dpt unique de code source versionn (avec SVN) ;
Automatiser les compilations (avec Apache Maven) ;
Rendre les compilations auto-testantes (Tests XUnit) ;
Inciter tous les dveloppeurs commiter4 tous les jours ;
Tout commit amne une compilation du tronc sur une machine d'intgration ;
Maintenir une construction de build courte ;
Tester dans un environnement de production clon ;
Rendre disponible facilement le dernier excutable ;
Faire voir tout le monde ce qui se passe ;
Automatiser le dploiement.
Lintgration continue industrialise :

La gnration des packages ;
Les tests unitaires ;
La qualimtrie ;
Le reporting.
Lobjectif ici est de vrifier, de faon automatique et chaque modification de code source, que le
rsultat des modifications ne produit pas de rgression de lapplication en cours de dveloppement.
ESP 2013
3
Extrait (traduit en franais) du site de M. Fowler http://www.martinfowler.com/articles/continuousIntegration.html
4
Version franise du verbe anglais commit qui correspond, dans le langage des base des donnes, une opration de
mise jour de la base avec le contenu de ces modifications actuellement dans la mmoire du calculateur.
Voici une srie de schmas qui comparent lavant IC et laprs IC sur un projet quelconque. La
phase dintgration nest plus une phase finale, mais est incorpore tout au long de la phase de
dveloppement.
Avant la mise en place de lintgration continue :
Aprs la mise en place de lintgration continue :
Source :
Fabian Piau
ESP 2013
Figure II.3 : Schma de comparaisons Avant et Aprs la mise en place de lIC
IV.1. Lintgration continue en trois tapes :
On pourrait rsumer lintgration continue aux trois tapes suivantes :

a) Les dveloppeurs publient leurs modifications de code sur le serveur SVN (commit).
Ils auront pris soin dcrire des tests sur leurs nouveaux codes et de lancer des builds privs (ou
locaux) sur leurs postes. Cest ltape la plus importante du processus.
b) Le serveur dintgration scrute les changements sur le SVN. A chaque fois quil
analyse un changement, il ralise un build dintgration. Cest une mthode dautomatisation on
stimulus.
Il est important de noter que le serveur dintgration continue utilise des scripts et des environnements
de build dj existant. Par exemple, dans notre cas Maven est utilis pour compiler et lier les
composants crits en Java, alors le serveur appellera simplement les commandes de mvn pour
initialiser la construction du build.
Nous avons parl dune automatisation on stimulus, mais il est possible davoir une construction
automatique de build rgulire, par exemple toutes les 30 minutes. Cette mthode dautomatisation
on the clock permet davoir une charge moins importante sur le serveur, mais peut se rvler moins
efficace, dans la rsolution des erreurs, quune construction de build chaque commit (notamment si
les dveloppeurs ont commit beaucoup de codes en lespace de ces 30 minutes).
c) A chaque fois quun build est ralis, un courriel de notification est envoy tous les
membres de lquipe. Ce courriel contient notamment le statut du dernier build. En cas dchec du
build, les dveloppeurs pourront travailler directement sur sa correction.
En plus des courriels automatiques, les dveloppeurs consultent rgulirement le portail du serveur
dintgration depuis leurs postes. Il contient des indicateurs parlants et des statistiques prcises
(exemple de Sonar). En cas d'chec d'intgration du projet on envoie un courriel aux dveloppeurs et
publier un message d'erreur sur une page web de synthse.
IV.2. Le rle des dveloppeurs dans lIntgration Continue

IV.2.1. Lintgration locale
Les dveloppeurs modifient le code, lancent un build priv puis commitent en cas de build priv
russi (sinon corrige les erreurs).
Voici le processus complet :
a. Le dveloppeur rcupre une copie du dernier code source en date partir du serveur
ESP 2013
SVN.
b. Il fait toutes les modifications au code dont il a besoin pour accomplir sa tche.
c. Une fois quil a termin, le dveloppeur lance un build priv sur sa machine.
d. Si le build russi, le dveloppeur peut commencer songer commiter.
e. Le problme est que dautres dveloppeurs auront peut-tre commit leur codes avant
lui (cest gnralement le cas).
f. Pour le vrifier, le dveloppeur doit donc mettre jour sa copie locale pour rcuprer
les dernires modifications.
g. Ensuite, il doit refaire un build priv et
h. Si le build priv rate, le dveloppeur doit rsoudre le problme.
i. Une fois que le build russit avec le code synchronis, le dveloppeur pourra enfin
commiter ses changements.
j. Une fois le code commit, le serveur dintgration lance un build dintgration (dans
le cas dune automatisation on stimulus)
k. Le dveloppeur reoit un courriel quelques secondes plus tard lui indiquant le statut
du build. Ou, il peut consulter, par lui-mme, le portail du serveur ou le blog ddi ou
un moniteur ddi.
On se rend compte que, si tous les dveloppeurs suivent ces tapes la lettre, la possibilit dobtenir
des builds dintgration qui chouent sur le serveur dintgration, est trs faible.
IV.2.2. Les bonnes pratiques du dveloppeur
Le dveloppeur est le principal acteur de lintgration continue. Sans son implication, lintgration
continue est, tout simplement, impossible.
Le dveloppeur devra changer ses habitudes et devra jouer le jeu. Il aura 8 bonnes pratiques mettre
(constamment) en uvre :
a) Commiter le code frquemment

Souvent les dveloppeurs ne veulent pas commiter leurs changements dans le code, soit ils ne veulent
pas affecter le travail des autres, soit ils ne veulent pas tre accuss davoir cass le dernier build.
Malheureusement, cette stratgie savre lourde de consquences sur lintgration continue. En effet,
il faudra dbugger des portions de code plus large, car les changements seront plus importants
(reprsentant le travail de plusieurs jours).
Attendre plus dun jour pour commiter son code mettra en pril lintgration continue, cause dune
perte de temps trop importante pour rsoudre les builds qui seront, coup sr, des checs. Le but est
de faire des petits changements sur son code et de commiter aprs chaque tche. Ds que cela est
possible, le dveloppeur doit commiter son code. Il faut commiter, au minimum, une fois par jour !
ESP 2013
b) Commiter du code bon
Une hypothse dangereuse sur un projet est : tous les dveloppeurs ne commitent jamais du code qui
ne fonctionne pas. Les dveloppeurs ne devront jamais commiter un code qui ne passe pas un test ou
qui ne compile pas avec un autre code. Ils peuvent le vrifier avec la construction de builds privs.
c) Rsoudre les builds rats rapidement

La cause dun build qui a rat peut tre nimporte quoi, cela peut tre une erreur de compilation, un
test qui ne passe pas, une mtrique en dessous dun certain seuil, un dploiement qui a chou.
Dans un contexte dintgration continue, chaque erreur dcouverte doit tre rsolue immdiatement,
elle a de grandes chances dtre petite. Tous les dveloppeurs qui ont commit prcdemment et qui
ont amen un build rat doivent tre impliqus dans la correction.
d) Ecrire des tests automatiss

Les tests sont aussi importants que la compilation. Si un seul test choue, cest le build lui-mme qui
choue.
e) Tous les tests et les rapports dinspection doivent passer

Un dveloppeur peu scrupuleux peut avoir lide de commenter le test qui ne passe pas. Non
seulement, il sera identifi rapidement avec le SVN, mais il participera la baisse du taux de
couverture de test du code.
f) Crer des builds privs

Pour viter des builds intgrs qui chouent, les dveloppeurs vont devoir muler des builds
dintgration sur leurs postes. Le dveloppeur rcupre la dernire version du code depuis le SVN
puis excute le processus de cration du build dintgration localement.
Dans le cas dun build priv russi, qui inclut les rcents changements des dveloppeurs, le
dveloppeur pourra alors commiter ses changements qui auront alors trs peu de chance daboutir
un build dintgration rat.
g) Eviter de rcuprer du mauvais code

Quand le build est dans le rouge sur le serveur dintgration, les dveloppeurs ne doivent pas
rcuprer la dernire version du code. Autrement, ils vont perdre du temps corriger des erreurs qui
ne sont pas les leurs. Dautant plus que, les dveloppeurs responsables du build rat doivent travailler
sur la rsolution de leur code et vont le commiter de nouveau dans le SVN
Ainsi, on voit quil est trs important, qu tout moment les dveloppeurs doivent connaitre ltat du
ESP 2013
dernier build. Lenvoi de courriel par le serveur dintgration continue est donc trs important
Figure II.4: Lintgration continue en un schma
Source :
Fabian Piau
Ibrahima KANE - Mmoire de Fin de Cycle DUT -- Mise en place dune plateforme dintgration continue 2SI
31
IV.2.3. Les diffrents types de build
Le diagramme qui suit illustre les diffrents types de build et leurs frquences (en anglais). En-
dessous nous avons toutes les explications en franais.
Source
Fabian Piau
Figure II.5 : Diagramme illustrant les diffrents types de build http://fabianpiau.com/
IV.2.3.1. Le build priv
Le build priv ou build local (private build) par le dveloppeur: de lordre dune douzaine par jour
par dveloppeur (lancement manuel).
Il rpond la question : Est-ce que mes changements marchent ?
Pourquoi faire des builds privs ?
Faire son build de manire autonome. Sil rate, on est le seul le savoir et on sait que le
problme vient de nous, donc on met tout en uvre pour rsoudre ses erreurs ;
On peut conserver les builds privs sur son poste et pouvoir revenir dessus pour saider (ce
sont des sortes de checkpoint) ;
Les builds privs permettent de partager du code mature avec les autres dveloppeurs.
Autrement dit, ce que lon commite est du code qui a t test grce au build priv.
IV.2.3.2. Le build dintgration de jour
Le build dintgration (integration build) par le serveur dintgration continue: plusieurs par jour
ESP 2013
(lancement automatique).
Il rpond la question : Est-ce que les changements de tout le monde marchent ?
Tous les jours, chaque commit des dveloppeurs ou intervalles de temps rguliers, les projets sont
compils, tests unitairement, dploys et les rsultats sont gnrs sur un blog, envoys par courriel.
Build de jour : compilation + tests unitaires (dure 10-15 minutes)
IV.2.3.3. Le build dintgration de nuit
Le build de nuit (nightly build) par le serveur dintgration continue: une fois par jour (lancement
automatique).
Il rpond la question : Est-ce que le produit marche?
Toutes les nuits une heure bien dfinie, un build dintgration plus complet est ralis sur chacun
des projets. Tous les tests sont excuts. Par exemple, les tests de performance qui sont ignors lors
des builds de jour.
Les builds dintgration de jour (qualifis de partiel) sont plus light que les builds de nuit (qualifis
de complet) pour viter un temps dattente trop long aux dveloppeurs.
Build de nuit : compilation + toutes les catgories de tests + rapports de qualit + packaging +
dploiements. (Dure importante)
V. Proposition dune architecture de la plateforme

+
Schma original
http://blog.octo.com/
Figure II.6: Les diffrents composants de la plateforme
Ce schma reprsente larchitecture de la plateforme dintgration continue avec les outils y

ESP 2013
intervenant. Dans le chapitre qui suit nous allons dtailler sur chacun de ces outils et son
utilit dans lenvironnement.
CHAPITRE III :
MISE EN PLACE DE LA
PLATEFORME
Dans ce chapitre nous allons faire la prsentation des outils et

technologies que nous avons utiliss dans la mise en place de la
plateforme. ESP 2013
MISE EN PLACE DE LA PLATEFORME
CHAPITRE III
I. Le gestionnaire de version : Subversion
Pour russir lintgration continue, lune condition ncessaire est davoir un dpt unique et
centralis du code source et pour y parvenir nous allons garder le mme gestionnaire de version
dj existant 2SI : Subversion
En effet le dveloppement des logiciels implique gnralement des dveloppements parallles,

avec des dveloppeurs qui intgrent leurs travaux sur un produit unique. Il est trs rare, dans les
entreprises, de voir des projets o il ny a quun seul dveloppeur. Tous les changements des
dveloppeurs ont besoin dtre suivis pour pouvoir identifier et rsoudre les problmes potentiels
qui pourraient apparaitre suite lintgration de ces changements.
Cest pour ces raisons quil est important dutiliser un logiciel de gestion de configuration
(Software Configuration Management ou SCM), il versionnera tous les changements du code
source. En plus de versionner le code, tout ce qui est ncessaire pour compiler le projet devrait
tre plac sous un contrle de version, c'est--dire :
Les librairies tierces ;
Les fichiers de proprits ;
Les schmas de base de donnes ;
Les scripts de test ;
Les scripts dinstallation.
Tous les dveloppeurs ont, au moins, un accs en lecture tous les fichiers ncessaires pour
construire un build et ils sidentifient avec un identifiant et un mot de passe. Cette procdure
assure que tous les dveloppeurs puissent travailler avec la dernire version en date du code source.
Subversion fonctionne sur le mode client-serveur, avec :

un Serveur informatique centralis et unique o se situent :
les fichiers constituant la rfrence (le 'dpt' ou 'rfrentiel', ou 'repository' en anglais)
un logiciel serveur Subversion tournant en 'tche de fond'
des postes clients sur lesquels se trouvent :
les fichiers recopis depuis le serveur, ventuellement modifis localement depuis,
et un logiciel client, sous forme d'excutable standalone (ex: SmartSVN) ou de plug-
ESP 2013
in (ex:TortoiseSVN, Eclipse Subversive) permettant la synchronisation, manuelle

et/ou automatise, entre chaque client et le serveur de rfrence
Capture : Interface web dun dpt de projet SVN SSI
Capture : accs au serveur SVN depuis Eclipse
II. Loutil de build : Apache Maven
Pour assurer la gestion et la production automatise des projets nous utilisons loutil de
build Apache Maven qui est un outil logiciel libre pour la gestion et l'automatisation de production
des projets logiciels Java en gnral et Java EE en particulier.
Le build, ce terme anglophone est au cur des concepts de lIC. Un build nest pas quune
simple compilation, cest beaucoup plus. Gnralement on trouve les tches suivantes dans un
build :
a. Chargement de la dernire version du projet depuis le SVN ;
ESP 2013
b. Compilation ;
c. Excution des tests unitaires ;
d. Inspection du code (en vue de gnrer les mtriques de qualit) ;
e. Construction des releases (JAR, WAR, EAR) ;
f. Dploiement de lapplication sur l'environnement de dveloppement (copie des librairies,
configuration et redmarrage, )
g. Excution des tests d'intgration ;
h. Gnration de la documentation, des rapports, des notes de release (Javadoc, rapports
Maven).
Un build, une fois construit, est en fait un package de livrables pour le client qui ont t pleinement
tests. Il contient tous les fichiers ncessaires (excutables, documentation).
Il existe diffrents outils de build (moteur de production) comme par exemple l'outil Ant, mais notre
choix sest arrt sur Maven parce quil fournit des moyens de configuration plus simples bass sur
le format XML.
Maven utilise un paradigme connu sous le nom de Project Object Model (POM) afin de dcrire un
projet logiciel, ses dpendances avec des modules externes et l'ordre suivre pour sa production
II.1. Project Object Model (POM)
Chaque projet ou sous-projet est configur par un POM qui contient les informations ncessaires
Maven pour traiter le projet (nom du projet, numro de version, dpendances vers d'autres projets,
bibliothques ncessaires la compilation, noms des contributeurs etc.). Ce POM se matrialise par
un fichier pom.xml la racine du projet. Cette approche permet l'hritage des proprits du projet
parent. Si une proprit est redfinie dans le POM du projet, elle recouvre celle qui est dfinie dans
le projet parent. Ceci introduit le concept de rutilisation de configuration. Le fichier pom du projet
principal est nomm pom parent. Il contient une description dtaille de notre projet, avec en
particulier des informations concernant le versionnage et la gestion des configurations, les
dpendances, les ressources de l'application, les tests, les membres de l'quipe, la structure entre
autres.
II.2. Convention plutt que configuration
Maven impose une arborescence et un nommage des fichiers du projet selon le concept de Convention
plutt que configuration. Ces conventions permettent de rduire la configuration des projets, tant
qu'un projet suit les conventions. Si un projet a besoin de s'carter de la convention, le dveloppeur
le prcise dans la configuration du projet.
ESP 2013
Voici une liste non-exhaustive des rpertoires d'un projet Maven :

/src : les sources du projet
/src/main : code source et fichiers source principaux
/src/main/java : code source
/src/main/resources : fichiers de ressources (images, fichiers annexes etc.)
/src/main/webapp : webapp du projet
/src/test : fichiers de test
/src/test/java : code source de test
/src/test/resources : fichiers de ressources de test
/src/site : informations sur le projet et/ou les rapports gnrs suite aux traitements effectus
/target : fichiers rsultat, les binaires, les packages gnrs et les rsultats des tests.
II.3. Cration dun archtype pour les projets JEE 2SI
Etant donn que plusieurs fichiers de configurations et certains composants reviennent par dfaut
dans tous les projets initialiss nous avons mis en place un archetype partir dun projet existant
auquel nous avons enlev ses lments spcifiques et que nous avons mavenis par la suite, cest-
-dire que nous avons adapt la convention de Maven.
Un archetype est au fait un template de projet maven ; le fait d'utiliser des archetypes pour initialiser
un projet nous permet de gagner du temps et de respecter une certaine convention.
Pour y parvenir nous avons utilis le plugin archetype de maven avec son goal create-from-project
Commande : mvn archetype:create-from-project
Aprs cela il faut installer larchetype dans le repository local pour pouvoir initialiser un projet avec
en utilisant la commande mvn install ou bien le dployer sur le dpt distant sur Nexus (on prsentera
Nexus dans la prochaine section)
ESP 2013
Capture : Initialisation dun nouveau projet partir dun archetype sur Nexus
Capture : Initialisation dun nouveau projet partir dun archetype sur Nexus
II.4. Cycle de vie dun projet maven
Les buts (goals en anglais) principaux du cycle de vie d'un projet Maven sont:
validate: vrifie que le POM est correct et complet

compile: compile les sources du projet qui se trouvent dans src/main/java et place les fichiers
compils (.class) dans target
test: compile les tests qui se trouvent dans src/test/java et lance l'intgralit des tests, les tests
compils sont placs dans target
package: gnre un package de l'application dans target/artifactId-version.jar
install: utilise le package gnr la phase package et l'ajoute au dpt local. utiliser pour une
bibliothque: elle peut ds lors tre utilise comme dpendance pour un autre projet.
deploy: publie le livrable pour dautres pour dautres projets dans un repository distant
clean: dtruit le rpertoire target
L'ide est que, pour n'importe quel but, tous les buts en amont doivent tre excuts sauf s'ils ont dj
t excuts avec succs et qu'aucun changement n'a t fait dans le projet depuis. Par exemple, quand
on excute mvn install, Maven va vrifier que mvn package s'est termin avec succs (le jar existe
ESP 2013
dans target/), auquel cas cela ne sera pas r-excut.
Source images
Maven: The Definitive Guide
Figure III.1 : Cycle de vie dun projet maven
En plus on peut donner plusieurs phases en paramtres, par exemple

> mvn clean test # excute la phase clean puis la phase test
Enfin, quelque-soit la phase, on peut demander Maven de sauter les tests, pour gagner du temps
> mvn install -Dmaven.test.skip : saute la compilation et l'excution des tests
ou bien
> mvn install -DskipTests # compile les tests mais saute l'excution
Pour gnrer un site internet pour le projet
> mvn site:site
ESP 2013
Pour gnrer la javadoc: la documentation sera gnre dans target/site/apidocs.

> mvn javadoc:javadoc
III. Le gestionnaire de dpt de rfrentiels Maven : Sonatype Nexus
A ct du gestionnaire de version SVN pour avoir un dpt central du code source nous utilisons
aussi le gestionnaire de dpt de rfrentiels Maven.
Nexus est un outil open source crit en Java et distribu sous licence GPL.
Il s'agit d'un gestionnaire de dpt de rfrentiels Maven et vise deux principaux objectifs : agir
comme un proxy entre l'entreprise et les dpts publics de Maven mais aussi comme destinataire de
nos propres artefacts.
Il propose une interface utilisateur et d'administration assez agrable qui utilise la libraire Javascript
Le fait d'utiliser un tel proxy apporte l'avantage essentiel qui est d'acclrer les build en organisant un
cache local du rfrentiel distant. Mais les avantages d'un gestionnaire de repository comme Nexus
sont aussi de :
mieux grer les snapshots que Nexus tient jour dans le rfrentiel local,
permettre de ne rcuprer qu'une seule fois les librairies et leurs dpendances, quel que soit le
nombre de dveloppeurs et de builds,
avoir la possibilit de contrler les dpendances, de choisir la version de tel ou tel framework
utilis par lentreprise,
avoir la possibilit d'inclure ou d'exclure certaines librairies,
avoir la possibilit de dployer les artefacts depuis l'interface,
Autre avantage de Nexus c'est son intgration facile avec Eclipse.
ESP 2013
Capture : Intgration du repository de SSI sepuis Nexus dans Eclipse
sonatype.com
Figure III.2: Principe de fonctionnement de Nexus
Capture : Aperu de la plateforme Nexus montant la liste des dpts prsents
IV. Le serveur dintgration continue : Jenkins
Au sein de la plateforme dintgration se trouve un outil indispensable qui va jouer le rle de matre
dorchestre, cest le serveur dintgration continue Jenkins qui est un outil open source, fork de l'outil
Hudson aprs les diffrents entre son auteur, Kohsuke Kawaguchi, et Oracle.
crit en Java, Jenkins fonctionne dans un conteneur de servlets tel quApache Tomcat, ou en mode
ESP 2013
autonome avec son propre serveur Web embarqu. Il s'interface avec le systme de gestion de
versions Subversion, et excute des projets bass sur Apache Maven.
Comme de nombreux projets Open Source ayant du succs, la force de Jenkins vient de sa grande et
dynamique communaut et de son adoption massive.
Une grande richesse de Jenkins est son systme de plugins, ainsi que le grand nombre de plugins
existant.
Capture : Capture de linterface daccueil du serveur dintgration
Capture : Aperu dun historique de build

ESP 2013
V. Loutil de qualimtrie : Sonar
Un code de bonne qualit, simple, lisible et testable est ncessaire la russite d'un projet de
dveloppement ainsi qu' l'efficacit et la bonne humeur des dveloppeurs qui y participent.
Malheureusement, matriser la qualit du code produit est loin d'tre une tche aise : avec le temps
et au fur et mesure des modifications, le code a une tendance se complexifier. Il doit alors tre
remani par une opration de "refactoring"5 et sa qualit doit tre restaure.
Pour y parvenir nous avons utilis Sonar qui est un outil gratuit et disponible sous la forme de
plug-in pour Maven et qui nous permet de vrifier les rgles de programmation et la complexit
du code source.
Il permet au dveloppeur de visualiser directement les remarques concernant le code quil vient
dcrire. Les rsultats danalyse apparaissent alors dans les tableaux de bord avec des accs au
code concern.
Voici les principaux lments qui sont vrifis et dtects :
Taille du code trop grande ;

Lisibilit du code (cohrence du style de nommage, organisation des sources) ;
Documentation (prsence de la Javadoc) ;
Respect des rgles de paquetages, de modularit, de dpendances et darchitecture en
couches ;
Test et couverture de test ;
Respect des rgles de programmation;
Variables locales non utilises ;
Blocs catch vides ;
Paramtres inutiliss ;
Blocs if vides ;
Imports dupliqus et inutiliss ;
Mthodes prives inutilises ;
Classes transformer en Singleton ;
Noms de variables et de mthodes trop longs ;
Etc.
ESP 2013
5
Le rusinage de code consiste retravailler le code source d'un code informatique sans ajouter de fonctionnalit au
logiciel ni corriger de bogues, mais en amliorant sa lisibilit pour simplifier sa maintenance, ou le rendre plus
gnrique
Avec cet outil, on cherche amliorer le code, et plus particulirement sa :
Usabilit / Lisibilit ;
Maintenabilit ;
Efficacit / Performance ;
Portabilit ;
Fiabilit ;
Testabilit.
Capture : plateforme Sonar, avec un projet de 2SI : projet Plante
ESP 2013
Capture : Tableau de bord du projet Plante avec Sonar
VI. Le Framework de test unitaire : JUnit
Lintgration continue industrialise la gnration des packages, les tests unitaires, la qualimtrie et le
reporting. Lexcution de tests unitaires est une phase non ngligeable dans le processus dintgration
continue, et le principal intrt est de s'assurer que le code rpond toujours aux besoins aprs
d'ventuelles modifications. Plus gnralement, ce type de tests est appel tests unitaires de non
rgression.
Souvent pour tester une classe, il est facile de crer une mthode main() qui va contenir les traitements
de tests. L'inconvnient est que ce code "superflu" est inclus dans la classe. De plus, son excution
doit se faire manuellement.
Pour parer cet inconvnient nous utilisons JUnit qui est un framework open source pour le
dveloppement et l'excution de tests unitaires automatisables. JUnit a t initialement dvelopp par
Erich Gamma et Kent Beck.
JUnit propose :
Un framework pour le dveloppement des tests unitaires reposant sur des assertions qui testent
les rsultats attendus
Des applications pour permettre l'excution des tests et afficher les rsultats
Le but est d'automatiser les tests. Ceux-ci sont exprims dans des classes sous la forme de cas de tests
avec leurs rsultats attendus. JUnit excute ces tests et les comparent avec ces rsultats. Cela permet
de sparer le code de la classe, du code qui permet de la tester.
ESP 2013
CONCLUSION
Pour conclure nous retenons que lintgration continue permet de dvelopper mieux, plus
rapidement, un cot moins lev, avec plus de confiance : better, faster, cheaper. Ce nest pas un
outil, mais un processus qui utilise des outils et fournit une vraie valeur ajoute nos projets
informatiques.
La communication est un des piliers centraux pour la mise en place dun tel projet, car lintgration
continue est un concept relativement nouveau qui peut bouleverser les habitudes du dveloppeur. Une
conduite au changement est indispensable. Il faut donc sensibiliser les membres de lquipe.
Personnellement ce stage que nous avons effectu 2SI nous a t dun grand apport dans la mesure
o il nous a permis non seulement de faire face aux ralits du monde professionnel, mais aussi
dtendre nos connaissances en matire de nouvelles mthodes et organisation du travail en quipe.
ESP 2013
Bibliographie
INTEGRATION CONTINUE :
Amliorer la qualit des logiciels et rduire les risques
Un dossier de Fabian Piau, Juillet 2009
JENKINS : LE GUIDE COMPLET

Jennifer Knight
David Futato
Robert Romano
Angela Howard
Karen Montgomery
Copyright 2011 John Ferguson Smart
Imprim aux tats-Unis dAmrique.
Webographie
Liens Date dernire visite

http://fr.wikipedia.org/wiki/Software_factory 28/09/2013
http://www.scub-foundation.org 26/08/2013
http://www.kalyss.com 28/09/2013
http://blog.pascal-martin.fr/post/integration-continue-jenkins- 28/09/2013
installation-configuration#integration-continue
https://fr.wikibooks.org/wiki/D%C3%A9velopper_en_Java/Intro 28/09/2013
duction_%C3%A0_Apache_Maven
http://www.zenika.com/Conseil/integration-continue.html 28/09/2013
ESP 2013
Gloassaire
Un archetype est un template de projet maven.

Le fait d'utiliser des archetypes pour initialiser un projet permet de gagner du temps et de respecter
une certaine convention.
Une dpendance est une rfrence vers un artefact spcifique contenu dans un repository.
Cet artefact est ncessaire pour une ou plusieurs phases du cycle de vie du projet.
Dans Maven, un artefact est un lment spcifique issu de la construction du logiciel. Dans
JAVA, les artefacts les plus communs sont des JARs, mais ce peut tre aussi un fichier WAR, un
EAR, un ZIP, etc...
Un repository local est un rpertoire sur le poste du dveloppeur permettant de stocker, suivant
la mme arborescence, tous les artefacts tlchargs depuis le(s) repository distant(s).
Environnement de dveloppement : il s'agit de l'environnement dans lequel le programme est
crit. Le plus souvent on parle d'un IDE (Integrated Development Environment) comme Eclipse ou
Visual Studio, mais les librairies, les fichiers de configuration, les serveurs ou les builds scripts
en font aussi partie.
Le Java Development Kit (JDK) est l'environnement dans lequel le code Java est compil pour
tre transform en bytecode afin que la JVM (machine virtuelle de Java) puisse l'interprter.
La qualit est une valeur donne aux diffrentes spcificits du produit. Ce terme est trs
subjectif et peut varier en fonction des priorits de chacun et de la pondration quon attribue ces
spcificits. Parmi elles on trouve : lentretien, la scurit, les performances, lextensibilit, les tests
oprs durant la conception du programme, etc.
Le risque est la potentialit quune erreur survienne.
Ajax (acronyme d'Asynchronous JavaScript and XML) permet de construire des applications
Web et des sites web dynamiques interactifs sur le poste client en se servant de diffrentes
technologies ajoutes aux navigateurs web entre 1995 et 2005.
XHTML (Extensible HyperText Markup Language) est un langage de balisage servant
crire des pages pour le World Wide Web.
MVC (modle-vue-contrleur) cest un modle destin rpondre aux besoins des applications
interactives en sparant les problmatiques lies aux diffrents composants au sein de leur
architecture respective.
JVM : La machine virtuelle Java (en anglais Java virtual machine) est un appareil informatique
fictif qui excute des programmes compils sous forme de bytecode Java.
HQL (Hibernate Query Language) est le langage d'interrogation de donnes qui vient avec
Hibernate.
JDBC (Java DataBase Connectivity) est une interface de programmation cre par Sun
Microsystems qui permet aux applications Java d'accder par le biais d'une interface commune
des sources de donnes pour lesquelles il existe des pilotes JDBC.
GNU LGPL (pour GNU Lesser General Public License) en anglais, est une licence utilise par
certains logiciels libres.
SCM (software configuration management), la gestion de configuration logicielle est une
discipline du gnie logiciel ayant pour objet de rpondre la question : quelqu'un a obtenu un
ESP 2013
rsultat. Comment le reproduire ? Le plus souvent, il ne s'agit pas de reproduire l'identique, mais
de reproduire avec des modifications incrmentales. La question est donc de comparer des rsultats
et d'analyser leurs diffrences.

Mémoire DUT 2013 - Ibrahima KANE - 2SI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mémoire DUT 2013 - Ibrahima KANE - 2SI

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU SENEGAL

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE

MEMOIRE DE FIN DE CYCLE

DIPLOME UNIVERSITAIRE DE TECHNOLOGIE EN INFORMATIQUE

Mise en place dune plateforme dintgration continue 2SI

15 mai 2013 - 30 juillet 2013

Prsent par : Encadr par : Matre de stage :

Anne universitaire : 2012 2013

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE

MEMOIRE DE FIN DE CYCLE

DIPLOME UNIVERSITAIRE DE TECHNOLOGIE EN INFORMATIQUE

Mise en place dune plateforme dintgration continue 2SI

15 mai 2013 - 30 juillet 2013

Prsent par : Encadr par : Matre de stage :

Anne universitaire : 2012 2013

A la mmoire de ma trs chre mre,

La dfunte et la regrette Fatou Thiam DIOP

I. Cycle de dveloppement 2SI ..................................................................................... 22

II.5 JBoss Application Server ................................................................................. 24

Figure I.1 : Position de 2SI sur Google Maps ........................................................................ 16

Figure II.1 : Schma du cycle de dveloppement 2SI ........................................................ 22

Figure II.4: Lintgration continue en un schma ................................................................ 32

Figure II.5 : Diagramme illustrant les diffrents types de build ......................................... 33

Figure II.6: Les diffrents composants de la plateforme ...................................................... 34

Figure III.1 : Cycle de vie dun projet maven ....................................................................... 41

Figure III.2: Principe de fonctionnement de Nexus .............................................................. 43

La prsentation gnrale permet davoir une ide globale du sujet, mais

LEcole Suprieure Polytechnique de Dakar (ESP) est un tablissement public caractre

Etablissement public vocation rgionale, sous la tutelle du Ministre de lEducation, lEcole

I.2.1 Le dpartement Gnie Informatique :

Ce dpartement forme des techniciens suprieurs, assistants ingnieurs, des ingnieurs en

I.3. Objectifs et missions

LESP a pour objectif et missions de :

Pour plus de dtails, on peut se rfrer au site officiel de lESP (www.esp.sn).

Figure I.1 : Position de 2SI sur Google Maps

Figure I.2 : Organigramme de 2SI

II.3.1 La Direction tudes et Ingnierie Logicielle

Spcialise dans ldition et l'intgration de solutions logicielles, la Direction tudes et

La Direction Automation est spcialise dans les domaines de la conception et la

II.3.3 La Direction Services Valeur Ajoute

II.3.4 La Direction Web et Multimdia

II.3.5 Le Centre de Formation Professionnelle et de Perfectionnement

Le Centre de Formation Professionnelle et de Perfectionnement, CF2P est un centre ddi aux

Figure I.3 : schma illustrant un software factory

d'intgration. Celui-ci est excut chaque changement dans l'environnement d'infrastructure du

Cette tude de lexistant nous permet de faire le bilan sur le

Figure II.1 : Schma du cycle de dveloppement 2SI

De faon succincte ce schma reprsente le fonctionnement du cycle de dveloppement 2SI.

dveloppeurs peuvent faire des mises jour.

II.2. La technologie des EJB

II.4. Le Framework Hibernate

II.5. JBoss Application Server

III. Critiques de lexistant

grer automatique les dpendances dans le projet.

Figure II.2 : Courbe dvolution des bogues dans le processus de dveloppement

IV. Proposition dune solution : lintgration continue (IC)

Lintgration continue industrialise :

Avant la mise en place de lintgration continue :

Aprs la mise en place de lintgration continue :