Ecole sup´erieure

des sciences appliqu

priv´e
´ees de
et
mangement

PROJET FIN D’E´TUDES

4 `eme ann´ee cycle ing´enieur

Sp´ecialit´e : g´enie logiciel

R´ealis´e par
WIEM JEMAI

Mise en place d’une plateforme DEVOPS pour

l’automatisation des tests

R´ealis´e au sein de l’entreprise

Soutenue le 09-10-2021 devant le jury compos´e de :

Pr´esident Mme/
: M
Rapporteur Mme/
: M
Encadreur acad M. Kamel BEN RHOUMA
´emique :

Session : 2020-2021
 Ecole sup´erieure
des sciences appliqu
priv´e
´ees de
et
mangement

PROJET FIN D’E´TUDES

4 `eme ann´ee cycle ing´enieur

Sp´ecialit´e : g´enie logiciel

R´ealis´e par
WIEM JEMAI

Mise en place d’une plateforme DEVOPS pour

l’automatisation des tests

R´ealis´e au sein de l’entreprise

Autorisation de soumettre le rapport du projet PFE

Encadreur de
Encadreur acad´emique
l’entreprise : Date :
: Date :
Signature :
Signature :
 Remerciem

Avant de commencer la pr´esentation de ce travail, je profite de

l’occasion pour remer- cier toutes les personnes qui ont contribu´e de pr`es
ou de loin a` la r´ealisation de ce projet.

Mes remerciements vont aussi `a tous mes professeurs, enseignantes et toutes

les personnes qui m’ont soutenu jusqu’au bout, et qui n’ont pas cess´e
de me donner des conseils tr`es importants en signe de reconnaissance.
Je remercie mon encadrant acad´emique monsieur Kamel BEN RHOUMA, et
mon enca- drant entreprise Mr BAHRI Saifeddine, pour son soutien
continu durant la p´eriode de mon projet. Grˆace a` sa confiance j’ai pu
accomplir la totalit´e de mes missions. Il fut d’une aide pr´ecieuse dans les
moments les plus d´elicats.

Je remercie ´egalement toute l’´equipe de la soci´et´e BILOG pour

leur accueil, et pour me fournir un excellent cadre de travail.

Wiem JEMAI

i
 R´esum´e /

Ce pr´esent rapport est le fruit d’un travail acharn´e pendant 6

mois au sein de la soci´et´e BILOG afin de r´ealiser le projet de fin
d’´etude pour l’obtention du Diplˆome Na- tional d’Ing´enieur en g´enie
logiciel.

Il consiste de la mise en place d’une plateforme DevOps. Cette plateforme

devrait au- tomatiser toutes les ´etapes du cycle de vie d’un logiciel jusqu’`a
le d´eploiement en produc- tion et faciliter la communication et le partage
d’informtion entre les membres de l’´equipe.

Tout au long de ce rapport, nous d´ecrirons les diff´erentes ´etapes de

la mise en œuvre de notre plateforme, en commen¸cant par la collecte des
exigences jusqu’`a la mise en pro- duction.

This report is the result of hard work of 6 months within BILOG In order
to carry out the end of studies project to obtain the National Diploma in
software engineering.

It consists of setting up a DevOps platform. This platform should automate

all the steps in the life cycle of a software till the deployment in production
and facilitate communica- tion and sharing information between the team
members.

Throughout this report, we will describe the different steps of the

implementation of our platform, starting with the collection of
requirements until production.

i
 Table des

Introduction g´en´erale 1

1 E´ tude pr´eliminaire 2
1.1 Introduction............................................................................................................2
1.2 Organisme d’accueil...........................................................................................2
1.2.1 Pr´esentation de l’organisme d’accueil .............................................3
1.2.2 Secteur d’activit´e ...................................................................................3
1.3 Contexte g´en´eral ...............................................................................................3
1.3.1 Introduction a` l’assurance qualit´e ...................................................4
1.3.2 Tests logiciel..............................................................................................4
1.3.3 Les bugs......................................................................................................5
1.4 Etude de l’existant...............................................................................................6
1.4.1 E´ tat actuel de la soci´et´e ..................................................................6
1.4.2 Probl´ematique ..........................................................................................7
1.4.3 Solution et architecture du projet....................................................8
1.5 M´ethodologies de travail ..................................................................................9
1.5.1 Avantages de la m´ethode agile Scrum ............................................9
1.5.2 Ce qui change avec Scrum...............................................................10
1.5.3 L’´equipe scrum ......................................................................................10
1.5.4 Le sprint....................................................................................................11
1.5.5 Les artefacts............................................................................................11
1.5.6 Les ´ev`enements scrum .....................................................................11
1.6 M´ethodologie de conception ..........................................................................12
1.7 Environnement de travail..............................................................................13
1.7.1 Choix technologiques..........................................................................13
1.7.2 Choix logiciel..........................................................................................15
1.8 Etude comparative............................................................................................17
1.8.1 Gestionnaire de version : Git vs SVN..........................................18
1.8.2 Serveur d’orchestration.....................................................................18
1.8.3 Sonarqube vs SonarLint.....................................................................18
1.8.4 Conteneurs vs Machines virtuelles...............................................19
1.9 Conclusion............................................................................................................20

2 Analyse et sp´ecification des besoins 21

2.1 Introduction.........................................................................................................21
2.2 Sp´ecifications des Besoins .............................................................................21
2.2.1 Besoins Fonctionnels...........................................................................21
2.2.2 Besoins Non Fonctionnels.................................................................22

i
 Table des
Table des mati`eres

2.2.3 Identification des acteurs du syst`eme informatique ..................22

2.3 Diagramme des cas d’utilisation globale................................................23
2.4 Le pilotage du projet par Scrum................................................................24
2.4.1 D´ecoupage du projet ...........................................................................24
2.4.2 Product Backlog.....................................................................................25
2.4.3 Gestion de Projet...................................................................................26
2.5 Conclusion............................................................................................................27

3 Sprint 1 - D´eveloppement des tests automatis´es et installation des outils 28

3.1 Introduction.........................................................................................................28
3.2 Sp´ecification des besoins .................................................................................28
3.3 Tests automatis´es ..............................................................................................29
3.3.1 Diagramme de Cas d’utilisation ”Fiche signal´etique” .............29
3.3.2 Tests fonctionnels.................................................................................29
3.4 Installation des outils......................................................................................31
3.4.1 Jenkins.......................................................................................................32
3.4.2 SonarQube et Sonar Scan.................................................................32
3.4.3 Docker........................................................................................................32
3.5 Conclusion............................................................................................................33

4 Sprint 2 - Configuration des outils 34

4.1 Introduction.........................................................................................................34
4.2 Sp´ecification des besoins ................................................................................34
4.3 Diagramme de Cas d’utilisation..................................................................35
4.4 Diagramme de d´eploiement ............................................................................36
4.5 Conception............................................................................................................37
4.6 R´ealisation : mettre en place le pipeline ..................................................38
4.6.1 GitLab & Jenkins...................................................................................38
4.6.2 SonarQube & jenkins..........................................................................42
4.6.3 SonarQube & Redmine.......................................................................44
4.6.4 Jenkins & Zulip......................................................................................45
4.6.5 Jenkins & Selenium..............................................................................46
4.6.6 Ticket redmine.......................................................................................47
4.6.7 D´epoiement du projet .........................................................................47
4.7 Conclusion............................................................................................................48

Conclusion & Perspectives 49

Webographie 50

i
 Table des

iv

v
 Table des figures

1.1 Organisme d’accueil BILOG............................................................................2

1.2 La chaine de l’erreur[5]....................................................................................5
1.3 Architecture du projet.......................................................................................8
1.4 Methode-scrum [6]............................................................................................10
1.5 Les ´ev´enements scrum [7] ............................................................................12
1.6 .Net..........................................................................................................................13
1.7 Selenium WebDriver........................................................................................14
1.8 NUnit......................................................................................................................14
1.9 Visual studio........................................................................................................15
1.10StarUML................................................................................................................15
1.11Jenkins....................................................................................................................16
1.12SonarQube............................................................................................................16
1.13Redmine.................................................................................................................16
1.14Zulip........................................................................................................................17
1.15Docker....................................................................................................................17
1.16VMs vs Docker[10]............................................................................................19

2.1 Acteurs syst`eme ................................................................................................22

2.2 Diagramme de cas d’utilisation globale..................................................23
2.3 Exemple de sch´ema de d´ecoupage en releases [9] ...............................24
2.4 D´ecoupage du projet ........................................................................................25
2.5 Planification du projet.....................................................................................26
2.6 Tableau scrum....................................................................................................26

3.1 Fiche signal´etique .............................................................................................29

3.2 NUnit Framework et de l’adaptateur de test NUnit..........................30
3.3 Selenium WebDriver........................................................................................30
3.4 R´esultat test selenium ....................................................................................31
3.5 Installation Jenkins...........................................................................................32
3.6 Installation SonarQube...................................................................................32
3.7 Installation Docker............................................................................................33

