Rapport 2

MISE EN PLACE D’UN SYSTEME D’INTEGRATION CONTINUE
DEDICACE
A TOUS CEUX QUI ME SONT

CHERS, JE DEDIE CE TRAVAIL.
TCHAYA TCHANGA GOODNESS

FTIC/ Licence en Génie Informatique
Université Protestante d’Afrique Centrale i

Anné e acadé mique 2021/2022
REMERCIEMENTS
C’est avec un grand plaisir que je réserve cette page en signe de gratitude et de profonde
reconnaissance à tous ceux qui ont apporté l’assistance nécessaire au bon déroulement de ce
travail.:
 Mes remerciements les plus distingués sont adressés au président du jury qui me fait
l’honneur de présider les membres du Jury de ce mémoire.
 Mes sincères remerciement s’adressent aussi à tous l’examinateur qui me fait l’honneur
de bien vouloir accepter d’évaluer mon travail
 J’exprime mes profondes reconnaissance et gratitude à M. PEGOFFA FABRICE mon
encadreur académique, qui m’a aidé et donné des conseils dans l’orientation du mémoire
et de sa rédaction
 Je remercie M. AYISSI PHILIPPE mon encadreur professionnel, qui m’a aidé et guidé
autant pour ma mission de stage au sein de ICCSOFT que pour la rédaction de ce
mémoire.
 Je suis également reconnaissante envers M. SIYOU HERVE qui a bien voulu
m’accordé une place de stagiaire au sein du département de développement de logiciels
dont il a la charge.
 Grande est ma reconnaissance envers mes Parents, qui m’ont encouragé moralement,
physiquement et financièrement.
 Je remercie particulièrement tout le personnel de ICCSOFT pour leur accueil
chaleureux au sein de leurs locaux.
 Ma profonde gratitude à mes frères, amis, et camarades, pour l’assistance, la patience
et l’aide dans les tests de bon fonctionnement de mon système.
 Enfin, je remercie tous ceux qui de près ou de loin m’ont soutenu et ont contribué à
l’acheminement de ce travail.

Université Protestante d’Afrique Centrale ii

SOMMAIRE
DEDICACE··················································································································································i
REMERCIEMENTS···································································································································ii
SOMMAIRE···············································································································································iii
LISTE DES FIGURES································································································································v
LISTE DES TABLEAUX···························································································································vi
LISTE DES ABREVIATIONS··················································································································vii
RESUME··················································································································································viii
ABSTRACT···············································································································································ix
INTRODUCTION GENERALE·················································································································1
CHAPITRE I : ANALYSE DE L’EXISTANT···························································································2
I. PRESENTATION DE L’ENTREPRISE·························································································3
1. HISTOIRE···································································································································3
2. MISSIONS··································································································································3
3. ACTIVITÉS································································································································3
4. LOCALISATION GÉOGRAPHIQUE························································································4
II. PROCEDURE DE DEVELOPPEMENT·························································································5
III. LIMITES·····································································································································6
IV. L’INTEGRATION CONTINUE·································································································7
1. DEFINITION·······························································································································7
2. FONCTIONNEMENT DE L’INTEGRATION CONTINUE······················································9
3. ETAPES DE L’INTEGRATION CONTINUE··········································································10
4. DIFFERENTS COMPOSANTS D’UNE PLATEFORME D’IC···············································11
CHAPITRE II : ETAT DE L’ART············································································································13
I. CRITERES DE COMPARAISON································································································14
II. SOLUTIONS EXISTANTES········································································································14
1. JENKINS···································································································································14
2. TRAVIS·····································································································································15

Université Protestante d’Afrique Centrale iii

3. BAMBOO··································································································································15
III. TABLEAU RECAPITULATIF·································································································16
CHAPITRE III : DEPLOIEMENT DE LA SOLUTION···········································································17
I. ARCHITECTURE DE DEPLOIEMENT······················································································18
II. PRESENTATION DES OUTILS A UTILISER············································································19
1. GESTIONNAIRE DE VERSION······························································································19
2. SERVEUR DE QUALITE DE CODE·······················································································20
3. GESTIONNAIRE DE DEPOT··································································································20
III. INSTALLATION DES OUTILS·······························································································21
1. INSTALLATION DE JAVA·····································································································21
2. INSTALLATION DE GIT········································································································22
3. INSTALLATION DE JENKINS·······························································································24
4. INSTALLATION DE SONARQUBE·······················································································37
5. INSTALLATION DE NEXUS··································································································38
CHAPITRE IV : PRESENTATION DES RESULTATS··········································································39
I. CONFIGURATION DU PROJET·································································································40
II. RESULTATS································································································································46
CONCLUSION GENERALE···················································································································52
REFERENCES BIBLIOGRAGRAPHIQUES···························································································52
TABLE DES MATIERES·························································································································53

Université Protestante d’Afrique Centrale iv

LISTE DES FIGURES
Figure 1:localisation de ICCSOFT S.A---------------------------------------------------------------------------------------- 4

Figure 2:Procédure suivi [4]--------------------------------------------------------------------------------------------------- 5
Figure 3: Avant la mise en place de l'intégration continue [4]---------------------------------------------------------5
Figure 4: Architecture existante---------------------------------------------------------------------------------------------- 5
Figure 5: Etapes d’une intégration continue [16]-----------------------------------------------------------------------10
Figure 6: Architecture à mettre en place---------------------------------------------------------------------------------- 18
Figure 7: Installation de Java------------------------------------------------------------------------------------------------ 21
Figure 8: Installation de git-------------------------------------------------------------------------------------------------- 22
Figure 9: Connexion à son compte GitHub-------------------------------------------------------------------------------23
Figure 10: Copie du projet en local---------------------------------------------------------------------------------------- 24
Figure 11: Port de Jenkins autorisé----------------------------------------------------------------------------------------- 26
Figure 12: Déverrouiller Jenkins-------------------------------------------------------------------------------------------- 27
Figure 13: Personnalisation de Jenkins------------------------------------------------------------------------------------ 28
Figure 14: Installation des plugins------------------------------------------------------------------------------------------ 29
Figure 15: Création de l'utilisateur----------------------------------------------------------------------------------------- 30
Figure 16: Confirmation de l'adresse-------------------------------------------------------------------------------------- 31
Figure 17: Page prête pour jenkins----------------------------------------------------------------------------------------- 32
Figure 18: Page d'accueil de Jenkins--------------------------------------------------------------------------------------- 33
Figure 19:Page de gestion de Jenkins-------------------------------------------------------------------------------------- 34
Figure 20: Configuration de Jenkins--------------------------------------------------------------------------------------- 34
Figure 21: Configuration d'une installation Maven--------------------------------------------------------------------35
Figure 22: Configuration d'une installation JDK------------------------------------------------------------------------35
Figure 23: Gestion des plugins dans Jenkins-----------------------------------------------------------------------------37
Figure 24: Dire à Jenkins où trouver le code source-------------------------------------------------------------------41
Figure 25: Planification des tâches de génération-----------------------------------------------------------------------42
Figure 26: Ajout d'une étape de génération-------------------------------------------------------------------------------42
Figure 27: Configuration des rapports de test JUnit--------------------------------------------------------------------43
Figure 28: Configuration l'archivage des artefacts----------------------------------------------------------------------44
Figure 29: Configuration de scanner avec SonarQube-----------------------------------------------------------------44
Figure 30: Configurations des notifications------------------------------------------------------------------------------45
Figure 31: Première tâche de construction en cours d'exécution----------------------------------------------------46
Figure 32: Premier build réussi--------------------------------------------------------------------------------------------- 47
Figure 33: Tableau de bord de Jenkins------------------------------------------------------------------------------------ 48
Figure 34: Construction ayant échouée------------------------------------------------------------------------------------ 48
Figure 35: Historique des tests échoués----------------------------------------------------------------------------------- 49
Figure 36: Liste de tous les tests cassés----------------------------------------------------------------------------------- 49
Figure 37: La construction est de retour à la normale------------------------------------------------------------------50
Université Protestante d’Afrique Centrale v