4.1 Diagramme de cas d’utilisation du ingenieur QA................................35

4.2 Diagramme de cas d’utilisation du d´eveloppeur ....................................35
4.3 Diagramme de cas d’utilisation du l’invit´e ..............................................36
4.4 Diagramme de d´eploiement ............................................................................36
4.5 Diagramme de s´equence du syst´eme ........................................................37
4.6 Cr´eation projet GITLAB ................................................................................38
4.7 Uploader le projet.............................................................................................39

v
 Table des figures

4.8 Cr´eation projet Jenkins ...................................................................................39

4.9 G´eneration d’un token .....................................................................................40
4.10Liaison entre jenkins et GitLab...................................................................40
4.11V´erification ..........................................................................................................41
4.12Environnement de build.................................................................................41
4.13Parametrage du projet SonarQube............................................................42
4.14Projet SonarQube..............................................................................................42
4.15SonarQube avec jenkins.................................................................................43
4.16Rapport SonarQube..........................................................................................43
4.17Tickets....................................................................................................................44
4.18Liaison SonarQube et Redmine...................................................................44
4.19User Story.............................................................................................................45
4.20Ticket Redmine...................................................................................................45
4.21Liaison Jenkins et Redmine...........................................................................46
4.22Message Zulip.....................................................................................................46
4.23Selenium Jenkins..............................................................................................47
4.24Cr´eation des tickets de bugs ........................................................................47
4.25Deploiement du projet sur Docker.............................................................48

vi
 Introduction g´en´erale

De nos jours, les technologies de d´eveloppement logiciel ´evoluent et

progressent constam- ment, et cela augmente les exigences en termes de
temps, complexit´e et efficacit´e.
L’automatisation des ´etapes dans le cycle de vie d’un projet est devenue
imp´erative, ainsi que la convergence entre les phases de d´eveloppement,
test et exploitation, pour avoir a` la fin une livraison continue et
collaboration id´eale entre les membres de l’´equipe de travail.

Le DevOps est la pratique la plus courante pour avoir une continuit´e

dans les phases d’int´egration, livraison et d´eploiement ainsi que la
gestion de configuration a` l’aide des outils interfc´es entre eux.

Tester votre application est une partie fondamentale du processus de d

´eveloppement d’ap- plication, le test de l’application est la phase qui
garantit la qualit´e et la fiabilit´e de votre application.

Dans ce cadre le pr´esent projet vise a` cr´eer un pipeline de livraison

continue en int´egrant toute une plateforme de DevOps qui renferme un
ensemble des outils pour une automati- sation compl`ete. Ce projet s’est d
´eroul´e au sein de l’entreprise BILOG, qui vise `a ´etudier plusieurs probl
´ematiques.

Le pr´esent rapport d´ecrit l’essentiel du travail r´ealis´e durant de ce

projet, il est orga- nis´e en 4 chapitres :
— E´ tude pr´eliminaire
— Analyse et sp´ecification des besoins
— Sprint 1 - D´eveloppement des tests automatis´es et installation des outils
— Sprint 2 - Configuration des outils
Nous terminerons notre rapport par une conclusion g´en´erale qui r´esume
notre travail et expose quelques perspectives pour notre plateforme.

1
1 E´ tude pr´eliminaire

1.1 Introduction
L’´etude pr´eliminaire constitue une ´etape primordiale a` la r´ealisation
d’une application. En effet, elle permet d’analyser, d’´evaluer et de critiquer
le fonctionnement habituel, tout en ´elaborant la liste des solutions possibles.
Elle fera donc l’int´erˆet du premier chapitre qui sera consacr´e `a la pr
´esentation de l’orga- nisme d’accueil, la pr´esentation du projet, l’´etude
de l’existant ainsi que la d´efinition de la m´ethode de d´eveloppement et
ses piliers.

1.2 Organisme d’accueil

Ce projet a ´et´e r´ealis´e au sein de l’entreprise bilog.

FIGURE 1.1 – Organisme d’accueil BILOG

2
 1.3. Contexte g

1.2.1 Pr´esentation de l’organisme d’accueil

Bilog est une entreprise fran¸caise de services en ing´enierie
informatique bas´ee a` Ver- sailles, sp´ecialis´ee dans le d´eveloppement
logiciel au forfait. Fond´ee en 2002, elle propose des offres de d
´eveloppements sp´ecifiques, aux clients Francais.[1]
Le centre de production, bas´e a` Tunis il m’a offert l’opportunit´e de
passer mon projet de fin d’´etudes, de participer aux diff`erentes formations
et de travailler sur l’un des projets client les plus importants.
T´el´ephone : 0033130216392.
Fax : 0033955737341
Site WEB : www.bilog.fr

1.2.2 Secteur d’activit´e

Dot´e d’une forte culture technique, Bilog met toute son expertise a` la
disposition de ses clients, sur site ou `a distance, et prend la
responsabilit´e globale de son projet. Les
´equipes d’ing´enieurs et de qualiticiens interviennent sur toutes les
techniques en offrant les services suivants :

— D´eveloppement au forfait
— Contrˆole qualit´e
— Audit de code source
— Applications mobile
— Cloud computing
— Infog´erance
— Portage d’applications
— Gestion industrielle
— Infog´erance
— Portage d’applications
— Gestion industrielle
— Secteur m´edical
— Tierce maintenance applicative
— Assistance utilisateurs
— Assistance technique

1.3 Contexte g´en´eral

Actuellement, les entreprises informatiques commencent a` prendre
conscience de l’im- portance de la phase de test dans la gestion de projet, qui
3
 1.3. Contexte g
se caract´erise par une strat´egie d’acceptation des fonctions et met en
œuvre cette strat´egie pour s’assurer que le projet conserve la bonne
direction.

4
 1.3. Contexte g

1.3.1 Introduction `a l’assurance qualit´e

La planification de tests commence par la conception de l’application ou sa
mise en œuvre. Cependant, les activit´es de tests et de v´erification de
la qualit´e ne se limitent pas au test du code d’application : la v
´erification de la qualit´e doit commencer par la validation de sp
´ecification.

De nombreuses d´efinitions sont possibles et valables pour la qualit´e,

elles repr´esentent des points de vue l´eg`erement diff´erents sur ce m
´etier. La norme internationale ISO 9001 indique qu’il s’agit du ”degr´e
auquel un ensemble de caract´eristiques remplit les exi- gences”.[2] D
´efinition semblable pour Philip B. Crosby : elle permet de ”se conformer aux
exigences des utilisateurs”.[3] IBM voit ”la qualit´e telle qu’elle est d´efinie
par la client`ele”[4] pour son enti`ere satisfaction.

Ce sont donc des d´efinitions g´en´eralistes qui indiquent que le m´etier

de la qualit´e lo- gicielle a pour but de s’assurer que le logiciel est
conforme `a ses sp´ecifications et aux attentes du client ou des
utilisateurs finaux.

1.3.2 Tests logiciel

Le test logiciel est une m´ethode de v´erification dynamique con¸cue
pour garantir le logiciel qui pr´esente en effet les caract´eristiques requises
par le contexte de son utilisation. Toute fabrication de produit suit les
´etapes suivantes :
1. Conception
2. R´ealisation
3. Test
Un test d´esigne une proc´edure de v´erification partielle d’un syst`eme. Son
objectif principal est d’identifier un nombre maximum de comportements
probl´ematiques du logiciel.
C’est une activit´e qui fait partie du processus de d´eveloppement.

Les types de tests

Ce mod`ele est repris par le r´ef´erentiel ISTQB (International Software

Testing Qualifications Board) et depuis longtemps il est consid´er´e comme le mod`ele qui
permet de mieux assurer la qualit´e du produit final. Du point de vue du testeur
certifi´e ISTQB, l’agilit´e et le DevOps ne font que raccourcir le cycle, mais les
activit´es restent les mˆemes. Elles sont faites plus r´eguli`erement, avec des d´elais
plus courts. Avec cette approche on peut pr´esenter un tableau qui liste les grandes
activit´es d’un projet agile, puis proposer en face de chaque activit´e ce que l’ISTQB

5
 1.3. Contexte g
recommande comme activit´e de validation et de v´erification. [6]

6
 1.3. Contexte g

Activit´e ISTQB
Plan Revue de sp´ecification (User Stories) Testabilit´e / Coh
´erence.
Tests statiques : revue de code, qualim´etrie
Code
Tests unitaires.
Build Tests d’int´egration.
Test Tests syst`emes.
Release Tests d’acceptation.
Deploy, Operate Tests de non-r´egression.

1.3.3 Les bugs

Un bug logiciel est une erreur, une faille ou un d´efaut dans un programme ou un
syst`eme informatique qui provoque un r´esultat incorrect ou un comportement inattendu.