Figure 38: Détails d'un test réussi------------------------------------------------------------------------------------------ 51
LISTE DES TABLEAUX
Tableau 1: Comparaison des serveurs d'intégration continue----------------------------------------------------16

Université Protestante d’Afrique Centrale vi

LISTE DES ABREVIATIONS
 CCEC : Caisse Camerounaise d’Epargne et de Crédit

 CI : Continuous Integration
 CVS : Concurrent Version System
 DSL : Digital Subscriber Line
 IC : Intégration Continue
 ICCSOFT : International Computer Center Software
 JDK : Java Development Kit
 JSON : JavaScript Object Notation
 SCM : Source Code Management
 SDK : Software Development Kit
 SVN : Social Venture Network

Université Protestante d’Afrique Centrale vii

RESUME
L'intégration continue est devenue un des piliers des bonnes pratiques du développement
logiciel. Les besoins exprimés par les scientifiques sont divers. Le principal point est de les
soulager de toutes les tâches de test, d’assemblage, de vérification manuelle en leur offrant un
service clés en main. Ils veulent aussi avoir une grande latitude sur les versions et plugins
utilisés. Après analyse de ces besoins, il est apparu indispensable que la mise à disposition d'un
serveur d'intégration continue soit la plus automatisée possible. Cela passe par la détection
d’erreurs, la vérification des résultats des tests, ou encore la détection de code dupliqué. Dans
quelle mesure pouvons-nous mettre en place une plateforme d’automatisation de tests et de
vérification de code ? il sera question pour nous de réaliser notre projet sous le thème « Mise en
place d’un système d’intégration continue ». Nous proposons donc la mise en place d’une
plateforme de tests équipé d’un serveur d’intégration, qui malgré une orientation Java peut
convenir à tout type de projet de développement.Un bilan sera ensuite établi à propos des
résultats obtenus, c’est-à-dire permettre aux différentes équipes de développeurs d’assembler
leurs codes, tout en permettant les tests rapides des projets, ainsi que sur les perspectives
éventuelles afin de continuer à améliorer la solution. Cela permettra d’économiser plus de temps,
et d’argent.
Mots clés : Intégration continue, test, automatisation, assemblage de code.

Université Protestante d’Afrique Centrale viii

ABSTRACT
Continuous integration has become one of the pillars of best practices in software
development. The needs expressed by scientists are diverse. The main point is to relieve them of
all the testing, assembly and manual verification tasks by offering them a turnkey service. They
also want to have a lot of latitude on the versions and plugins used. After analyzing these needs,
it appeared essential that the provision of a continuous integration server be as automated as
possible. This involves detecting errors, verifying test results, verifying their coverage, or even
detecting duplicate code. To what extent can we set up a test automation and code verification
platform? It will be a question for us to carry out our project under the theme “Implementation of
a continuous integration system”. We therefore propose the implementation of a test platform
equipped with an integration server, which despite a Java orientation can be suitable for any type
of development project. A report will then be established on the results obtained, i.e. allowing
the various teams of developers to assemble their codes, while allowing rapid testing of the
projects, as well as on the possible prospects in order to continue to improve the solution. This
will save more time and money.
Keywords: Continuous integration, testing, automation, code assembly.

Université Protestante d’Afrique Centrale ix


Université Protestante d’Afrique Centrale 1

I. PRESENTATION DE L’ENTREPRISE
II. PROCEDURE DE DEVELOPPEMENT
III. LIMITES
IV. L’INTEGRATION CONTINUE
Le présent chapitre a pour objectif de mettre le projet dans son cadre général à savoir
l'entreprise accueillante. Par la suite, nous enchainerons avec l’étude de l’existant en présentant
les différentes procédures ainsi que les limites. Puis nous abordons le concept de l’intégration
continue avec son fonctionnement et ses composants.
I. PRESENTATION DE L’ENTREPRISE
1. HISTOIRE
ICCSOFT (International Computer Center Software) est une société du groupe ICCNET
(International Computer Center Network) créer le 1er Janvier 2003, et qui a hérité de nombreuses
années de savoir-faire en informatique et gestion des systèmes d’informations. ICCSOFT est un
service et ingénierie en informatique, spécialisé dans l’édition, l’intégration de systèmes
complexes (gratuits &/ propriétaire), et la fourniture de services de conseil et de support à ses


partenaires. Plus spécifiquement, ICCSOFT S.A à développer des compétences pour le soutient
des services de l’Etat et comme appui au développement des systèmes d’informations
2. MISSIONS
ICCSOFT met au service de ses clients (Etats, Institutions Publiques et Entreprises
Privées), ses compétences dans les domaines de gestion des systèmes d'informations. Les
missions d'ICCSOFT comprennent :
 L’accompagnement dans les choix technologiques ;
 Le design de solutions adaptées aux besoins définis par ses clients avec le soutien
de l’entreprise ;
 Réalisation d'une analyse indépendante :
 Optimiser les solutions par des développements spécifiques.
3. ACTIVITÉS
ICCSOFT a été créé dans le but de fournir des services en informatique. Ses activités sont
centrées sur l'aspect technique de l'étude et de la consultation ainsi que sur l'expertise dans les
systèmes d'information de contrôle. ICCSOFT est en mesure de fournir une expertise :
 Développement de logiciel
 Intégration de solutions ERP
 Intégration de solution de système d'information géographique,
 Intégration des outils de travail collaboratif des systèmes de communication unifiés.
 Intégration de solutions de gestion électronique de documents,
 Maîtrise du cycle de vie du logiciel, Développement de composants logiciels