Le terme BUG est utilis´e pour d´esigner : Erreur → De´f aut → Def aillance → Anomalie.

FIGURE 1.2 – La chaine de l’erreur[5]

Une Erreur : Action humaine produisant un r´esultat incorrect.[5]

Un D´efaut : Une imperfection dans un composant ou un syst`eme qui peut conduire `a
ce qu’un compo- sant ou un syst`eme n’ex´ecute pas les fonctions requises, par exemple
une instruction ou une d´efinition de
donn´ees incorrecte.[5]
Une D´efaillance : E´ cart constat´e du composant ou syst`eme par rapport au
livrable, au service ou au r´esultat attendu. Incapacit´e d’un syst`eme ou d’un
composant d’ex´ecuter une fonction requise dans les limites sp´ecifi´ees.[5]
Une Anomalie : toute condition qui d´evie des attentes bas´ees sur les exigences
de sp´ecifications, do- cuments de conception, documents utilisateurs, standards etc,
ou des perceptions ou exp´eriences de quelqu’un.[5]

7
 1.4. Etude de

Gravit´e des anomalies

Le tableau suivant illustre plusieurs niveaux d’exception :

Gravit´e Description
Des anomalies entraˆıneront l’arrˆet complet du syst`eme
Bloquante ou des com-
posants fonctionnels n´ecessaires.
Une fonctionnalit´e indispensable est partiellement inop
Majeure ´erante sans
op´erer des outils de blocage. L’application peut
continuer.
Panne fonctionnelle inutile sans blocager du
Mineure fonctionnement de
l’outil.

Les sources des bugs

Voici quelques exemples de sources des bugs logiciels :

— Le facteur HUMAIN (Le manque de connaissances et de comp´etences professionnelles).

— L’´echec de la communication (Une incompr´ehension du besoin et des exigences).

— Des temps de d´eveloppement trop courts

— Une mauvaise logique de conception

1.4 Etude de l’existant

Assurer la qualit´e des syst`emes op´erationnels d’un organisme n’est pas une tˆache
facile. Les normes sont d´efinies des fac¸ons visant `a maximiser la performance, mais
les gestionnaires et les employ´es sont principalement laiss´es `a eux-mˆemes pour d
´ecider comment am´eliorer pratiquement la situation.

1.4.1 E´ tat actuel de la soci´et´e

Actuellement la soci´et´e BILOG utilise des anciennes m´ethodes de test, qui
sont les tests manuels. Tous les sc´enarios sont r´ealis´es par un ˆetre humain, le
testeur navigue librement dans l’application pour y d´eceler le maximum de bugs et de
probl`emes. Ces tests demandent beaucoup de temps et `a chaque fois les mˆemes sc
´enarios doivent ˆetre r´ep´et´es.
Cycle de vie actuel de chaque application :

1. L’´equipe analyse le cahier des charges et les sp´ecifications envoy´es par le client

8
 1.4. Etude de
2. l’´equipe d´eveloppement r´ealise l’application.

3. l’´equipe assurance qualit´e (QA) cr´ee un plan de test sur l’application TestLink.

4. D`es que l’application sera prˆete l’´equipe QA teste l’application

manuellement pour d´etecter le maximum nombre des bugs.

9
 1.4. Etude de

5. L’´equipe QA cr´ee un ticket pour chaque bug d´etect´e sur l’application Redmine.

6. A` la fin de tests l’´equipe QA cr´ee un compte-rendu d´etaill´e dans l’application Zulip

7. L’´equipe d´eveloppement corrige les bugs et met `a jour le statut des tickets
puis doit relivrer l’application en recette avec les nouvelles fonctionnalit´es corrig
´ees.

8. L’´equipe QA reteste tous les modules de l’application.

⇒ Les mˆemes taches se r´ep`etent jusqu’`a obtenir une application qui r´epond aux
crit`eres et au besoin client.

TestLink

c’est un outil de gestion des tests (ALM) open source bas´es sur le web et totalement
gratuit. Il permet, comme d’autres ALM, de g´erer ses exigences, tests et campagnes de
test tout en les liant entre elles.

Redmine

Redmine est une application appartenant `a la cat´egorie des logiciels de gestion de

projet, open source. Redmine recouvre l’ensemble des fonctionnalit´es cl´es d’une
application de gestion de projet. Parmi les principales, on retrouve :

— La gestion multiprojets

— La gestion de groupes d’utilisateurs

— La personnalisation des champs des demandes

— Un forum de discussion par projet

— Etc

Zulip

Zulip est une application de messagerie pour les entreprises et les organisations (web,
bureautique ou Android) qui vise `a combler les besoins de communication de groupes.

1.4.2 Probl´ematique
Les inconv´enients de la m´ethode utilis´ee par bilog dans la gestion des projets sont les suivants :

— Perte de temps : ces tests demandent beaucoup de temps et `a chaque fois

les mˆemes sc´enarios doivent ˆetre r´ep´et´es.

— Perte de ressources : ces travaux n´ecessitent plusieurs personnes.

— Pas de liaison entre les outils : chaque application fonctionne ind´ependamment de l’autre.

1
 1.4. Etude de

1.4.3 Solution et architecture du projet

La solution propos´ee est de mettre en place une plateforme DEVOPS afin de lier
toutes les applica- tions entre elles pour automatiser et simplifier les tˆaches de l’´equipe
en utilisant la chaine pr´esent´ee dans la figure 1.3.

FIGURE 1.3 – Architecture du projet

La plateforme DevOps se compose de plusieurs outils qui communiquent entre eux, et

chaque outil a son rˆole dans la chaˆıne de d´eveloppement. L’architecture, pr´esent´ee
dans la figure 1.3, sp´ecifie les interactions entre les outils et le rˆole de chaque outil.

GitLab est une plateforme DevOps compl`ete propos´ee sous la forme d’une
application unique. Elle r´evolutionne le d´eveloppement, la s´ecurit´e, l’exploitation et la
collaboration entre les ´equipes. Nous avons choisi GitLB dans notre projet parce qu’il
est open source et populaire.
Jenkins est le coueur d’une plateforme DevOps,il assure le lien entre les diffrents composnts.
SonrQube est un logiciel libre qui permet de mesurer la qualit´e du code source.
Selenium est un projet englobant un ´eventail d’outils et de librairies permettant
l’automtisation des navigateurs internet.
Docker est une technologie de conteneuristion qui permet la cr´eation et l’utilisation de
conteneurs.

Le cycle de vie de chaque projet sera le suivant :

1
 1.4. Etude de
1. L’´equipe analyse le cahier des charges et les sp´ecifications envoy´es par le client

1
 1.5. M´ethodologies de

2. l’´equipe ´elabore le TDD (Test Driven Development) et le plan de test en utilisant TestLINK

3. Les d´eveloppeurs commencent le d´eveloppement de l’application. Les ing

´enieurs QA ´elaborent le plan de test, les tests unitaires, et les tests fonctionnels
en utilisant Selenium.

4. Les d´eveloppeurs livrent le livrable du sprint en recette

5. L’´equipe lance l’ex´ecution de la chaine, une fois l’application d´etecte une erreur,
un ticket va ˆetre cr´e´e automatiquement sur REDMINE. Apr`es le test un
rapport va ˆetre g´en´er´e automatiquement et publi´e dans la room du projet dans
l’application zulip.

6. Apr`es la correction des bugs d´etect´es, tous les sc´enarios seront faits suite au
lancement de la chaine. D`es qu’on obtient une application qui r´epond aux
crit`eres et au besoin client l’application sera livr´ee en prod.

1.5 M´ethodologies de travail

D´edi´ees `a la gestion de projets informatiques, les m´ethodes agiles reposent sur une
approche it´erative et incr´ementale qui s’adaptent parfaitement aux futurs besoins du
client.
Les m´ethodes agiles dirig`erent vers int´egrer le client dans la r´ealisation du projet afin
d’avoir un produit de haute qualit´e.
Il existe plusieurs m´ethodologies dans la famille comme la m´ethode RUP, la m
´ethode XP, la m´ethode Scrum, etc.
Pour la gestion de ce projet nous avons choisi d’utiliser la m´ethode SCRUM, car
elle est la m´ethode la plus pratiqu´ee parmi toutes les m´ethodes agiles existantes.
C’est une m´ethode agile principalement bas´ee principalement sur des it´erations de
courtes dur´ees appel´ees Sprints.

1.5.1 Avantages de la m´ethode agile Scrum

La m´ethode agile Scrum a plusieurs avantages comme :

— Avoir une id´ee claire sur les diff´erentes ´etapes du projet : une vue
d’ensemble sur l’´evolution du projet du l’´etape de d´eveloppement vers l’´etape
de production.

— Avoir une flexibilit´e totale du projet : le client peut avoir une flexibilit´e
totale au niveau de la d´efinition des priorit´es selon ses besoins.

— Avoir la meilleure qualit´e : une ´evaluation p´eriodique de l’avancement du

projet et sa permet de garantir une meilleure qualit´e du produit.

1
 1.5. M´ethodologies de
— Avoir une planification adapt´ee `a votre besoin : une planification d´etaill´ee `a
court terme et `a long terme.