commutateurs, interfaces de signalisation (SS7, RNIS, R2, exploitation et plates-
formes ;
 Applications d'échange de données informatisées aux normes EDI ;
 Applications d'échange sécurisé par cryptage et signature ;
 Intégration, validation des systèmes ;

 Suivi, métier, support client
4. LOCALISATION GÉOGRAPHIQUE
Figure 1:localisation de ICCSOFT S.A
ICCSOFT se situe à la montée Anne-Rouge, à côté de la CCEC
II. PROCEDURE DE DEVELOPPEMENT
ICCSOFT S.A suit une procédure classique dans la gestion de ses projets, en effet
l’équipe de développeurs met l’accent sur le développement des fonctionnalités.
Figure 3: Avant la mise en place de l'intégration continue [4]
Les figures 2 et 3 montrent que l’équipe passe par une partie conceptuelle du produit,
puis développe le code, en faisant des tests en local, et enfin génère le livrable pour ses clients.
TCHAYA
Figure 2:Procédure TCHANGA
suivi [4] GOODNESS

Figure 4: Architecture existante
La figure 4 nous montre que le produit tourne sur un serveur applicatif Tomcat avec une base
de donné Postgresql, et un serveur web Apache.
III. LIMITES
Nous pouvons extraire ces limites de l’architecture existante :
 Le produit se livre sans exécuter les tests nécessaires tels que les tests unitaires et les
mesures de la qualité de code.
 Les artéfacts de l’application passent du local de l’équipe de développeurs au client
directement sans passer par un gestionnaire de dépôt.
 . Grande surcharge dû aux différentes sources
Ça reste toujours des lacunes devant les ambitions d’une jeune entreprise qui vise un grand
marché non seulement en Afrique mais aussi en Europe.
Pour faire face aux limites mentionnées ci-dessus, ICCSOFT nous a confié la tâche de
l’étude et la mise en place d’une plateforme d’intégration continue.


IV. L’INTEGRATION CONTINUE
1. DEFINITION
L’intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant

à vérifier à chaque modification de code source que le résultat des modifications ne produit pas
de dérive dans l’application développée [5]. Autrement dit, l’IC sert à vérifier que l’ajout ou la
modification de lignes de code n’a pas introduit ou découvert d’erreurs ou de problèmes dans le
code existant.
Généralement, l’intégration classique consiste à assembler à la fin du projet toutes les

fonctionnalités développées. Le projet est ensuite testé et une longue phase de tests et de
corrections de bogue débute. Néanmoins, il est plus difficile de corriger le code une fois que tout
est réalisé qu’au fur et à mesure du projet. Cela entraîne des coûts supplémentaires de
développement et éventuellement, un manque de temps peut provoquer la sortie du projet
contenant toujours d’importants bogues [1].
Ce sont ces différents problèmes que l’intégration continue cherche à résoudre. Pour
simplifier le processus d’intégration continue, on utilise des serveurs d’intégration continue, qui

sont des outils permettant de gérer des projets et configurer la compilation ainsi que le processus
de déploiement. La plupart de ces outils disposent de fonctionnalités permettant la génération de
rapports ou de métadonnées à propos des projets.
L’intégration continue s’impose comme une solution incontournable. En effet, sans IC le

logiciel développé est considéré comme non fonctionnel jusqu’à ce que quelqu’un l’exécute sans
problème, habituellement dans une phase de test ou d’intégration. Avec l’IC, le logiciel est
certifié 100% fonctionnel malgré les nouvelles modifications [4].
Ces dernières peuvent causer des bugs, que l’équipe de développement sait quand elles
peuvent surgir et comment les résoudre immédiatement. Les logiciels développés en utilisant
l’intégration continue sont connus pour être livrés plus rapidement et avec moins de bugs, par
rapport à des logiciels qui ne sont développés avec l’IC. En effet, les bugs sont découverts très
tôt dans le processus de développement afin d’éviter qu’ils soient chers à réparer. Ce qui fournit
d’importantes économies en coûts et en temps. Par conséquent, on peut considérer l’IC comme
une pratique incontournable pour les projets professionnels.
Afin d’implémenter l’intégration continue, certains prérequis sont indispensables [5].

Nous aborderons ces prérequis et certaines bonnes pratiques que les équipes doivent mettre en
place afin d’assurer un bon fonctionnement de l’intégration continue.
Le premier important prérequis pour implémenter l’IC est sans doute un logiciel de
gestion de version. En effet, le développement logiciel implique généralement des développeurs
qui chacun travaillent sur une copie du code source et ensuite les copies sont rassemblées pour
constituer une seule. Afin de permettre cela, un gestionnaire de version est nécessaire qui en
outre garde l’historique des modifications de chacun afin d’assurer un suivi, ce dernier permettra
de facilement d’identifier et de résoudre les problèmes potentiels. Il est évident, que le
gestionnaire de version doit être utilisé pour archiver le code source, les tests, les scripts de base
de données, les scripts du build.
Le deuxième prérequis est l’automatisation du processus de build. Il faut être en mesure de

démarrer ce processus par ligne de commande ou par un ensemble complexe de scripts.
Quel que soit le mécanisme utilisé, une personne ou un programme doit être capable de lancer le
build, les tests de manière automatisée.

Il est important de donner une définition du mot "build" avant de continuer d’expliquer le
fonctionnement de l’intégration continue. Le build est un terme anglophone qui désigne l’activité
principale qui conduit à la construction de l’application [5].
2. FONCTIONNEMENT DE L’INTEGRATION CONTINUE
Cette méthode repose sur la mise en place d’une brique logicielle qui va permettre
l’automatisation de plusieurs tâches [4] :
 La compilation automatique du code et de ses dernières modifications,

 Mise à jour du code source de l’application depuis le gestionnaire de version.
 Les tests unitaires et fonctionnels,
 La validation du produit en fonction de plusieurs critères,
 Des tests de performances afin de procéder à certaines optimisations
 Revue du code pour vérifier la qualité.
 Génération de la documentation.
 Génération de l’exécutable.


3. ETAPES DE L’INTEGRATION CONTINUE
L’utilisation du schéma qui suit permet de comprendre et d’expliquer plus en détail ce

qu’est l’intégration continue ainsi que son fonctionnement
Figure 5: Etapes d’une intégration continue [16]
La présente figure nous montre les étapes d’une intégration continue.


 Etape 1 : Les différents développeurs du projet travaillent ensemble et développent les
fonctionnalités et modules qui leur sont attribués. Chacun veille à tester le code écrit à
l’aide de tests unitaires, et vérifie que tout fonctionne dans son environnement. Une fois
testé, chaque développeur peut ensuite envoyer son code auprès du gestionnaire de
versions. A chaque envoi appelé commit, le code est fusionné au code déjà existant. Les
autres développeurs peuvent ensuite récupérer et mettre à jour (update) le code sur leur
machine ;
 Etape 2 : L’utilisation d’outil d’intégration continue permet de récupérer le code publié
sur le gestionnaire de versions. Cela peut être réalisé automatiquement à chaque commit,
à intervalles réguliers ou manuellement. Ce choix dépend purement de l’outil utilisé ainsi
que de la volonté de l’utilisateur.
 Etape 3 : Une fois le code récupéré par le serveur d’intégration continue, il est ensuite
possible de compiler ce code ainsi que d’exécuter les tests qu’il contient.
 Etape 4 : Une fois la compilation et l’exécution des tests terminés, les informations sur la
réussite ou non de l’étape précédente sont transmises à l’utilisateur. De plus, des rapports
concernant la qualité, la stabilité ou la découverte de bogues peuvent être générés.
 Etape 5 : Les rapports peuvent ensuite être analysés afin de corriger les éventuels
problèmes rencontrés.
Grâce aux tests très réguliers du code développé, les problèmes sont détectés dès leur
apparition. Il est ainsi plus facile et rapide de les corriger : le projet n’étant pas terminé, il y a de
fortes chances d’avoir moins de parties du code à modifier, ce qui entraîne un gain de temps au
final. L’on constate qu’il est très important d’avoir un suivi régulier de l’état de chaque build afin
d’informer les développeurs. Pour cela il faut que le serveur d’intégration soit équipé avec un
mécanisme d’envoi de courriel.
4. DIFFERENTS COMPOSANTS D’UNE PLATEFORME D’IC


 L’ordonnanceur : c’est le chef d’orchestre du système [1]. Il ordonne les tâches pour
qu’elles se réalisent dans le bon ordre. Il remonte également les erreurs aux utilisateurs
[1].
 Le gestionnaire de source (VCS) : dans cette application se retrouve l’ensemble des
sources sous différentes versions. Il est possible de revenir en arrière facilement, de créer
des branches (pour différentes versions d’un même projet [4].
 Le compilateur : c’est l’outil qui permet de traduire le code source (par exemple, du C)
en langage compréhensible par la machine, ou par un interpréteur [4].
 Les tests unitaires : ce composant permet d’effectuer et de jouer l’ensemble des tests
unitaires définis dans un projet [5].
 Le contrôle qualité : ce composant est chargé d’assurer la qualité du code en fonction de
plusieurs paramètres [4].
 Le dépôt de binaire : ce composant permet le stockage des différentes versions d’un
projet après compilation [4]. Il peut aussi servir comme source pour des composants
utilisés dans son propre projet.
Au cours de ce premier chapitre, nous avons commencé par présenter l’organisme d’accueil
ICCSOFT S.A. Par la suite nous avons étudié l’existant en citant ses limites puis nous avons
présenté son architecture ainsi que le principe de l’intégration continue. Nous détaillerons dans le
chapitre suivant clairement la migration vers les nouvelles technologies.


CHAPITRE II : ETAT DE L’ART

Préambule
L’état de l’art est le document où nous présenterons toutes les informations existantes
concernant le domaine de recherche. Dans cette section nous parlerons de l’intégration continue
et des environnements de test.
Vue d’ensemble


I. CRITERES DE COMPARAISON
Nous commençons ce chapitre par la mise en évidence des différentes solutions existantes, ainsi
que nos différents critères pour la réalisation de note projet.
I. CRITERES DE COMPARAISON
Jenkins, travis et bamboo sont des outils d’orchestration bien connu sur le marché, chacun
d’entre eux présente ses avantages et ses inconvénients. La comparaison se base sur :
 Licence : Capacité d’être librement utilisé, modifier ou partager

 Le nombre de plugins : Capacité d’intégrer de nouvelles fonctionnalités
 Communauté d’utilisateurs : Personnes rassembler autour du logiciel
 Compatibilité avec la gestion de version : Capacité de gérer les différentes versions
produites


II. SOLUTIONS EXISTANTES
Dans cette partie, nous présentons les différents outils qui existent sur le marché.
1. JENKINS
.
Jenkins, débuté en 2011 comme branche d’un autre outil populaire Hudson, est l’outil le
plus utilisé pour l’intégration continue[1]. C’est un serveur conçu en Java qui, grâce à ses
plusieurs centaines de plugins, permet la découverte de défauts au début du cycle d’un projet. Il
supporte un nombre important de langages et d’outils de compilation
Jenkins permet de tester et de rapporter les changements effectués sur une large base de
code en temps réel. En utilisant ce logiciel, les développeurs peuvent détecter et résoudre les
problèmes dans une base de code et rapidement. Ainsi les tests de nouveaux builds peuvent être
automatisés, ce qui permet d’intégrer plus facilement des changements à un projet, de façon
continue. L’objectif de Jenkins est en effet d’accélérer le développement de logiciels par le biais
de l’automatisation. Jenkins permet l’intégration de toutes les étapes du cycle de développement.
Jenkins peut être installé à partir de packages Ubuntu ou en téléchargeant et en exécutant

son fichier d’archive d’application Web, une collection de fichiers qui constituent une
application Web complète à exécuter sur un serveur.
2. TRAVIS
Travis est une solution d’intégration continue à l’origine créée pour des applications
Rails, mais qui supporte désormais des dizaines de langages comme PHP, JavaScript, C/C++ ou
encore Python. Contrairement aux précédents outils, Travis est hébergé en ligne : Aucune
installation n’est donc nécessaire. Il dispose également d’une importante communauté aidant les
nouveaux utilisateurs. Cela empêche donc de le personnaliser comme on pourrait le faire avec
des plugins pour d’autres outils. Travis est intégré avec GitHub : il enregistre tous les ajouts de
code et compile automatiquement ensuite. Il est toutefois limité à celui-ci, il n’est pas possible


d’utiliser d’autres outils de gestion de version pour lui fournir le code source. Il est de plus
payant pour les dépôts privés de GitHub [1].
3. BAMBOO
Créé par Atlassian, les développeurs de très populaires travail d'équipe logiciels, tels que Jira
et Trello, Bamboo est une solution d'intégration, de déploiement et de livraison continue [1].
Avec le serveur Bamboo, les développeurs peuvent procéder à l’intégration, au déploiement et à
la gestion des versions. Le fabricant Atlassian propose ce logiciel en tant qu’interface Web basée
sur Java. Bamboo assiste les développeurs avec des automatisations et fonctionne avec différents
outils de build. Pour les projets open source, cette offre normalement payante est également
disponible gratuitement.
III. TABLEAU RECAPITULATIF

Le présent tableau permet de comparer ces outils.
Tableau 1: Comparaison des serveurs d'intégration continue
Aspect Jenkins Bamboo Travis
Licence Open Source Payante Open Source
Nombre de Plugins +1800 Très coûteux Très peu
Communauté d’utilisateurs Oui Non Oui
Outils de versionning Tout Tout GitHub


L’étude comparative entre ces différents serveurs a dirigé notre choix vers Jenkins, qui,
grâce à ses nombreux plugins, permet un interfaçage facile avec de nombreux outils dont nous
avons besoin tel que Nexus et Sonar.
Une description de notre architecture a été fait dans ce chapitre. Quelques outils
d’intégration continue ont été présentés concernant leur classification, principe de
fonctionnement ainsi que leur qualité et leurs défauts. Après avoir présenté l’outils retenus par
notre système, la suite du travail est consacrée au déploiement de notre solution.
CHAPITRE III : DEPLOIEMENT DE LA SOLUTION
Préambule
Mettre en place l'intégration continue suit un chemin qui fera passer par différentes phases.
Dans cette section, nous présenterons les différents outils ainsi que leur installation.
Vue d’ensemble


I. ARCHITECTURE DE DEPLOIEMENT
Après avoir exposé le contexte de la mission ainsi qu’étudié quelques outils susceptibles de
répondre à ses besoins, il est désormais temps d’aborder plus en détail les réalisations à
effectuées grâce aux outils retenus. Nous présenterons donc les différentes configurations de tous
nos outils retenus.
I. ARCHITECTURE DE DEPLOIEMENT
Figure 6: Architecture mise en place
Lorsque nous lançons un Build sous Jenkins, ce dernier télécharge le code source depuis
Git, le compile puis le scanne avec SonarQube et enfin envoi la livrable générée vers le serveur
de dépôt Apache Maven (Nexus). Il montre l’architecture complète qui assure le déploiement
technique et fonctionnel de notre solution.
Avec l’intégration continue nous souhaitons que les équipes détectent les problèmes le
plutôt possible, c’est-à-dire, dès que le code soit écrit et non pas à quelques jours de la livraison.


II. PRESENTATION DES OUTILS A UTILISER
La plateforme que nous allons mettre en place est composée d’un gestionnaire de source :
Git(GitHub), un serveur d’intégration continue : Jenkins, un serveur de qualité de code : Sonar,
un gestionnaire de dépôt : Nexus, et un environnement de tests Docker.
1. GESTIONNAIRE DE VERSION
Git(GitHub) est un logiciel de gestion de version. Git va nous permettre d’enregistrer les
différentes modifications effectuées sur un projet et de pouvoir retourner à une version
précédente du projet.
Derrière Git se cache un système de versionning décentralisé. Il existe un dépôt (de

l’anglais repository) dans lequel tous les changements sont incorporés et qui permet aux
utilisateurs d’y télécharger leurs propres copies de travail [12]. Ils disposent également d’un
dépôt complet qui comprend l’historique local sans qu’ils n’aient besoin d’une connexion
permanente au réseau. Par ailleurs, les modifications sont transférées rapidement dans le dépôt
principal. En conséquence, Git ne propose pas de système de verrouillage mais permet à tous les
utilisateurs de créer leurs propres branches qui seront ensuite téléchargées dans le dépôt
principal. Chaque utilisateur dispose par ailleurs des droits de lecture et d’écriture standards pour
tout le répertoire. S’il existe d’autres droits, d’autres répertoires principaux doivent alors être
définis. Chaque copie de travail est une sauvegarde individuelle du répertoire principal, ce qui
présente un avantage au cas où celui-ci tombe en panne ou est abîmé. Git ne définit que les
contenus des répertoires, c’est pourquoi les répertoires vides sont automatiquement supprimés.
GitHub est un service en ligne qui permet d’héberger des dépôts ou repo Git. C’est le plus grand
hébergeur de dépôts Git du monde [12].
Pour récapituler, et afin d’être bien clair sur ce point : Git est un logiciel de gestion de
version tandis que GitHub est un service en ligne d’hébergement de dépôts Git qui fait office de
serveur central pour ces dépôts.


2. SERVEUR DE QUALITE DE CODE
SonarQube est un outil d'analyse et de mesure de la qualité du code, qui permet de faire
un audit complet. Il analyse code source et puis génère un rapport détaillé contenant plusieurs
informations : nombre de lignes de code, pourcentage de couverture de code par les tests
unitaires et nombre de violations de règles de codage. SonarQube peut analyser plus de vingt-
cinq langages tels que JAVA, Objective-C, C#, PHP et tant d’autres.
Les tests réalisés par Sonar sont lancés par Jenkins automatiquement à chaque nouveau
cycle de vie. Sonar peut mettre les statuts du cycle en état « FAILURE » si la couverture du code
n’atteint pas le pourcentage spécifié. Sonar est lié avec un serveur de base de données MySQL.
3. GESTIONNAIRE DE DEPOT
Un gestionnaire de référentiels pour Apache Maven est un logiciel qui va permettre de

centraliser et de masquer toute la complexité liée à ces dépôts de bibliothèques logicielles [13].
Maven dispose de plusieurs référentiels à plusieurs niveaux. Le but du référentiel est de rendre
disponible aussi bien les plugins utilisés ou envisagés de l’être que les projets générés par
Maven. On peut bien sûr y installer des projets pour les utiliser (sans qu’ils ne soient générés par
Maven).
Cet outil sert à conserver les différentes versions générées par Jenkins après chaque
lancement en état « SUCCESS », qui sont par la suite téléchargées et exploitées par les autres
environnements tels que l’environnement production. Jenkins peut automatiser le déploiement
des artefacts sauvegardés dans Nexus, sous des serveurs applicatifs qui sont déployés dans des
containers docker légers.


III. INSTALLATION DES OUTILS
La fonction principale de tout outil d'Intégration Continue est de surveiller du code

source dans un outil de gestion de configuration, d'en extraire la dernière version et de la
construire dès que des modifications sont apportées. Donc, il vous faudra un outil de gestion de
configuration. Dans le cas qui nous occupe, nous utiliserons Git. Le code source de notre simple
projet se trouve hébergé sur GitHub.
1. INSTALLATION DE JAVA
La première chose que l’on va devoir installer sur notre machine est Java. Jenkins est une
application web Java web application, aussi l’on aura besoin au minimum du Java Runtime
Environment, ou JRE pour l'exécuter.
$ sudo apt-get install java
Pour vérifier notre version depuis la ligne de commande
«figure :
$ java version de java »
-version
Figure 7: Installation de Java
La figure 7 permet de constater que Java est bel et bien installé, et nous renseigne sur la
version


2. INSTALLATION DE GIT
Etant donné que nous utiliserons Git, il va falloir installer et configurer Git sur notre
machine. Vu que nous utilisons les distributions GNU/Linux la commande à exécuter est la
suivante :
$ sudo apt-get install git-core
Une fois cette opération réalisée, l’on vérifie que Git est correctement installé en
exécutant la commande suivante :
$ git --version
Figure 8: Installation de git
La figure 8 nous permet de constater que le serveur Git est installé et nous renseigne sur la
version.
a) Configuration d’un compte github
Ensuite, si l’on ne possède pas déjà un, l’on doit créer un compte GitHub. Cela est simple et
(pour notre usage du moins) gratuit. Dans notre cas, nous possédons déjà un compte donc sur
la page d'enregistrement de GitHub nous choisissons l'option “Sign in ” ; l’on a qu'à fournir le
nom d'utilisateur ou l’adresse e-mail, ainsi que le mot de passe.


Figure 9: Connexion à son compte GitHub
La figure 9 présente la connexion à notre compte GitHub
b) Configuration des clefs ssh
GitHub utilise les clefs SSH pour établir une connexion sécurisée entre l’ordinateur et les
serveurs GitHub. Les configurer n'est pas compliqué mais demande un peu d'effort :
heureusement, il existe des instructions claires et détaillées pour chaque système d'exploitation