1
 1.5. M´ethodologies de

FIGURE 1.4 – Methode-scrum [6]

1.5.2 Ce qui change avec Scrum

Certaines fonctions d´evolues traditionnellement au chef de projet sont d´el´egu´ees `a
d’autres personnes. Il n’y a plus de management d’´equipe : Dans Scrum, l’´equipe
s’auto-organise et s’autog`ere `a l’aide d’un facilitateur, le scrum master. Il n’y a donc
plus de management hi´erarchique.
La gestion de la qualit´e : Le scrum master est responsable du respect du processus de
d´eveloppement et des normes de qualit´e. C’est l’´equipe tout enti`ere qui est
responsable de la qualit´e du produit.
Le d´ecoupage technique du projet et les estimations : L’expertise technique
est du ressort de l’´equipe. C’est elle qui identifie les taches et estime la charge de
travail.

1.5.3 L’´equipe scrum

Le tableau suivant nous montre les taches des diff´erents membres de l’´equipe scrum :

1
 1.5. M´ethodologies de

Membres taches
S’assure que les principes et les valeurs de Scrum sont
Le Scrum Master
respect´es. Facilite la communication au sein de
l’´equipe.
Cherche `a am´eliorer la productivit´e et le savoir-faire de
son ´equipe.
Pas de rˆole bien d´etermin´e : architecte, d
L’E´ quipe de d
´eveloppement ´eveloppeur, testeur. Tous les membres de l’´equipe
apportent leur savoir-faire pour ac- complir les tˆaches.
Taille de 6 `a 10 personnes en g´en´eral et pouvant aller
jusqu’`a 200
personnes.
Expert m´etier, d´efinit les sp´ecifications fonctionnelles.
Le Product Owner
E´ tablit la priorit´e des fonctionnalit´es `a d´evelopper
ou corriger. Valide les fonctionnalit´es d´evelopp´ees.
Joue le rˆole du client.

1.5.4 Le sprint
Au cœur de Scrum, le sprint a une dur´ee d’un mois ou moins au cours duquel une
version ≪ termin´ee≫, utilisable et potentiellement livrable du logiciel est cr´e´ee. Il est pr
´ef´erable que les sprints gardent une dur´ee constante tout au long de l’initiative de d
´eveloppement. Un nouveau Sprint d´ebute imm´ediatement apr`es la conclusion du pr´ec
´edent.

1.5.5 Les artefacts

Les artefacts Scrum sont des documents qui fournissent des informations cl´es
que l’´equipe Scrum et les parties prenantes doivent connaˆıtre pour comprendre le
produit en d´eveloppement, les activit´es r´ealis´ees et les activit´es pr´evues dans le
projet. Les artefacts suivants sont d´efinis dans le Scrum Process Framework :

— Le Product Backlog : C’est l’ensemble des fonctionnalit´es du produit que l’on veut d
´evelopper.

— Le Sprint Backlog : C’est une liste de tˆaches identifi´ees par l’´equipe `a remplir pendant un
sprint.

— Le Burndown charts : Mise en relief du taux de travail restant dans un sprint.

1.5.6 Les ´ev`enements scrum

La figure 1.8 pr´esente les diff´erents ´ev´enements de scrum.

1
 1.6. M´ethodologie de

FIGURE 1.5 – Les ´ev´enements scrum [7]

Planification de Sprint (Sprint planning) : c’est un ´ev´enement Scrum qui d´efinit

ce que l’´equipe sera en mesure de livrer dans le prochain Sprint et comment y
parvenir

Mˆel´ee quotidienne (daily meeting) : Comme son nom l’indique, la r´eunion a

lieu tous les jours. La dur´ee la plus longue est de 15 minutes. Son objectif est de
permettre `a l’´equipe Scrum de synchroniser et d’ajuster ses op´erations sous 24h, et de
r´epartir les tˆaches `a traiter.

Revue de sprint : Le but de la revue est de montrer les r´ealisations r´ealis´ees lors du
sprint afin d’arriver
`a des r´esultats pour le reste du projet.

R´etrospective du sprint : Le sprint r´etrospectif est la c´er´emonie Scrum `a la

clˆoture du Sprint, qui a lieu imm´ediatement apr`es la revue du Sprint. En effet, le
sprint est clos `a l’issue de cette c´er´emonie

1.6 M´ethodologie de conception

La phase de conception de notre projet doit utiliser une m´ethode pour construire le
mod`ele sur lequel nous allons nous appuyer. Pour cette raison, nous retenons UML

1
 1.6. M´ethodologie de
comme m´ethode m´ethodologique.

UML est un langage qui s’appuie sur un m´eta-mod`ele, un mod`ele de plus haut niveau qui d
´efinit les
´el´ements d’UML (les concepts utilisables) et leur s´emantique (leur signification et
leur mode d’utilisa- tion). UML est un langage, donc un formalisme pour repr´esenter
un des concepts. Il ne suffit pas de

1
 1.7. Environnement de

produire des logiciels de qualit´e, mais son utilisation, largement r´epandue, a prouv
´e son utilit´e dans la sp´ecification d’une application.

UML offre diff´erents mod`eles pour sp´ecifier et concevoir un logiciel. Ces mod`eles utilisent une
repr´esentation graphique sous forme de diagrammes repr´esentant des vues diff´erentes du
syst`eme (diagramme de cas d’utilisation, diagramme de classes, diagramme de s´equence,
diagramme de d´eploiement, diagramme d’ac- tivit´es...).

Dans notre travail, nous allons nous int´eresser `a l’´elaboration des diagrammes suivants ;

— Diagrammes de cas d’utilisation.

— Diagrammes de s´equences.

— Diagramme de d´eploiement

1.7 Environnement de travail

Cette partie est consacr´ee `a la pr´esentation des technologies utilis´ees ainsi
que l’environnement de d´eveloppement logiciel. nous expliquerons nos choix techniques
concernant les langages de programmation et les outils utilis´es ainsi qu’un apercu sur les
´etapes planifi´ees pour la r´ealisation du projet.

1.7.1 Choix technologiques

.Net C’est la technologie .net la plus r´ecente qui fait partie de la plateforme
Microsoft.NET. Elle permet la programmation des applications web dynamiques ou des

web services.[3]

FIGURE 1.6 – .Net

Selenium WebDriver est un framework web qui vous permet d’ex´ecuter des tests
multi-navigateurs. Cet outil est utilis´e pour automatiser les tests d’applications Web
pour v´erifier qu’ils fonctionnent cor- rectement.

1
 1.7. Environnement de

NUnit est un framework de test unitaire pour tous les langages .NET.
Initialement port´ee `a partir

2
 1.7. Environnement de

FIGURE 1.7 – Selenium WebDriver

de JUnit, la version de production actuelle a ´et´e r´e´ecrite avec de nombreuses

nouvelles fonctionnalit´es et la prise en charge d’un large ´eventail de plates-formes
.NET. C’est un projet de la Fondation .NET. [1]

NUnit est pr´ef´er´e aux autres frameworks de test car il est compatible avec la suite
de tests Selenium. Les tests NUnit pour l’automatisation Selenium sont largement utilis´es
en raison des avantages suivants par rapport aux autres frameworks de test :

— Les annotations utilis´ees dans NUnit aident `a acc´el´erer le d´eveloppement et

l’ex´ecution des tests, car les tests peuvent ˆetre ex´ecut´es avec de nombreuses
valeurs d’entr´ee.

— Le TDD est principalement utile car les tests unitaires sont essentiels pour trouver des
probl`emes
/ bogues au cours des premi`eres ´etapes du d´eveloppement du produit. Le
framework de test NUnit peut ˆetre utilis´e avec Selenium si vous pr´evoyez
d’utiliser TDD (Test Driven Development) pour l’activit´e de test.

— Vous offre la possibilit´e d’ex´ecuter vos cas de test en parall`ele.

— A` l’aide de NUnit, vous pouvez ex´ecuter des cas de test `a partir de l’ex
´ecution de la console par un outil de test d’automatisation tiers ou par
l’adaptateur de test NUnit dans Visual Studio.

FIGURE 1.8 – NUnit

2
 1.7. Environnement de

1.7.2 Choix logiciel

Visual Studio 2019 C’est un environnement de d´eveloppement int´egr´e (EDI)
de Microsoft. Il est utilis´e pour d´evelopper des programmes informatiques pour
Windows (OS Microsoft), ainsi que des sites Web, des applications Web et des services
Web. VS 2017 est la derni`ere mise `a jour du logiciel rendu disponible en november
2017. Nous avons utilis´e ce logiciel pour le d´evelopper du projet.[4]