c) Le dépôt des exemples
Comme nous l'avons mentionné plus tôt, tous les exemples de code de ce document sont
stockés sur GitHub, à l'URL suivante : [7] https://github.com/PreciousAmine/game-of-life. C'est
un dépôt public, il est accessible librement pour voir les codes sources en ligne. Une fois les
configurations terminées, l’on doit cloner une copie locale pour vérifier que tout est correctement
configuré. La commande à exécuter est la suivante (en remplaçant <username> avec notre
propre nom d'utilisateur GitHub):
$ git clone git@github.com:PreciuosAmine/game-of-life.git
Ceci va faire une copie du projet sur le disque local ;
Figure 10: Copie du projet en local
La figure 10 montre que nous disposons à présent d'une copie locale du projet que nous
pourrons construire et exécuter. Nous utiliserons ce projet plus tard pour déclencher des
changements dans le dépôt.
3. INSTALLATION DE JENKINS
L’installation se déroule comme suit : Tout d’abord, l’on ajoute la clé de référentiel au
système
$ wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key
| sudo apt-key add -


Une fois la clé ajoutée, le système reviendra avec OK. Ensuite, ajoutons l’adresse du dépôt de
paquets
$ sudo Debian
sh -cà celle
'echodu serveur
deb http://pkg.jenkins.io/debian-stable binary/
> /etc/apt/sources.list.d/jenkins.list'
Une fois les deux commandes saisies, nous exécuterons afin d’utiliser le nouveau
référentiel update apt
$ sudo apt update
Enfin, nous allons installer Jenkins et ses dépendances.
$ sudo apt install jenkins
Maintenant que Jenkins et ses dépendances sont en place, nous allons démarrer le serveur
Jenkins. Commençons Jenkins en utilisant systemctl
$ sudo systemctl start jenkins
Étant donné qu’il n’affiche pas la sortie d’état, nous utiliserons la commande pour
vérifier que Jenkins a démarré avec succès :systemctlstatus
$ sudo systemctl status jenkins
Tout s’étant bien passé, le début de la sortie d’état indique que le service est actif et
configuré pour démarrer au démarrage :
Maintenant que Jenkins est opérationnel, ajustons nos règles de pare-feu afin que nous
puissions y accéder à partir d’un navigateur Web pour terminer la configuration initiale.
Par défaut, Jenkins s’exécute sur le port. Nous ouvrirons ce port en utilisant :8080ufw


$ sudo ufw allow 8080
Vérifions l’état de Jenkins pour confirmer les nouvelles règles :ufw
$ sudo ufw status
Figure 11: Port de Jenkins autorisé
Grâce à la figure 10 nous pouvons remarquer que le trafic est autorisé à porter de n’importe
où.
Avec Jenkins installé et notre pare-feu configuré, nous pouvons terminer l’étape
d’installation et plonger dans la configuration de Jenkins.
a) Configuration de jenkins
Pour configurer notre installation, visitons Jenkins sur son port par défaut, en utilisant le nom
de domaine ou l’adresse IP de notre serveur, dans notre cas nous utiliserons l’adresse du serveur.