FIGURE 1.9 – Visual studio

StarUML est un logiciel de mod´elisation UML, c´ed´e comme open source par
son ´editeur, `a la fin de son exploitation commerciale, sous une licence modifi´ee de
GNU GPL. Nous l’avons utilis´e pour la conception du projet.[2]

FIGURE 1.10 – StarUML

Jenkins est un outil logiciel d’int´egration continue. Il s’agit d’un logiciel open source d
´evelopp´e `a l’aide du langage de programmation Java. Il vous permet de tester et
de signaler les modifications apport´ees sur une large base de code en temps r´eel.
En utilisant ce logiciel, les d´eveloppeurs peuvent rapidement d´etecter et r´esoudre
les probl`emes dans la base de code. En cons´equence, les tests nouvellement construits
peuvent ˆetre automatis´es, ce qui facilite l’int´egration continue des modifications dans le
projet. L’objectif de Jenkin est d’acc´el´erer le d´eveloppement de logiciels grˆace `a
2
 1.7. Environnement de
l’automatisation. Jenkins peut int´egrer toutes les ´etapes du cycle de d
´eveloppement. Nous avons utilis´e cet outil pour l’orchestration entre les

2
 1.7. Environnement de

autres outils, et pour automtiser les pipelines.

FIGURE 1.11 – Jenkins

SonarQube est un outil de r´evision automatique de code, utilis´e pour d

´etecter les erreurs, les vuln´erabilit´es et les odeurs de code. Il peut ˆetre int´egr´e
`a votre flux de travail existant pour permettre une inspection continue du code dans
les branches du projet et les demandes d’extraction. Nous avons utilis´e cet outil pour
mesurer la qulit´e de notre code source.

FIGURE 1.12 – SonarQube

Redmine est une application web libre de gestion de projets compl`ete, d

´evelopp´ee en Ruby sur la base du Framework Ruby on Rails. Il a ´et´e cr´e´e par
Jen-Philippe Lng. Nous avons utilis´e cet outil pour la gestion des tickets des bugs.

FIGURE 1.13 – Redmine

2
 1.8. Etude

Zulip est un outil de chat et de collaboration interne dont le rˆole est d’´etablir des
discussions internes et d’informer les parties prenantes du projet `a travers de nouveaux
´ev´enements. Zulip peut envoyer des messages internes et des messages courts
rapidement et facilement. Il offre une visibilit´e sur le statut des employ´es (en r
´eunion/disponible/absent). Il prend en charge la fonction de notification de bureau et peut
´egalement ˆetre notifi´e via l’interface des outils GitLAB / SonarQube et Jenkins
DevOps. Il convient `a la version web/de bureau/t´el´ephone mobile.

FIGURE 1.14 – Zulip

Docker est un logiciel libre Open Source qui permet d’automatiser le d

´eploiement d’applications. Il a ´et´e d´evelopp´e par Solomon Hykes de la soci´et´e
dotCloud et a ´et´e distribu´e `a partir de mars 2013. C’est une plateforme de
virtualisation par conteneur qui va permettre de concevoir, tester et d´eployer des
applications rapidement. Grˆace `a Docker, il est facile de d´eployer et dimensionner les
applications dans n’importe quel environnement en s’assurant que le code s’ex´ecutera
automatiquement.

FIGURE 1.15 – Docker

1.8 Etude comparative

Pour mettre en place le pipeline DEVOPS, nous avons besoin d’un ensemble
d’outils `a savoir, un gestionnaire de version, un orchestrateur, un outil d’automatisation
et un serveur de qualit´e de code.

2
 1.8. Etude
Dans cette partie, nous devons proc´eder `a une ´etude comparative entre les diff´erents
outils qui existent sur le march´e.

2
 1.8. Etude

1.8.1 Gestionnaire de version : Git vs SVN

Le tableau suivant illustre les oppositions majeures qui existent entre les deux outils :

Aspect Git SVN

Versionning D´ecentralis´e Centralis´e
Des copies de d´epˆot, pr
Un d´epˆot central dans lequel
D´epˆot ´esentes loca- lement, dans
les co- pies de travail sont cr´e
lesquelles il est possible
´ees.
de travailler.
Droit d’acc`es Pour le r´epertoire complet. Bas´e sur le chemin.
Suivi des Enregistre des donn´ees. Enregistre des donn´ees.
modifications

Le choix du gestionnaire du code source a ´et´e fait par l’entreprise.

1.8.2 Serveur d’orchestration

Jenkins, travis et bamboo sont des outils d’orchestration bien connus sur le march´e,
chacun d’entre eux pr´esente ses avantages et ses inconv´enients. Le tableau suivant
permet de comparer entre ces outils.

Caract´eristique Jenkins travis Bamboo

les versions sous li-
A` partir de 69$ cence facturent
Prix Lib´erer
par mois environ 880$ pour
un agent dis-
tant
Certains priv´es
Mod`ele logiciel Open source (cer- Outil commercial

tains open source)

Origine Java Java Java
Solution cloud Oui Oui Oui
Plugins Oui Cher Peu

L’´etude comparative entre ces diff´erents serveurs d’orchestration a dirig´e notre

choix vers Jenkins, qui, grˆace `a ses nombreux plugins, permet un interfac¸age facile
avec de nombreux outils dont nous avons besoin tel que Sonar, selenium, redmine ...

1.8.3 Sonarqube vs SonarLint

Le serveur de qualit´e de code a plusieurs atouts pour n’importe quel projet. En
effet, il fournit une analyse compl`ete de la qualit´e d’une application en fournissant de
2
 1.8. Etude
nombreuses statistiques. Ces donn´ees permettent ainsi d’´evaluer la qualit´e du code, et
d’en connaˆıtre l’´evolution au cours du d´eveloppement.

2
 1.8. Etude

Aspect Sonarqube Sonarlint

Open source Oui Oui
Installation `a base de Facile Moyen
Docker
Langages support´es 25+ 20+
Tableau de bord Oui Non

Apr`es cette comparaison, nous avons choisi de travailler avec Sonarqube comme
serveur de qualit´e de code.

1.8.4 Conteneurs vs Machines virtuelles

Dans le cas de la virtualisation traditionnelle avec des machines virtuelles, chaque
machine virtuelle dispose de son propre syst`eme d’exploitation. Ainsi, lors de l’ex
´ecution des applications int´egr´ees `a des machines virtuelles, l’utilisation de la m
´emoire peut ˆetre sup´erieure `a ce qui est n´ecessaire et les machines virtuelles peuvent
commencer `a utiliser les ressources requises par l’hˆote.

Contrairement aux applications classiques, les applications conteneuris´ees partagent

un environnement de syst`eme d’exploitation (noyau), elles utilisent donc moins de
ressources que des machines virtuelles compl`etes et r´eduisent la pression sur la m
´emoire de l’hˆote.

FIGURE 1.16 – VMs vs Docker[10]

Vu ses points forts, nous avons d´ecid´es de choisir docker comme solution de
virtualisation pour mettre en place notre plateforme d’int´egration continue.

2
 1.9.

1.9 Conclusion
Dans ce chapitre, nous avons donn´e un aper¸cu du projet en d´ecrivant l’organisme
d’accueil BILOG, et le contexte du projet. Nous avons pr´esent´e aussi la m´ethode
de travail Agile scrum, le langage de mod´elisation UML, environnement de travail et
nous avons termin´e par l’´etude comparative.
Le prochain chapitre sera consacr´e `a l’analyse et la sp´ecification des besoins.

3
2 Analyse et sp´ecification des besoins

2.1 Introduction
Ce chapitre sera commenc´e par la sp´ecification des besoins, ensuite nous allons
voir le diagramme des cas d’utilisation globale et nous terminerons par le pilotage du
projet par Scrum.

2.2 Sp´ecifications des Besoins

La sp´ecification des besoins repr´esente la premi`ere phase du cycle de d
´eveloppement d’un syst`eme. Elle sert `a identifier les acteurs r´eactifs du syst`eme
pour associer `a chacun l’ensemble d’actions avec lesquelles il intervient dans l’objectif
de donner un r´esultat optimal et satisfaisant pour le client.

2.2.1 Besoins Fonctionnels

Il s’agit des fonctionnalit´es du syst`eme. Ce sont les besoins sp´ecifiant un
comportement d’entr´ee / sortie du syst`eme.
Le syst`eme permet de :

— Faire la liaison entre les diff´erents outils de syst`eme.

— Automatiser les taches de l’´equipe.

— D´etecter automatiquement des erreurs..

— Minimiser les erreurs humaines possibles.

— Gagner du temps sur la r´esolution des probl`emes.