Figure 12: Déverrouiller Jenkins
La figure 12 montre l’écran Déverrouiller Jenkins, qui affiche l’emplacement du mot de

passe initial
Dans la fenêtre du terminal, nous utilisons la commande pour afficher le mot de passe :
$ sudo cat /var/lib/jenkins/secrets/initialAdminPassword
Copions le mot de passe alphanumérique du terminal et collons-le dans le champ Mot de passe

administrateur, puis cliquons sur Continuer.


Figure 13: Personnalisation de Jenkins
La figure 13 présente la possibilité d’installer des plugins suggérés ou de sélectionner

des plugins spécifiques
Nous allons cliquer sur l’option Installer les plugins suggérés, qui commencera
immédiatement le processus d’installation.
Figure 14: Installation des plugins
La figure 14 montre l’installation des différents plugins.


Figure 15: Création de l'utilisateur
La figure 15 montre la configuration du premier utilisateur administratif.
Il est possible d’ignorer cette étape et de continuer à utiliser le mot de passe initial que
nous avons utilisé ci-dessus, mais nous prendrons un moment pour créer l’utilisateur.


Figure 16: Confirmation de l'adresse
La figure 16 montre la configuration de l’adresse de notre instance
Nous recevons une page configuration d’instance qui nous demandera de confirmer

l’URL préférée pour notre instance Jenkins. Après avoir confirmé les informations appropriées,
cliquons sur Enregistrer et terminer.