— R´eduire les risques grˆace `a l’automatisation des processus.

— Automatiser la g´en´eration de rapport

— Interfac¸age avec les applications

21
 2.2. Sp´ecifications des

2.2.2 Besoins Non Fonctionnels

Les besoins non fonctionnels d´ecrivent toutes les contraintes aux quelles est soumis
le syst`eme pour sa r´ealisation et son bon fonctionnement.
Les besoins non fonctionnels de notre syst`eme se d´ecrivent comme suit :

— Rapidit´e : Le syst´eme doit optimiser les traitements pour avoir un temps de g´en
´eration de sch´emas raisonnable.

— Efficacit´e : Le syst´eme doit ˆetre fonctionnelle ind´ependamment de toutes

circonstances pouvant entourer l’utilisateur.

— S´ecurit´e : D´efinit les niveaux d’acc`es possibles au syst`eme pour les

utilisateurs et les syst`emes externes.

2.2.3 Identification des acteurs du syst`eme informatique

Dans cette partie nous allons identifier les acteurs du syst`eme informatique en
prenant en compte ceux du m´etier qui touchera de fa¸con directe ce syst`eme.

FIGURE 2.1 – Acteurs syst`eme

Invit´e : cet utilisateur n’appartient pas `a l’´equipe scrum, il peut ˆetre un chef de
projet, un respon- sable du pˆole, etc.

Ingenieur QA c’est l’ex´ecuteur des cas de tests. Il enregistre les anomalies et les d
´efauts du produit dans l’outil, enregistre les exigences du produit, pr´epare et d
´eveloppe les sc´enarios de tests.

D´eveloppeur c’est le d´eveloppeur des applications et le correcteur des bugs.

2
 2.3. Diagramme des cas d’utilisation

Acteur Role
Ingenieur QA G´erer les projets de
test G´erer les plans
de test
G´erer et Suivre les anomalies d´etect´ees et les
tickets cr´e´es
Suivre les comptes rendus
D´eveloppeur Configurer la chaine DEVOPS
G´erer et Suivre les anomalies d´etect´ees et les
tickets cr´e´es Suivre les comptes rendus
Invit´e Suivre les comptes rendus

2.3 Diagramme des cas d’utilisation globale

Les besoins et les acteurs que nous avons extraits se traduisent en ce diagramme, qui
sera notre rep`ere tout au long du d´eveloppement.
Le diagramme repr´esent´e dans la figure 2.2 nous donne une vision globale sur l’application.

FIGURE 2.2 – Diagramme de cas d’utilisation globale

Au cours des sprints, on construira une conception plus d´etaill´ee d’une fa¸con incr´ementale.

2
 2.4. Le pilotage du projet par

2.4 Le pilotage du projet par Scrum

Comme nous avons mentionn´e dans la section M´ethodologie de travail du
chapitre 1, nous avons choisi la m´ethodologie agile, car elle offre la facilit´e d’un d
´eveloppement rapide et permettra de r´eutiliser les fonctionnalit´es d´evelopp´ees s´epar
´ement de la plateforme.
Notre m´ethodologie n´ecessite la collaboration de plusieurs intervenants.

Pour notre projet :

Mr Saifeddine BAHRI est `a la fois notre :

- Product Owner car il a une forte connaissance sur le sujet, ses d´etails et l’ancienne application.
-Scrum Master puisqu’il est certifi´e par ScrumAlliance et nous a appris les bases de Scrum.

L’´equipe de d´eveloppement( d´eveloppeur et QA) : Fares BEN REJIBA ,Fethi SLIM et Wiem
JEMAI

2.4.1 D´ecoupage du projet

Le choix de Scrum exige le d´ecoupage du projet en plusieurs releases.
Le Release Planning est une s´erie de sprints successifs qui refl`ete les attentes par
rapport aux fonctionna- lit´es qui seront mises en œuvre et qui se terminent quand les incr
´ements successifs constituent un produit pr´esentant suffisamment de valeurs `a ses
utilisateurs.

FIGURE 2.3 – Exemple de sch´ema de d´ecoupage en releases [9]

La figure 2.4 repr´esente le d´ecoupage de notre projet en diff´erents lots d’activit´es afin
d’avoir des parties dont la complexit´e est plus ais´ement maitrisable.

2
 2.4. Le pilotage du projet par

FIGURE 2.4 – D´ecoupage du projet

2.4.2 Product Backlog

Scrum d´ecrit trois artefacts principaux :

— Le backlog du produit

— Le backlog Sprint

— L’incr´ement du produit.

Le Product Backlog est le point central de tout projet Scrum. Il est sous la
responsabilit´e unique du Product Owner, mais doit ´egalement ˆetre accessible par
l’´equipe.

ID Epics ID User stories User stories

En tant que membre de l’´equipe
D´eveloppement des 1.1 scrum, Elev´e
1
tests automatis´es et je veux voir l’ex´ecution des tests
installation des En tant que membre de l’equipe
1.2 scrum, Elev´e
outils
je veux utiliser les outils de la
chaine.
En tant que membre de l’´equipe
scrum,
2.1 Elev´e
2 Configuration des outils je veux utiliser Redmine dans la
chaine devops.
En tant que membre de l’´equipe
2.2 scrum, je veux utiliser Zulip dans Elev´e
la chaine de-
vops.
En tant que membre de l’´equipe
2.3 scrum, je veux utiliser selenium Elev´e

2
 2.4. Le pilotage du projet par
dans la chaine
devops.
En tant que membre de l’´equipe
scrum,
2.4 Elev´e
je veux utiliser SonarQube dans
la chaine devops.

2
 2.4. Le pilotage du projet par

2.4.3 Gestion de Projet

Dans la figure 2.5 nous pr´esentons la planification que nous avons suivie tout au long du
stage.

FIGURE 2.5 – Planification du projet

Scrum Board :
Pour mieux organiser notre travail, nous avons utilis´e l’un des outils offerts par
Scrum qui est Scrum Board.

FIGURE 2.6 – Tableau scrum

Scrum Board est un outil qui aide les ´equipes `a rendre visibles les ´el´ements du
SprintBacklog. Le tableau peut prendre de nombreuses formes physiques et virtuelles, mais

2
 2.4. Le pilotage du projet par
il remplit la mˆeme fonction, quel que soit son aspect. Le tableau est mis `a jou par
l’´equipe et montre tous les ´el´ements qui doivent ˆetre compl´et´es

2
 2.5. Conclusion

pour le sprint actuel.

Il comporte quatre colonnes :

— User Story (Les ≪ user story ≫ du sprint actuelle)

— To Do(Les taches `a faire)

— In progress(Les taches en cours de d´eveloppement)

— Done(Les taches termin´es)

2.5 Conclusion
Dans ce chapitre, nous avons extrait les besoins ainsi que les acteurs qui vont nous
servir pour guider dans le d´eveloppement qu’on va entamer d`es le prochain chapitre.
Selon notre planning, le d´eveloppement sera d´ecoup´e en deux sprints, pour s´eparer et
simplifier les tˆaches. Dans le chapitre suivant nous allons ´etudier le premier sprint
”d´eveloppement des tests automatis´es et installation des outils”

2
 3
Sprint 1 - D´eveloppement des tests
automatises et installation des outils
´

3.1 Introduction
Au d´ebut de chaque sprint, nous d´efinissons un objectif et nous lui associons
une liste de fonction- nalit´es qui constituera le sprint backlog. Au cours d’un sprint,
l’objectif et la composition de l’´equipe ne peuvent ˆetre modifi´es. Durant ce sprint, nous
devons r´ealiser les tests automatis´es et installer les diff´erents outils de syst`eme.

3.2 Sp´ecification des besoins

Dans cette partie nous allons analyser les ”user stories” de ce sprint.

Le sprint backlog
Notre sprint backlog se pr´esente comme suit :

User stories ID Taches

Analyse le cahier des charges et les
En tant que membre de l’´equipe scrum, je 1.1
sp´ecifications envoy´es par le client
veux voir l’ex´ecution des tests.
1.2 D´evelopper les tests automatis´es
En tant que membre de l’equipe scrum, 2.1 Installation, Configuration et test de
Jenkins
je veux utiliser les outils de la chaine.
2.2 Installation, Configuration et test de
Docker
Installation, Configuration et test de
2.3 Sonar-
Qube
28
 3.3. Tests

3.3 Tests automatis´es

Pour r´ealiser ce projet nous avons d´ecid´e d’utiliser le module ”Fiche signal´etique”
du projet ”Gestion des formations”.
Gestion des formations une application Web permettra aux utilisateurs de la soci´et´e g´en
´erale des m´edecins de g´erer les formations, les utilisateurs et les activit´es.
Le module fiche signal´etique comporte les fonctionnalit´es suivantes que nous allons
tester au cours de ce sprint :

— Authentification

— Ajouter une fiche

— Afficher une fiche

— Modifier une fiche

— Supprimer une fiche

3.3.1 Diagramme de Cas d’utilisation ”Fiche signal´etique”

FIGURE 3.1 – Fiche signal´etique