Figure 17: Page prête pour jenkins
La figure 17 montre une page de confirmation confirmant que « Jenkins est prêt ! ».
Cliquons sur Démarrer l’utilisation de Jenkins pour visiter le tableau de bord principal de

Jenkins :
Figure 18: Page d'accueil de Jenkins
Cette figure 18, contient la liste des tâches (jobs en anglais), c’est à dire la liste des projets
ainsi que les différentes configurations établies. Elle permet de jeter un coup d’œil rapide sur
quelques éléments importants, à savoir :
 Une icône indiquant le résultat de la dernière compilation à l’aide de trois états : Success,
Unstable ou Failed.

 Une icône indiquant l’évolution des compilations récentes comme leur stabilité, les
résultats récents des tests, couverture de code etc.
 Les dates de dernière compilation réussie (ainsi que sa durée) et échouée.
 Une dernière icône permet directement de programmer une compilation.
b) Configuration des outils
Avant de commencer, nous devons faire un peu de configuration. Cliquons sur le lien Gérer
Jenkins sur la page d’accueil. Cela nous mènera à la page Gérer Jenkins, le guichet unique
central pour toute configuration Jenkins. À partir de cet écran, nous pouvons configurer notre
serveur Jenkins, installer et mettre à niveau des plugins, suivre la charge du système, gérer des
serveurs de build distribués, et plus encore. Cliquons simplement sur le lien Configuration du
système en haut de la liste.
Cela nous mène à l’écran de configuration principal de Jenkins De là, nous pouvons tout
configurer, de la configuration de la sécurité et des outils de construction aux serveurs de
messagerie, aux systèmes de contrôle de version et à l’intégration avec des logiciels tiers.
L’écran contient beaucoup d’informations, mais la plupart des champs contiennent des valeurs
par défaut sensibles, vous pouvez donc les ignorer en toute sécurité pour le moment.
i. Configuration de Maven
Notre exemple de projet utilise Maven, nous devrons donc d’abord installer et configurer
Maven. Jenkins fournit un excellent support prêt à l’emploi pour Maven. Défilons vers le bas
jusqu’à atteindre la section Maven dans l’écran Configurer le système.
Jenkins fournit plusieurs options lorsqu’il s’agit de configurer Maven. Nous allons laisser
Jenkins faire tout le travail difficile et télécharger Maven pour nous en ce qui concerne
l’installation de Maven. Pour choisir cette option, nous cochons simplement la case Installer
automatiquement. Jenkins téléchargera et installera Maven à partir du site Web Apache la
première fois qu’un travail de construction en aura besoin.

Choisissons simplement la version de Maven que nous voulons installer et Jenkins fera le
reste. Nous devons également donner un nom à notre version de Maven (appelée de manière
imaginative « Maven 2.2.1 » dans notre exemple), afin que nous puissons y faire référence dans
nos travaux de construction.
Figure 19: Configuration d'une installation Maven
La figure 19 présente la configuration d’une installation Maven
ii. Configuration du JDK
Une fois L’installation Maven terminée, nous devons également configurer une installation.
Nous demandons à Jenkins de télécharger le JDK à partir du site Web d’Oracle la première fois
qu’une tâche de génération l’exige. Ceci est similaire à la fonction d’installation automatique de
Maven - il suffit de choisir la version JDK nous avons besoin et Jenkins s’occupera de toute la
logistique. Toutefois, pour des raisons de licence, nous devons également cocher une case pour
indiquer que nous acceptons le contrat de licence du SDK Java.
Figure 20: Configuration d'une installation JDK


La figure 20 présente la configuration d’une installation JDK
Maintenant, allez en bas de l’écran et cliquons sur le bouton Enregistrer.
iii. Configuration des notifications
Un autre aspect important que nous configurons est la notification. Lorsqu’une version

Jenkins est interrompue et qu’elle fonctionne à nouveau, elle peut envoyer des messages
électroniques à l’équipe pour passer le mot. En utilisant des plugins, nous pouvez également
l’obtenir pour envoyer des messages instantanés ou des messages SMS, r ou informer les gens de
plusieurs autres manières. Tout dépend de ce qui fonctionne le mieux pour nous. La notification
par e-mail est assez facile à configurer si l’on connaît l’adresse de son serveur SMTP local.
Fournissons simplement cette valeur dans la section Notification par e-mail vers le bas de la page
de configuration principale.
iv. Configuration de Git
La dernière chose que nous devons configurer est de faire fonctionner Jenkins avec Git.
Jenkins est livré avec le support de Subversion et CVS prêt à l’emploi, mais nous devons
installer le plugin Jenkins Git. Tout d’abord, cliquons sur le lien Gérer Jenkins à gauche de
l’écran pour revenir à l’écran de configuration principal. Cliquons ensuite sur Gérer les plugins.
Cela ouvrira l’écran de configuration du plugin, où vous gérerons les fonctionnalités
supplémentaires que vous souhaitons installer sur notre serveur Jenkins. Nous avons quatre
onglets : Mises à jour, Disponible, Installé et Avancé.


Figure 21: Gestion des plugins dans Jenkins
La figure 21 présente la page de gestion de plugin
Une fois cela fait, Nous devons redémarrer Jenkins pour que les modifications prennent
effet. Pour ce faire, nous pouvons simplement cliquer sur le bouton « Redémarrer Jenkins
lorsqu’aucun travail n’est en cours d’exécution » affiché sur l’écran d’installation, ou bien arrêter
et redémarrer Jenkins à la main.
C’est tout ce dont nous avons besoin pour cette étape. Nous sommes prêts à configurer
notre premier travail de construction Jenkins.
4. INSTALLATION DE SONARQUBE
Le gestionnaire de la qualite de code sera installe via le menu Gerer les plugins. Une fois cela
fait, Nous devons redémarrer Jenkins pour que les modifications prennent effet. Pour ce faire,
nous pouvons simplement cliquer sur le bouton « Redémarrer Jenkins lorsqu’aucun travail n’est
en cours d’exécution » affiché sur l’écran d’installation, ou bien arrêter et redémarrer Jenkins à la
main.

5. INSTALLATION DE NEXUS
Pour installer ce logiciel, il y a deux possibilités, car il est distribué soit en version tout en
un "bundle", soit fourni sous la forme d'une application web empaquetée dans un fichier war
destiné à être déployé sur le serveur d'applications Tomcat, dont l'installation est donc un
prérequis [14].
Après avoir téléchargé Nexus, on le copie dans le répertoire /var/lib/tomcat6/webapps.

Tout d'abord, l’on crée le répertoire /usr/share/tomcat6/sonatype-work et lui attribue les droits
et groupes de l'utilisateur tomcat6. Puis on édite le fichier /etc/init. d/tomcat6 et vérifie que le
paramètre TOMCAT6_SECURITY a bien la valeur "no". L’on redémarre ensuiteTomcat via la
commande:
$ sudo /etc/init.d/tomcat6 restart
Dans notre navigateur internet, l’on accède à l'url http://localhost:8080/nexus.
Dans cette partie nous avions un objectif essentiel de montrer comment notre système
devra être mis en place, les outils utilisés parmi lesquels Git, Maven, Jenkins, ainsi que leur
installation. Maintenant que les différents outils ont été présentés, nous passons à la
démonstration.


CHAPITRE IV : PRESENTATION DES RESULTATS
Préambule
Une fois qu’une solution est analysée, il faudrait la concevoir et la déployée. Cette partie de notre
document concerne l’utilisation des outils nécessaires pour notre plate-forme.
Vue d’ensemble
I. CONFIGURATION DU PROJET
II. RESULTATS DES TESTS