3.3.2 Tests fonctionnels

Dans cette partie, nous effectuerons un jeu d’essai pour tester le module ”Fiche
signal´etique” de l’application ”Gestion des formation”.

Les packages

Pour ces tests nous allons utiliser le NUnit Framework, l’adaptateur de test NUnit
et le Selenium WebDriver.

2
 3.3. Tests

Nous avons install´e le NUnit comme indique la figure 3.2

FIGURE 3.2 – NUnit Framework et de l’adaptateur de test NUnit

La figure 3.3 pr´esente l’installation de selenium WebDriver.

FIGURE 3.3 – Selenium WebDriver

L’int´egration du s´el´enium avec le framework NUnit permet `a un testeur de diff

´erencier les diff´erentes classes de test. NUnit permet ´egalement aux testeurs d’utiliser
des annotations telles que SetUp, Test et TearDown pour effectuer des actions avant et
apr`es l’ex´ecution du test.

Identification des ´el´ements :

Pour trouver l’´el´ement avec pr´ecision sur les pages Web, il existe diff´erents types de
localisateurs :

— Nom : Pour rechercher l’´el´ement par le nom de l’´el´ement

— Identifiant : Pour trouver l’´el´ement par ID de l’´el´ement

— Nom du cours : Pour trouver l’´el´ement par nom de classe de l’´el´ement

3
 3.3. Tests
— Texte du lien : Pour trouver l’´el´ement par texte du lien

3
 3.4. Installation des

— XPath : XPath requis pour trouver l’´el´ement dynamique et passer entre divers ´el
´ements de la page Web

— Chemin CSS : Le chemin CSS localise ´egalement les ´el´ements sans nom, classe ou ID.

Locator est une commande qui indique `a Selenium IDE quels ´el´ements de
l’interface graphique (par exemple, zone de texte, boutons, cases `a cocher, etc.) il
doit fonctionner. L’identification des ´el´ements d’interface utilisateur corrects est une
condition pr´ealable `a la cr´eation d’un script d’automatisation.

Dans l’automatisation Selenium, si les ´el´ements ne sont pas trouv´es par les
localisateurs g´en´eraux tels que id, classe, nom, etc., XPath est utilis´e pour trouver un
´el´ement sur la page Web.

R´esultat des tests S´el´enium

Suite aux tests de diff´erentes fonctionnalit´es du module ”Fiche signal´etique”

nous avons d´etect´e un bug lors de la suppression d’une fiche

FIGURE 3.4 – R´esultat test selenium

Sc´enario du bug :

— Cr´eer une fiche m´edecin.

— Supprimer la fiche.
⇒ La fiche a ´et´e supprim´ee avec succ`es
— Cr´eer une autre fiche m´edecin avec le mˆeme nom, pr´enom et code postale de l’ancienne
fiche.
⇒ D´etection d’un doublon, impossible de cr´eer la fiche.

3
 3.4. Installation des
3.4 Installation des outils
A` ce niveau-l`a nous allons installer les diff´erents outils de notre pipeline.

3
 3.4. Installation des

3.4.1 Jenkins
Nous avons install´e et configur´e l’outil Jenkins sur le serveur DevOps, pour
l’orchestration entre les autres outils, et afin d’automatiser le pipeline.
La figure 3.5 contient l’interface web de Jenkins apr`es l’installation.

FIGURE 3.5 – Installation Jenkins

3.4.2 SonarQube et Sonar Scan

Nous avons install´e et configur´e l’outil SonarQube sur le serveur DevOps, pour
l’audit qualit´e code source. Voir figure 3.6

FIGURE 3.6 – Installation SonarQube

3.4.3 Docker
Nous avons install´e Docker sur le serveur de d´eploiement, pour d´eployer le projet.

3
 3.5.

FIGURE 3.7 – Installation Docker

3.5 Conclusion
Dans ce chapitre, nous avons expos´e l’installation de diff´erents outils de notre
syst`eme ainsi le d´eveloppement des tests automatis´es.
Dans la partie suivante nous allons ´etudier la configuration de notre chaine DEVOPS.

3
4 Sprint 2 - Configuration des outils

4.1 Introduction
Durant ce sprint, nous devons mettre en place et configurer les diff´erents outils de syst`eme.

4.2 Sp´ecification des besoins

Nous allons analyser les ”user stories” pour avoir une description des sc´enarios
de chacune d’elles, avec une conception globale, et nous achevons finalement par la
configuration et le test.

Le sprint backlog
Notre sprint backlog se pr´esente comme suit :

User stories ID Taches

En tant que membre de l’equipe scrum, 1.1 Integration de Redmine dans la chaine
Devops
je veux utiliser Redmine dans la chaine
1.2 Configuration de Redmine
devops
1.3 Test l’outil
En tant que membre de l’equipe scrum, 2.1 Integration de Zulip dans la chaine
Devops
je veux utiliser Zulip dans la chaine
2.2 Configuration de Zulip
devops
2.3 Test l’outil
En tant que membre de l’equipe scrum, 3.1 Integration de Selenium dans la chaine
Devops
je veux utiliser Selenium dans la chaine
3.2 Configuration de Selenium
devops
3.3 Test l’outil
En tant que membre de l’equipe scrum, 4.1 Integration de SonarQube dans la chaine
Devops
je veux utiliser SonarQube dans la
4.2 Configuration de SonarQube
chaine devops
4.3 Test l’outil
34
 4.3. Diagramme de Cas

4.3 Diagramme de Cas d’utilisation

Le diagramme repr´esent´e ci-dessous par la figure 4.1 d´ecrit les diff´erentes
actions r´ealis´ees par le testeur.

FIGURE 4.1 – Diagramme de cas d’utilisation du ingenieur QA

Le diagramme repr´esent´e ci-dessous par la figure 4.2 d´ecrit les diff´erentes

actions r´ealis´ees par le d´eveloppeur.

FIGURE 4.2 – Diagramme de cas d’utilisation du d´eveloppeur

Le diagramme repr´esent´e ci-dessous par la figure 4.3 d´ecrit les diff´erentes actions r´ealis´ees

3
 4.3. Diagramme de Cas
par l’invit´e

3
 4.4. Diagramme de d

syst´eme.

FIGURE 4.3 – Diagramme de cas d’utilisation du l’invit´e

4.4 Diagramme de d´eploiement

Le diagramme de d´eploiement repr´esent´e dans la figure 4.4 est une vue statique qui
repr´esente l’uti- lisation de l’infrastructure physique par le syst`eme et la fac¸on
dont les composants du syst`eme sont distribu´es et la relation entre eux.
TSPLUS : Logiciel d’acc`es `a distance, de livraison d’applications et de s´ecurit´e pour
les professionnels de l’informatique.
IDE : Un environnement de d´eveloppement int´egr´e, ou IDE, est un logiciel de cr´eation
d’applications, qui rassemble des outils de d´eveloppement fr´equemment utilis´es dans une
seule interface utilisateur graphique (GUI).

FIGURE 4.4 – Diagramme de d´eploiement

3
 4.5. Conception

4.5 Conception
La conception est la deuxi`eme ´etape dans ce sprint. Elle se traduit par, un
diagramme de s´equences. Ce diagramme permet de repr´esenter une vue dynamique du
syst`eme. Il permet de d´ecrire les sc´enarios de chaque cas d’utilisation en mettant
l’accent sur la chronologie des op´erations en interaction avec les objets.
La figure repr´esent´ee ci-dessous par la figure 4.5 d´ecrit l’interactions entre les
acteurs et les diff´erents outils de syst`eme selon un ordre chronologique.

FIGURE 4.5 – Diagramme de s´equence du syst´eme

Les webhooks permettent de d´eclencher une action suite `a un ´ev´enement. Ils sont g
´en´eralement utilis´es pour faire communiquer des syst`emes. C’est la fac¸on la plus
simple de recevoir une alerte lorsque quelque chose se produit dans un autre syst`eme.
Description du syst`eme :

1. Le d´eveloppeur fait un push vers le serveur GitLAb.

2. Le GitLAB notifie l’orchestrateur Jenkins par le nouveu push. Jenkins clone le code
depuis GitLAB et lance le build.

3. Jenkins notifie SonarQube pour clone et lance l’audit qualit´e du code source.
Jenkins rec¸oit le rapport sonar si le code passed ou non.

4. S’il y des bugs des tickets seront cr´e´es sur Redmine.

5. Jenkins notifie Selenium pour cloner et lancer les tests. Jenkins rec¸oit un rapport d´etaill´e.

6. S’il y a des bugs des tickets seront cr´e´es sur Redmine.

3
 4.6. R´ealisation : mettre en place le

7. Jenkins publie un rapport sur Zulip

8. Jenkins fait le d´eploiement sur conteneurs docker.

4.6 R´ealisation : mettre en place le pipeline