Le document de réalisation est celui qui contient toutes les informations relatives à
l’implémentation actuelle du projet. Il répond à la question « comment utiliser cette application
qui est devant nous ? ». Il est donc crucial pour nous de présenter les différentes opérations
variées de notre système.
I. CONFIGURATION DU PROJET
Notre application est une implémentation Java simple du « Game of Life » de John
Conway (voir [3] http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life). Le Jeu de la Vie
est un jeu mathématique qui se déroule sur une grille bidimensionnelle de cellules, que nous
appellerons l’Univers. Chaque cellule peut être vivante ou morte. Les cellules interagissent avec
leurs voisines directes pour déterminer si elles vivront ou mourront dans la prochaine génération
de cellules. Pour chaque nouvelle génération de cellules, les règles suivantes sont appliquées :
 Toute cellule vivante avec moins de deux voisins vivants meurt de sous-population.
 Toute cellule vivante avec plus de trois voisins vivants meurt de surpeuplement.
 Toute cellule vivante avec deux ou trois voisins vivants vit jusqu’à la génération suivante.
 Toute cellule morte avec exactement trois voisins vivants devient une cellule vivante.
Notre application est un module Java, qui implémente la logique métier de base du Jeu de la
Vie.
Pour notre premier travail de build, nous allons rester simples: nous allons simplement
compiler et tester notre exemple d’application.Dans ce cas, nous l’appelons game-of-life, car ce
sera la version CI par défaut pour notre projet Game of Life.


Figure 22: Dire à Jenkins où trouver le code source
La figure 22 indique à Jenkins où trouver le code. Pour ce projet, nous obtiendrons le

code source du référentiel GitHub que nous avons configuré précédemment. Sur l’écran Jenkins,
choisissons « Git » et entrons l’URL du référentiel que nous avons définie dans le dépôt des
exemples.
Une fois que nous avons dit à Jenkins où trouver le code source de notre application,
nous devons lui dire à quelle fréquence il doit vérifier les mises à jour. Nous voulons que Jenkins
surveille le référentiel et démarre un build chaque fois que des modifications ont été validées. Il
s’agit d’un moyen courant de configurer une tâche de génération dans un contexte d’intégration
continue, car elle fournit un retour rapide en cas d’échec de la génération.
Une autre chose que nous pouvons faire est d’archiver les résultats de notre build. Jenkins
peut stocker une copie des artefacts binaires générés par notre build.
Maintenant, nous avons terminé, cliquons sur le bouton Enregistrer en bas de l’écran. Notre
travail de construction devrait maintenant être prêt à s’exécuter. Alors voyons-le en action!


II. RESULTATS
Une fois enregistré notre nouvelle tâche de génération, Jenkins affiche la page d’accueil de cette
tâche. C’est là que Jenkins affiche des détails sur les derniers résultats de build et l’historique de
build.
Figure 23: Première tâche de construction en cours d'exécution
Après une minute environ, la génération démarre automatiquement : l’on peut voir la barre de
progression en bandes dans la section Historique de génération dans le coin inférieur gauche ;
mais on peut également déclencher la génération manuellement à l’aide du bouton Générer
maintenant.


Figure 24: Premier build réussi
La figure 30 présente l’historique des constructions
La version figure également fièrement sur la page d’accueil de notre serveur

Jenkins. Cette page affiche un résumé de toutes nos tâches de construction, y compris l’état
actuel de la construction et l’état général de santé de chacune de nos constructions. Il indique
quand chaque build s’est exécutée avec succès pour la dernière fois, et quand elle a échoué pour
la dernière fois, ainsi que le résultat de la dernière build.
Figure 25: Tableau de bord de Jenkins


La figure 31 présent le tableau de bord de Jenkins
Lorsque la construction est terminée, la boule dans la zone Historique de construction

devient bleue. Cela signifie que la construction a été un succès. Les échecs de construction sont
généralement indiqués par une boule rouge.
Alors faisons un changement. L’idée est d’introduire un changement de code qui entraînera
l’échec des tests unitaires. Donc, dans cet exemple, nous allons, contre toutes les meilleures
pratiques, simplement modifier le code de l’application directement.
Figure 26: Construction ayant échouée
Revenons maintenant à la page Web de Jenkins. Après environ une minute, une nouvelle
construction à démarrer et à échouer. En fait, il y a plusieurs autres endroits qui sont affectés par
ce changement, et les tests de régression liés à ces fonctionnalités échouent maintenant. Sur la
page d’accueil de la tâche de génération, nous voyons une boule rouge inquiétante dans
l’historique de génération avec: cela indique que la dernière génération a échoué.


Figure 27: Historique des tests échoués
Si nous cliquons sur la nouvelle entrée de l’historique des builds, Jenkins nous donnera
plus de détails sur ce qui s’est mal passé. Jenkins nous dit qu’il y a eu 61 nouveaux échecs de test
dans cette version.
Figure 28: Liste de tous les tests cassés
Ce qui peut être vu en un coup d’œil dans le graphique de tendance des résultats des
tests ; le rouge indique les échecs de test. L’on peut même voir quels tests échouent et depuis
combien de temps ils ont été cassés.
Pour simplifier les choses, nous allons simplement revenir sur nos modifications et
réengager le code dans son état d’origine (les utilisateurs finaux ont juste changé d’avis sur les

astérisques, de toute façon). Annulons donc simplement les modifications que nous avons
apportées à la classe. Lorsque nous avons effectué cette opération, validons à nouveau nos
modifications :
Figure 29: La construction est de retour à la normale
Maintenant, la construction est réparée.


Figure 30: Détails d'un test réussi
Jenkins affiche les détails réels des tests à savoir l’utilisateur qui a lancé la construction,
et le statut de celui-ci, ce qui est d’une grande aide.
Au cours de ce dernier chapitre, nous avons implémenté notre solution qui consiste en la
mise en place d’une plateforme d’intégration continue, et qui a été déroulé sur deux étapes : une
étape technique pour la configuration de l’environnement, et une étape fonctionnelle pour la
configuration des composants


CONCLUSION GENERALE
Ce travail réalisé au sein de la société ICCSOFT S.A consistait à la mise en place d’un
système d’automatisation des tests continue. Nous avons décomposé notre travail en quatre
modules, allant de la présentation des architectures déjà en place jusqu’à la présentation de notre
système mis en place.
Le choix de la technologie de Jenkins met le déploiement de notre solution très rapide

grâce à son outil. La rapidité de déploiement de notre architecture présente une grande
importance dans notre projet, en effet, nous pouvons tester n’importe quel logiciel en mode de
développement dans un intervalle de temps très court.
Le déploiement de la plateforme, ainsi que les tests que nous avons fait pour le produit
game of life sont tous réalisés avec succès. Ce stage nous a beaucoup apporté, tant sur le plan
personnel que professionnel. Il nous a permis de mieux comprendre et d’appréhender
l’organisation d’une entreprise, ses contraintes et ses missions. Ceci présente pour nous une
opportunité pour mieux comprendre le concept du DevOps.
Il est à noter qu’afin de continuer à garantir la production d’un code de qualité croissante,
l’utilisation d’un environnement de test en dehors de ceux utilisés habituellement pourrait être
envisagée afin d’assembler les codes peu importe l’environnement de travail. Ceux-ci
amélioreront non seulement notre projet en termes de fonctionnalités, mais aussi en terme
d’efficacité permettant un système encore plus fiable.
REFERENCES BIBLIOGRAGRAPHIQUES
[1] Geridoo, Intégration continue. http://jfdidgeridoo.wordpress.com/2011/04/04/lintegration-
continue/.Consulté le 01/04/2022

[2] Wikipedia, Game of life de John Conway. http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life

consulté le 01/04//2022
[3] Projet utilisé pour les tests https://github.com/PreciousAmine/game-of-life
[4] Wikipedia, Processus d’intégration continue.
https://wiki.nci.nih.gov/display/Suite/The+Suite+2.0+Continuous+Integration+Architecture. Consulté
le 10/04/2022
[5] GitHub Pages, Guide complet de Jenkins. http://jenkins-le-guide-complet.github.io/html/. Consulté le

11/04/2022
[6] Betterscm, Comparaison entre les outils de gestion et contrôle de versions.
http://betterscm.shlomifish.org/comparison/comparison.html. Consulté le 20/04/2022
[7] Pourquoi Junit http://www-igm.univ-mlv.fr/~dr/XPOSE2003/JUnit_tour/ Consulté le 26/04/2022
[8] Virtualisation avec Docker http://blog.nicolargo.com/2014/06/virtualisation-legere-docker.html
Consulté le 30/04/2022
[9] Documentation sur JUnit .https://junit.org Consulté le 20/05/2022
[10] Wikipedia, wikipedia.org/wiki/Single_Source_of_Truth Consulté le 22/04/2022
[11] Récupéré sur : https://jack-vanlightly.com/blog/2017/2/19/sonarqube-hell-yes-sonarlint-no-thanks
consulté le 11/05/2022
[12] Pierre Giraud, Présentation de Git Présentation de Git et de GitHub - Pierre Giraud (pierre-
giraud.com) Consulté le 12/04/2022
[13] Présentation de Apache Maven Apache Maven - Maîtrisez l'infrastructure d'un projet Java EE - Les
gestionnaires de référentiels Maven | Editions ENI (editions-eni.fr) Consulté le 20/04/2022
[14] Wikipédia, Installation de Nexus nexus [Wiki ubuntu-fr] Consulté le 30/04/2022
[15] Bing Cartes, Localisation de ICCSOFT localisation de iccsoft yaounde - Bing Cartes Consulté le
30/03/2022
TABLE DES MATIERES
DEDICACE..................................................................................................................................................i

REMERCIEMENTS...................................................................................................................................ii
SOMMAIRE..............................................................................................................................................iii
LISTE DES FIGURES................................................................................................................................v
LISTE DES TABLEAUX..........................................................................................................................vi
LISTE DES ABREVIATIONS.................................................................................................................vii
RESUME.................................................................................................................................................viii
ABSTRACT...............................................................................................................................................ix
INTRODUCTION GENERALE.................................................................................................................1
CHAPITRE I : ANALYSE DE L’EXISTANT............................................................................................2
I. PRESENTATION DE L’ENTREPRISE.........................................................................................3
1. HISTOIRE...................................................................................................................................3
2. MISSIONS..................................................................................................................................3
3. ACTIVITÉS.................................................................................................................................3
4. LOCALISATION GÉOGRAPHIQUE........................................................................................4
II. PROCEDURE DE DEVELOPPEMENT.........................................................................................5
III. LIMITES.....................................................................................................................................6
IV. L’INTEGRATION CONTINUE.................................................................................................7
1. DEFINITION...............................................................................................................................7
2. FONCTIONNEMENT DE L’INTEGRATION CONTINUE......................................................9
3. ETAPES DE L’INTEGRATION CONTINUE..........................................................................10
4. DIFFERENTS COMPOSANTS D’UNE PLATEFORME D’IC...............................................11
CHAPITRE II : ETAT DE L’ART............................................................................................................13
I. CRITERES DE COMPARAISON................................................................................................14
II. SOLUTIONS EXISTANTES........................................................................................................14
1. JENKINS...................................................................................................................................14
2. TRAVIS.....................................................................................................................................15
3. BAMBOO..................................................................................................................................15
III. TABLEAU RECAPITULATIF.................................................................................................16
CHAPITRE III : DEPLOIEMENT DE LA SOLUTION...........................................................................17
I. ARCHITECTURE DE DEPLOIEMENT......................................................................................18
II. PRESENTATION DES OUTILS A UTILISER............................................................................19
1. GESTIONNAIRE DE VERSION..............................................................................................19
2. SERVEUR DE QUALITE DE CODE.......................................................................................20
3. GESTIONNAIRE DE DEPOT..................................................................................................20

III. INSTALLATION DES OUTILS...............................................................................................21

1. INSTALLATION DE JAVA.....................................................................................................21
2. INSTALLATION DE GIT.........................................................................................................22
a) Configuration d’un compte github.........................................................................................22
b) Configuration des clefs ssh....................................................................................................23
c) Le dépôt des exemples...........................................................................................................24
3. INSTALLATION DE JENKINS...............................................................................................24
a) Configuration de jenkins........................................................................................................26
b) Configuration des outils.........................................................................................................33
i. Configuration de Maven....................................................................................................34
ii. Configuration du JDK........................................................................................................35
iii. Configuration des notifications......................................................................................36
iv. Configuration de Git......................................................................................................36
4. INSTALLATION DE SONARQUBE.......................................................................................37
5. INSTALLATION DE NEXUS..................................................................................................38
CHAPITRE IV : PRESENTATION DES RESULTATS..........................................................................39
I. PREMIER TRAVAIL DE CONSTRUCTION JENKINS.....................Erreur ! Signet non défini.
II. TRAVAIL DE CONSTRUCTION EN ACTION.................................Erreur ! Signet non défini.
CONCLUSION GENERALE....................................................................................................................52
REFERENCES BIBLIOGRAGRAPHIQUES...........................................................................................53
TABLE DES MATIERES.........................................................................................................................54



Rapport 2

Transféré par

Informations du document

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

Rapport 2

Transféré par

Droits d'auteur :

Formats disponibles

MISE EN PLACE D’UN SYSTEME D’INTEGRATION CONTINUE

A TOUS CEUX QUI ME SONT

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale i

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale ii

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale iii

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale iv

LISTE DES FIGURES

Figure 1:localisation de ICCSOFT S.A---------------------------------------------------------------------------------------- 4

Université Protestante d’Afrique Centrale v

Figure 38: Détails d'un test réussi------------------------------------------------------------------------------------------ 51

LISTE DES TABLEAUX

Tableau 1: Comparaison des serveurs d'intégration continue----------------------------------------------------16

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale vi

LISTE DES ABREVIATIONS

 CCEC : Caisse Camerounaise d’Epargne et de Crédit

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale vii

Mots clés : Intégration continue, test, automatisation, assemblage de code.

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale viii

Keywords: Continuous integration, testing, automation, code assembly.

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale ix

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale 1

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale 2

Université Protestante d’Afrique Centrale 3

 Suivi, métier, support client

Figure 1:localisation de ICCSOFT S.A

ICCSOFT se situe à la montée Anne-Rouge, à côté de la CCEC

II. PROCEDURE DE DEVELOPPEMENT

Figure 3: Avant la mise en place de l'intégration continue [4]

Université Protestante d’Afrique Centrale 4

Figure 4: Architecture existante

Nous pouvons extraire ces limites de l’architecture existante :

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale 5

IV. L’INTEGRATION CONTINUE

L’intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant

Généralement, l’intégration classique consiste à assembler à la fin du projet toutes les

Université Protestante d’Afrique Centrale 6

L’intégration continue s’impose comme une solution incontournable. En effet, sans IC le

Afin d’implémenter l’intégration continue, certains prérequis sont indispensables [5].

Le deuxième prérequis est l’automatisation du processus de build. Il faut être en mesure de

Université Protestante d’Afrique Centrale 7

2. FONCTIONNEMENT DE L’INTEGRATION CONTINUE

 La compilation automatique du code et de ses dernières modifications,

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale 8

3. ETAPES DE L’INTEGRATION CONTINUE

L’utilisation du schéma qui suit permet de comprendre et d’expliquer plus en détail ce

Figure 5: Etapes d’une intégration continue [16]

La présente figure nous montre les étapes d’une intégration continue.

Université Protestante d’Afrique Centrale 9

4. DIFFERENTS COMPOSANTS D’UNE PLATEFORME D’IC

TCHAYA TCHANGA GOODNESS

Université Protestante d’Afrique Centrale 10

TCHAYA TCHANGA GOODNESS