Dans cette partie nous allons ´etudier la mise en place de la chaine et la liaison
entre les diff´erents outils.

4.6.1 GitLab & Jenkins

La premi`ere ´etape sera la liaison entre Jenkins et Gitlab.

1. Cr´eation projet GITLAB

Nous avons commenc´e par la cr´eation d’un projet sur GitLAB.

FIGURE 4.6 – Cr´eation projet GITLAB

2. Upload du projet

Apr´es la cr´eation du projet GitLab nous allons uploader le projet de d

´eveloppement comme montre la figure 4.7.

3
 4.6. R´ealisation : mettre en place le

FIGURE 4.7 – Uploader le projet

3. Cr´eation projet jenkins

Nous avons choisi un projet ”free-style” car il est facile et non limit´e

FIGURE 4.8 – Cr´eation projet Jenkins

4. Configuration webhook

Apr`es la cr´eation du projet Jenkins nous avons configur´e le ”Webhook”, afin de g´en´erer un
token.
Dans la figure 4.9 nous avons g´en´er´e le token.

4
 4.6. R´ealisation : mettre en place le

FIGURE 4.9 – G´eneration d’un token

5. Liaison entre Jenkins et Gitlab

A` ce niveau il faut assurer la liaison entre Jenkins et Gitlab en utilisant le token g´en´er´e.
La figure 4.10 pr´esente la liaison entre jenkins et GitLab.
Nous avons ajout´e l’URL de Jenkins et le token dans le projet GitLab.

FIGURE 4.10 – Liaison entre jenkins et GitLab

Apr`es la configuration, Gitlab va envoyer une requˆete vers le lien Jenkins, ce dernier va
recevoir l’envoi, puis lancer l’ex´ecution.

4
 4.6. R´ealisation : mettre en place le

FIGURE 4.11 – V´erification

6. Param´etrer l’environnement de build

Pour param´etrer l’environnement de build il faut :

— Ajouter l’URL de GitLab, pour que Jenkins puisse r´ecup´erer le code : git clone ’URL’

— Donner au jenkins tous les droits d’acc`es au dossier.

— Installer les d´ependances du projet (exemple : prime Ng, input Groupe ...) en
utilisant la commande ”npm install”, les d´ependances install´ees seront trouv´ees
dans un dossier nomm´e ”node-modules”. (NB : il faut que ”node js” d´eja installer
dans notre machine).

— Cr´eer un dossier ”dist” en utilisant la commande ”Sudo ng build –prod” ce

dossier contient les dossiers qu’on va d´eployer.

FIGURE 4.12 – Environnement de build

4
 4.6. R´ealisation : mettre en place le

4.6.2 SonarQube & jenkins

La deuxi`eme ´etape de notre sprint sera la liaison entre SonarQube et Jenkins.

1. Cr´eation du projet SonaQube

Au d´ebut nous avons commenc´e par la cr´eation du projet SonarQube. Une

fois la proc´edure de cr´eation est termin´ee, nous devrons choisir le type du projet et
l’os.

FIGURE 4.13 – Parametrage du projet SonarQube

2. Audit du code source

Apr`es la cr´eation et le param´etrage du projet il faut lancer ”Sonar Scan”

dans le dossier de code source pour faire l’audit du code.

FIGURE 4.14 – Projet SonarQube

4
 4.6. R´ealisation : mettre en place le

Ex´ecution sonar avec jenkins.

FIGURE 4.15 – SonarQube avec jenkins

3. G´en´eration du rapport et des tickets

Apr´es l’analyse du code SonarQure g´en`ere un rapport et des ticekts.

La figure 4.16 pr´esente le rapport g´en´er´e par SonarQube.

FIGURE 4.16 – Rapport SonarQube

La figure 4.17 pr´esente les Tickets cr´e´es par SonarQube.

Nature de tickets : des commentaires inutiles, ancienne m´ethode, duplication du
code, manques des titres html, hors norme ...

4
 4.6. R´ealisation : mettre en place le

FIGURE 4.17 – Tickets

4.6.3 SonarQube & Redmine

Pour rendre les tickets lisibles pour toute l’´equipe (invit´e, QA et d´eveloppeur) il
faut les publier sur Redmine.
Nous avons ajout´e l’api de Redmine dans sonarqube pour assurer la liaison et la
cr´eation des tickets d´etect´es.
Lors du lancement du scan une user Story va ˆetre cr´e´e automatiquement dans le projet Redmine
contenant
tous les tickets d´etect´es par Sanarqube, chaque ticket contient une petite description d
´etaill´ee du bug. A` la fin de chaque scan l’api va cr´eer des nouveaux tickets et
modifier le statut des anciens tickets (rouvrir, fermer le ticket).
La figure 4.18 pr´esente la liaison entre SonarQube et Redmine

FIGURE 4.18 – Liaison SonarQube et Redmine

La figure 4.19 pr´esente l’Use Story cr´e´e sur Redmine

4
 4.6. R´ealisation : mettre en place le

FIGURE 4.19 – User Story

La figure 4.19 contient les tickets cr´e´es sur Redmine

FIGURE 4.20 – Ticket Redmine

4.6.4 Jenkins & Zulip

Apr`es la cr´eation des tickets il faut notifier l’´equipe par un message Zulip.
Pour assurer la publication du message il faut faire la liaison entre les deux outils en
ajoutant l’api key, le lien de l’application zulip et le nom de la room dans Jenkins.

4
 4.6. R´ealisation : mettre en place le

FIGURE 4.21 – Liaison Jenkins et Redmine

La figure 4.25 contient le message Zulip

FIGURE 4.22 – Message Zulip

4.6.5 Jenkins & Selenium

Pour ex´ecuter les tests automatis´es il faut faire la liaison entre selenium et Jenkins.
Nous avons clon´e le projet tests dans Jenkins en ajoutant le lien du projet. Puis nous

4
 4.6. R´ealisation : mettre en place le
avons lanc´e les tests en utilisant la

4
 4.6. R´ealisation : mettre en place le

commande ”dotnet test”.

FIGURE 4.23 – Selenium Jenkins

4.6.6 Ticket redmine

Apr`es l’ex´ecution des tests automatis´es avec Jenkins nous allons envoyer le rapport
g´en´er´e par sele- nium vers un API d´evelopp´e par la soci´et´e bilog cet API permet
de g´en´erer des tickets Redmine `a partir d’un rapport HTML.

FIGURE 4.24 – Cr´eation des tickets de bugs

4.6.7 D´epoiement du projet

La derni`ere ´etape de votre pipeline sera le d´eploiement de notre projet sur Docker.

4
 4.7. Conclusion

FIGURE 4.25 – Deploiement du projet sur Docker

4.7 Conclusion
Au cours de ce sprint nous avons termin´e la mise en place et la configuration de notre chaine.
Avec ce chapitre, on clˆoture le d´eveloppement et notre release est prˆete.

5
 Conclusion g´en´erale &

Le but de ce projet de fin d’´etudes effectu´e au sein de la soci´et´e BILOG est de

mettre en place une plateforme qui assure l’automatisation de cycle de vie d’un projet d
´eveloppement ainsi que le partage et la diffusion de l’information dans chaque phase
entre les intervenants.

Pour impl´ementer la solution, nous avons tout d’abord identifi´e les besoins de l’entreprise et
lanc´e une
´etude technique sur les diff´erentes technologies pour faire le bon choix des outils. Nous
avons ensuite mis en place les chaines DEVOPS.

Ce projet a ´et´e une opportunit´e pour d´ecouvrir le monde DevOps et maˆıtriser

ses outils et ses tech- nologies et avoir une formation th´eorique et pratique dans la m
´ethodologie agile Scrum.

A` l’issue de ce projet, nous pouvons envisager plusieurs perspectives. En fait, notre plateforme
a ´et´e
appliqu´ee sur une application web afin d’automatiser la phase audit qualit´e code
source, tests automa- tis´es, build et d´eploiement ainsi que la diffusion de l’information
dans l’outil chat et la cr´eation des tickets bugs. Nous pouvons envisager d’appliquer
cette solution sur les projets desktop et mobile.

5
 Bibliograp

[1] http ://www.bilog.fr/

[2] https ://www.iso.org/fr/iso-9001-quality-management.html

[3] http ://qualitadmin.blogspot.com/2012/12/la-qualite-selon-crosby.html

[4] https ://www.ibm.com/fr-fr/products/ibm-engineering-test-management/

[5] https ://latavernedutesteur.fr

[6] https ://agiliste.fr/guide-de-demarrage-scrum/

[7] https ://www.journaldunet.com/web-tech/developpeur/1206361-devo

[8] https ://www.valnaos.com/formation/framework-scrum/

[9] https ://blog.myagilepartner.fr/index.php/2018/07/24/le-dsdm-et-le-scrum/

[10] https ://www.alibabacloud.com/fr/knowledge/difference-between-container-and-virtual-machine