Présentation de l’organisme d’accueilrime.emi.ac.ma/ressources_numériques/Mise en place... ·...

SOMMAIRE

Introduction .......................................................................................................................... 1

Chapitre I : CONTEXTE DU PROJET ............................................................................. 2

1. Présentation de l’organisme d’accueil ............................................................................ 3

2. Système intégré de taxation ............................................................................................ 3

3. Tierce Maintenance Applicative du SIT ......................................................................... 5

4. Problématique ................................................................................................................. 6

5. Objectifs du projet ........................................................................................................... 7

6. Démarche suivie pour la conduite du projet ................................................................... 8

Chapitre II: Spécifications fonctionnelles et conceptuelles de la plateforme IC .......... 10

1. Intégration continue : Définition et processus .............................................................. 11

1.1. Définition de l’intégration continue ....................................................................... 11

1.2. Processus d’intégration continue ........................................................................... 11

2. Spécifications fonctionnelles et conceptuelles de la plateforme ................................... 13

2.1. Spécifications fonctionnelles et conceptuelles de la plateforme ............................ 13



a. Processus de suivi des bugs et qualification des performances ................................ 17

b. Processus de mise à jour et build de versions de code source .................................. 17

c. Processus de réalisation des builds d’intégration ...................................................... 18

d. Processus global d’intégration continue .................................................................. 19

Chapitre III : Etude des composants de la plateforme et solution composée .............. 21

1. Outils de gestion et contrôle des versions ..................................................................... 22

2. Outils de tests automatisés et d’exécution des builds ................................................... 24

3. Outils de suivi et qualification des performances ......................................................... 28

4. Outils de gestion de bugs .............................................................................................. 30

5. Serveurs d’intégration continue .................................................................................... 31

6. Architecture logicielle de la plateforme proposée ........................................................ 32

Chapitre IV: Implémentation de la plateforme IC ....................................................... 34

1. Configuration de serveur d’intégration Hudson ........................................................... 35

2. Configuration et migration vers l’outil de gestion et contrôle de versions SVN .......... 35

3. Configuration des tests unitaires,fonctionnels,performances ....................................... 36

4. Automatisation de la gestion des bugs .......................................................................... 42

5. Configuration des outils de suivi et qualification des performances ............................ 44

Conclusion ........................................................................................................................... 51

Bibliographie

Annexe A: Standard BPMN

Annexe B: Ecrans de configuration de Hudson

Annexe C: Scénarios de tests

Annexe D : Migrations des outils

Introduction 2011/2012

Projet de Fin d’Etudes Page 1

Introduction

La méthodologie de développement et de maintenance d’une application a une

incidence directe sur sa qualité et sa performance. Dans ce contexte, l’industrialisation des

processus métier est aujourd’hui un concept qui permet de garantir un maximum de profit.

C’est dans ce cadre que notre projet de fin d’étude vise à mettre en place une plateforme

d’intégration continue au sein du service Développement de la Direction générale des impôts,

organisme d’accueil. La Direction dispose, en effet, d’un système d’intégration fiscal qui,

d’une part, devrait être continuellement amélioré pour répondre aux attentes de la Direction et

des contribuables, et d’autre part, pourrait comprendre des anomalies qui devraient être

corrigées. Le processus de maintenance actuel s’avère lent et complexe. Le but de notre projet

est ainsi d’améliorer la qualité de ce processus et celle du système en question et ce tout en

réduisant les coûts en termes de ressources et temps nécessaire pour effectuer les différents

tests.

Notre mission est d’élaborer un environnement d’intégration continue fondé sur un

bechmarking des solutions existantes sur le marché. Le déploiement et le test de la solution

proposée par la réalisation d’un exemple de processus de production logicielle figurent aussi

comme un objectif de ce travail pour valider cette solution.

Le présent rapport comporte quatre chapitres. Le premier chapitre définit le contexte

général du projet. Le deuxième chapitre présente une spécification fonctionnelle et

conceptuelle de la plateforme mise en jeu. Le troisième chapitre constitue une étude

comparative des outils existants sur le marché et qui justifie le choix de ceux s’avérant

appropriés pour l’implémentation de la solution proposée. Le quatrième et dernier chapitre

concerne la mise en œuvre de la plateforme.

Chapitre I : Contexte du Projet 2011/2012


Chapitre I : CONTEXTE DU PROJET

Ce chapitre aborde le contexte général du projet. Il présente d’abord l’organisme

d’accueil et son système d’intégration de taxation (SIT) dont l’amélioration du

processus de maintenance fait l’objet de ce projet. Nous y évoquons par la suite la

problématique, la motivation aussi bien que les objectifs de notre travail. Nous

terminons par présenter la démarche suivie pour la conduite de ce projet.



1. Présentation de l’organisme d’accueil

La Direction Générale des Impôts (DGI) est l’établissement chargé de la mise en

oeuvre de la politique fiscale, conformément aux orientations du Ministre de l'Economie et

des Finances. Elle a pour missions d’exercer des activités relatives à la détermination de

l’assiette de l’impôt (bases sur lesquelles sont prélevés les impôts ainsi que les taxes), le

recouvrement (perception des taxes, des impôts et des droits d’enregistrement et de timbre)

et le contrôle fiscal (vérification des informations du système déclaratif tout en garantissant

les droits des contribuables).

L’administration centrale comprend quatre Directions parmi lesquelles la Direction

des ressources et du système d’information qui fournit aux différentes entités de la DGI

les ressources et l’infrastructure nécessaires au bon déroulement de leurs missions.

Elle est composée de plusieurs divisions parmi lesquelles la division du développement.

Celle-ci a pour mission d’exploiter les nouvelles technologies dans les processus métiers.

Elle est constituée de trois services : le Service de développement de télé service, le

service de la maintenance des applications et le service de développement des applications

qui accueille le présent projet.

Le service de développement des applications est chargé du développement des

applications informatiques utilisées par les différents services ainsi que de la gestion

moderne de l’information de l’administration fiscale en déployant les dernières

technologies informatiques. Ce service fait appel à des prestataires pour mener des projets

de grandes envergures et met également en place des applications développées en interne.

2. Système intégré de taxation

La supervision du domaine de la fiscalité au Maroc incombe à la DGI qui a pour

mission l’imposition et le calcul de l’impôt pour les différents contribuables au niveau du

royaume. Dans ce contexte, la DGI a lancé, dans le cadre de la réalisation de son schéma

directeur informatique et télécommunication (SDIT), le projet Système Intégré de

Taxation (SIT) qui a commencé en 2003. Le but était, d’une part, de mettre en place un

système d’information centré sur le contribuable qui, à la fois, assure la célérité des

traitements et la cohérence des données et d’autre part, de rapprocher la DGI des usagers et

de leur offrir des services de proximité.



SIT constitue, en fait, le résultat du processus d’urbanisation de l’ancien système

d’information de la DGI qui avait pour but de le faire évoluer dans son ensemble afin de

garantir sa cohérence vis-à-vis des objectifs métier, tout en prenant compte des contraintes

externes et internes, et en tirant parti des opportunités en technologies de l’information et

de la communication. Comme illustré sur la figure 1.1, il est fondé sur une architecture

client/serveur et sur l’utilisation d’une base de données orientée client qui permet la

fédération et le partage des données et des dossiers fiscaux des contribuables entre les

gestionnaires concernés du système.

Figure 1.1 Architecture global du SIT

SIT offre une vision d’ensemble de la situation fiscale de chaque contribuable à

travers des fonctionnalités relatives au contrôle fiscal, au recouvrement, aux affaires

juridiques et à l’assiette considérée comme le montre son architecture fonctionnelle

illustrée dans la figure 1.2. En vue d’apporter une aide à l’analyse, la décision et l’action,

SIT facilite aussi les contrôles de cohérence des déclarations des contribuables aussi bien

que la détection d’éventuelles anomalies.

Figure1.2 Architecture fonctionnelle du SIT



3. Tierce Maintenance Applicative du SIT

La Tierce Maintenance Applicative (TMA) est la maintenance appliquée à un

logiciel qui est assurée par une expertise externe. Dans le cas du SIT, sa maintenance a été

confiée à BULL dans le but de le maintenir et l’améliorer tout en préservant son niveau de

qualité. Comme illustré à la figure 1.3, le cycle TMA du SIT est un cycle itératif qui

permet le maintien sous contrôle du système à travers la détection et la correction de ses

défaillances, et ce selon une stratégie de tests. Les utilisateurs du système détectent et

signalent notamment toute anomalie au service SDA qui en informe BULL. Le chef de

projet concerné assigne, ensuite, les différentes tâches de corrections ou d’amélioration aux

développeurs selon leur domaine de compétence. Les corrections ou les améliorations

apportées par les développeurs sont par la suite livrées au service SDA. Le bon de

livraison, comprenant des informations tels que l’objet d’amélioration ou de correction, les

prérequis de déploiement, les scripts de bases de données, la liste des anomalies corrigées

et la liste des évolutions traitées, est ensuite communiqué au service d’exploitation qui

déploie le produit livré sur l’environnement de production. Après vérification du produit

par le responsable du domaine fonctionnel, et sauf en cas de découverte d’éventuelles

anomalies (anomalie bloquante, majeure, mineure, régression, etc.) par le service SDA, les

améliorations ou corrections sont enfin intégrées par BULL. Ce cycle de maintenance est

relativement facilité par l’usage de l’outil de bugtracking Bugzilla qui sert d’interface

d’échange entre les différents intervenants.

Figure 1.3 Cycle TMA du projet SIT



Les demandes de corrections suivent un cycle de vie fondé sur l’état d’avancement

de la demande comme montré dans la figure 1.4. Tout bug est considéré comme ouvert au

moment de sa déclaration. Il est ensuite assigné à un développeur par le chef de projet.

Après traitement par le développeur, il est considéré comme bug résolu. Selon la décision

du responsable fonctionnel chargé de la vérification des corrections, la demande serait

considérée comme correctement résolue ou serait ré-ouverte en cas de problème. Quand

toutes les étapes de corrections sont accomplies correctement, elle passerait à l’état fermé.

Figure 1.4 Cycle de vie d’une demande de bugtracking

4. Problématique

Préserver la qualité du SIT et améliorer sa performance et son efficacité est un

objectif crucial du service SDA. Toutefois, cet objectif est confronté à des problèmes liés

au cycle de maintenance de ce système. Ces problèmes peuvent se résumer dans les

suivants :

Complexité et la lenteur du processus de maintenance : Les tests actuels sont

réalisés de façon manuelle et nécessitent la maîtrise de l’aspect fonctionnel pour

comprendre le bug dans un premier temps puis le corriger par la suite. Le cycle de

maintenance devient donc lent et complexe. Corriger un bug constitue une charge

majeure et coûteuse en termes de temps. A titre d’exemple, 700 bugs ont été déclarés en

2011 et seulement 30 livraisons on été qualifiées.



Nombre élevé d’éventuels bugs et d’itérations à effectuer : Chaque bug risque

de susciter de nombreuses itérations. Cela rend cette opération coûteuse en termes de

ressources humaines aussi bien que matérielles.

Difficulté du suivi du processus de maintenance : Il s’avère notamment difficile

d’établir le suivi des anomalies découvertes et corrections et améliorations apportées.

Cela rend difficile l’analyse et la prise de décisions relatives au processus de

maintenance.

5. Objectifs du projet

Pour remédier aux problèmes évoqués auparavant, il était question de penser à

industrialiser le processus de maintenance en mettant en place une plateforme d’intégration

continue. L’intérêt d’instaurer une telle plateforme au sein du service SDA dérive du

besoin d’améliorer le processus de production logicielle, tout en restant dans un contexte

d’industrialisation informatique qui permet la bonne gestion des ressources internes du

service. Ceci peut être réalisé à travers, notamment, l’automatisation des processus métiers

et la réduction par la suite du temps passé sur la phase des tests. Dans le cadre de cette

perspective, le présent projet a pour objectifs les suivants :

Vérification fréquente du code et de sa bonne compilation : Il s’agit de

l’exécution de builds répétitifs pour s’assurer de la cohérence du projet et la disponibilité

à tout moment d’un exécutable de l’application en utilisant des outils techniques tel que

Ant, Gradle ou encore Hudson.

Réalisation automatique des tests unitaires, fonctionnels et des tests de

performances avant chaque livraison : L’idée est de concevoir des plans de tests pour

les automatiser à l’aide d’outils logiciels tels que JUnit, Sahi, Jmeter.

Traçabilité des dernières modifications du code en lien avec l’ensemble des

anomalies corrigées : Il est question de garder un suivi des modifications apportées au

code par l’utilisation des solutions logicielles comme Hudson, Jira.

Suivi de la qualité du code et couverture des tests : Il s’agit de mettre en œuvre

des outils logiciels qui vérifient la qualité du code, génèrent des rapports à la demande et

proposent une vue globale sur le taux du code testé. On peut citer par exemple Sonar,

Corbertura ou encore PMD.



6. Démarche suivie pour la conduite du projet

Pour mener à bien la réalisation de notre projet, nous avons adopté une démarche qui

consiste à diviser le projet en plusieurs étapes :

a. Cadrage du projet et étude préalable : Il s’agit de la première étape qui a consisté

à mener une étude détaillée de l’existant. Le but était de pouvoir, d’une part,

comprendre le système objet de notre travail et d’autre part, de nous familiariser

avec le contexte du projet qu’est l’intégration continue et dont les notions nous

étaient floues, voire inconnues.

b. Spécifications fonctionnelles et conceptuelles de la plateforme : Nous étions

amenés à cette étape à définir une architecture détaillée des différents

environnements composant le processus d’intégration et qui sont nécessaires pour

aboutir à une solution répondant aux besoins attendus. Nous avons également

élaboré les spécifications conceptuelles de notre plateforme à travers un diagramme

de cas d’utilisation, qui définit les acteurs de notre plateforme, ainsi qu’une

modélisation BPMN des sous-processus métiers faisant partie du processus global

d’intégration continue.

c. Etude comparative des outils composant la plateforme d’IC : Cette étape a

consisté en un survol des outils d’intégration continue existant sur le marché en vue

de les comparer et en choisir ceux appropriés pour implémenter la plate-forme à

mettre en place.

d. Implémentation de la plateforme : Il s’agit de la quatrième étape qui a consisté en

l’implémentation de la solution proposée à travers l’installation des outils logiciels

et plugins nécessaires, ainsi que la réalisation des configurations permettant

l’interfaçage entre les différents outils, puis le déploiement de la plateforme mise

en place et la réalisation de tests.

La planification d’un projet vise en fait à établir des prévisions raisonnables pour la

mise en œuvre des travaux d'ingénierie logicielle et de gestion du projet. Ces prévisions

sont indispensables pour une gestion de projet efficace. C’est dans ce sens que nous avons

réalisé un diagramme de Gantt illustrant le planning de réalisation de notre projet et que

nous représentons dans le tableau 1.1 ci-après pour des raisons de lisibilité.



Phase Tâches Estimation Début Fin Livrable

Cadrage du projet et

étude préalable

Etude de l'existant

Analyse des besoins

Définition des objectifs et

motivations

7%

07/02/12

16/02/12

Rapport de cadrage du

projet.

Spécification

fonctionnelle et

conceptuelle de la

plateforme

Environnements de la

plateforme IC

Spécifications fonctionnelles

de la plateforme

Spécifications conceptuelles de la plateforme

Modélisation BPMN

10%

16/02/12

24/02/12

Dossier des

spécifications

Etude comparative

des composants de la

plateforme

Choix de l'outil SCM

Choix de l’outil de gestion des

builds

Choix des outils de tests

Choix des outils de qualimétrie

Choix du serveur d'intégration

Choix de l’outil de Bugtracking

10%

24/02/12

09/03/12

Rapport de Benshmark

des outils

Implémentation de la

plateforme

Mise en Place de Hudson

Mise en place de SVN

Mise en place de JIRA

Mise en place de SAHI

Mise en place de JMETER

Mise en place des outils

(checkstyle, pmd,

sonar,cobertura)

73%

09/03/12

13/05/12

Rapport technique.

Scripts des tests

fonctionnels

Scripts des tests de

performance.

Tableau 1.1 Planning du projet

Dans ce chapitre, nous avons présenté le contexte général de notre projet en mettant

l’accent particulièrement sur les besoins fonctionnels qui ont poussé le service SDA à

penser de mettre en place une plateforme d’intégration continue. Les spécifications

fonctionnelles de cette plateforme, ainsi que les spécifications conceptuelles feront l’objet

du chapitre suivant.

Chapitre II : Spécifications fonctionnelles et conceptuelles de la plateforme IC 2011/2012


Chapitre II : Spécifications fonctionnelles

et conceptuelles de la plateforme IC

Ce chapitre et réservé aux détails des spécifications fonctionnelles et conceptuelles

de la plateforme IC. Il aborde d’abord le concept d’intégration continue en termes de

terminologie et de processus. Nous y présentons ensuite les spécifications

fonctionnelles associées en dégageant les fonctionnalités, les acteurs et les cas

d’utilisation décrits en UML [1] Nous terminons par la suite par la modélisation du

processus d’intégration au moyen du standard BPMN [2].



1. Intégration continue : Définition et processus

1.1. Définition de l’intégration continue

L'Intégration Continue (IC) est un nom qui a été donné initialement par la

communauté d’XP pour désigner la pratique de génie logiciel visant à accélérer la

livraison des logiciels en réduisant le temps d'intégration des nouvelles mises à jour des

codes sources. Le terme « intégration» englobe un ensemble d’actions que le code subit

avant de déclencher une nouvelle tâche. Ces actions comprennent principalement la

compilation, le test et le déploiement. Le terme « Continue » est utilisé pour référencer une

continuité d’intégration dans un sens de répétition dans des intervalles de temps rapprochés

[3].

En résumé, nous pouvons définir L’IC comme étant la pratique qui permet « d’intégrer »

tout changement appliqué sur un code avant de commencer une nouvelle tâche. Le but est

de connaître à chaque instant l’état du logiciel, d’avoir un exécutable à tout moment et

d’améliorer la qualité et la fiabilité du logiciel.

1.2. Processus d’intégration continue

L’architecture fonctionnelle d’une plateforme d’IC, est généralement constituée de cinq

environnements [4] :

L’environnement de dépôt (repository) : Il permet, d’une part, de centraliser tous

les codes sources relatifs à une application et créés par différents membres de l’équipe de

développement. D’autre part, il assure la gestion et contrôle des différentes versions

développées au cours du cycle de vie de l’application, tout en stockant ces sources au

niveau d’un serveur de contrôle SCM (Source Control Management).

L’environnement de compilation : Cet environnement consistant en une machine

virtuelle ou une machine physique dédiée est réservé aux développeurs qui l’utilisent

pour compiler ou réaliser ce qu’on appelle build de leurs codes source ou de l’application

entière. En intégration, le build dépasse la compilation pour regrouper également des

tâches comme la construction des releases (par exemple, les fichiers JAR, WAR, EAR,

etc.), l’exécution des tests unitaires et tests d’intégration, le déploiement de l’application

sur l'environnement de développement, l’inspection du code (en vue de générer les

métriques de qualité) et la génération des documents et rapports correspondants. Il existe

plusieurs types de builds : le build privé ou build local créé par le développeur sur sa



propre machine, le build d’intégration de jour géré par le serveur d’intégration continue

pour tester l’intégration de tous les codes des développeurs et le build d’intégration de

nuit réalisé pour exécuter tous les tests y compris ceux de performance.

L’environnement de tests : Il permet à travers une machine virtuelle ou une

machine physique dédiée de déployer toute nouvelle version de l’application issue de

l’environnement de développement, en vue de tester ses fonctionnalités par rapport aux

spécifications établies.

L’environnement de pré-production : Il est utilisé pour tester la version finale de

l’application dans un environnement qui doit être le plus possible proche de

l’environnement réel utilisé par le client. Cela permet de réaliser les tests de charge et de

valider la bonne exécution de l’application lors du passage en production.

L’environnement de production : C’est l’environnement final accessible par les

clients.

Comme illustré dans la figure 2.1, le processus d’intégration continue est effectué à travers

ces différents environnements selon les étapes suivantes :

1. Chaque développeur, souhaitant apporter des changements à une partie du code

source, doit commencé par importer (effectuer un check out) une copie de la

dernière version de l’application à partir du repository.

2. Une fois les changements apportés au code source, le développeur doit lancer un

build privé pour s’assurer qu’une une version saine de l’application est conservée.

3. Suite au succès du build privé, le développeur effectue un commit pour exporter la

nouvelle version vers le repository.

4. Grâce à un contrôle régulier du repository, le serveur d’IC détecte l’enregistrement

de la nouvelle version comprenant les changements effectués et l’importe.

5. L’intégrateur lance ensuite un script pour exécuter un build d’intégration.

6. Des feedbacks sont générés par la suite par le serveur d’IC pour avertir les

développeurs du succès ou de l'échec du build. Dans ce dernier cas, ils sont

informés des bugs détectés et doivent procéder à leur correction en reprenant les

étapes de 1 à 3.

7. Suite au succès du build d’intégration, l’application sera déployée dans

l’environnement de pré-production.



8. Des tests fonctionnels et de charge de l’application seront effectués dans

l’environnement de pré-production.

9. L’application pourrait finalement être déployée dans l’environnement de production

pour tester aussi bien que qualifier l’application.

10. En cas de détection de bugs ou de problème de performance, une notification sera

envoyée aux acteurs de l’environnement de compilation et de test.

Figure 2.1 Processus d’intégration continue

2. Spécifications fonctionnelles et conceptuelles de la plateforme :

2.1. Fonctionnalités nécessaires pour l’intégration continue

Dans ce paragraphe, nous précisons les fonctionnalités principales que toute plateforme

d’intégration continue doit assurer. Conformément aux environnements et processus d’IC

expliqué auparavant, ces fonctionnalités sont les suivantes :

La gestion et contrôle de versions : Cette fonctionnalité consiste, d’une part, à

maintenir l'ensemble des versions d'un projet dans un espace de stockage centralisé

(repository), et à gérer, d’autre part, les mises à jour des codes sources effectuées par

chacun de l’équipe de développement afin de conserver une trace des changements

apportés. La gestion de versions repose sur un modèle de fusion de copies locales et

distantes pour remédier à des problèmes d’écrasements des mises à jour et est assuré,

généralement, par un logiciel spécifique de gestion de versions.

http://www.techno-science.net/?onglet=glossaire&definition=1509






L’exécution des builds : Elle désigne la tâche de production de l’application à

partir de l'ensemble des fichiers sources. Cela inclut non, seulement la compilation des

fichiers sources, éventuellement leur regroupement sous forme de fichiers compressés

(Jar, zip, etc.) mais également la production de fichiers d'installation, de mise à jour ou

création de bases de données et la réalisation des tests automatiques. Réaliser des tests

automatiques a pour but de réduire leur durée d’exécution. Il permet également de

garder des détails sur les tests exécutés afin de garantir leur réutilisabilité et faciliter leur

maintenance. Toutes les étapes du build sont généralement automatisées à l’aide de

scripts spécifiques qui sont lancés une fois qu’un changement apporté au code source

est repéré. Par ailleurs, cette fonctionnalité peut être utilisée pour réaliser des builds

locaux ou des builds d’intégration. Ces derniers consistent à fusionner les modules de

l’application réalisés par différents développeurs. Ils comprennent des tests

d’intégration pour garantir la non-régression de l’application et se font au fur et à

mesure du développement de l’application afin de corriger les anomalies à temps.

Le suivi et qualification des performances : Cette fonctionnalité permet de

dégager des métriques concernant l’analyse du code source. Il est possible, par exemple,

de vérifier que les lignes n'excèdent pas une certaine longueur, que les standards de

nommage sont bien respectés et que le code est bien commenté. Il permet également

d’obtenir des rapports d’exécution des tests de performances, des indicateurs sur la

couverture du code et même de pouvoir détecter des codes morts (non-utilisés).

La gestion des bugs : Elle traduit la possibilité d’enregistrer les bugs détectés et

d’obtenir un historique de chaque bug. Cela permet, par exemple, de connaître le

nombre de fois que le bug a été reporté, la personne qui a reporté le bug et le

programmeur chargé de le résoudre. Cette fonctionnalité assure un suivi des bugs et, par

la suite, un gain au niveau de la maintenance.

2.2. Acteurs et cas d’utilisation

Notre étude des besoins spécifiques dans le cas d’intégration continue nous a permis

de dégager quatre principaux acteurs. Comme illustré dans la figure 2.2, ces acteurs

utilisent des cas d’utilisation relatifs à l’ensemble de fonctionnalités que nous avons

présenté dans le paragraphe précédent. Il s’agit des suivants :



Le développeur : Une fois authentifié, il utilise le cas d’utilisation « Gérer les

versions du code » pour importer la dernière version du projet mais aussi pour demander sa

mise à jour après y avoir apporté des changements. Il peut aussi exécuter un build privé et

des tests unitaires tout en ayant la possibilité de consulter les résultats des tests. Il a

également le droit de consulter les bugs détectés suite à l’exécution des builds.

L’intégrateur : Cet acteur utilise, après authentification, le cas d’utilisation

« Exécuter des builds ». Il peut notamment configurer des builds d’intégration, en

définissant les paramètres de compilation et d’édition de l’application et aussi les plans et

scénarios de test, puis lancer ces builds.

Testeur DGI : Il s’agit d’un employé de la DGI qui, après authentification, peut

utiliser les cas d’utilisation « Consultation et suivi des bugs » et « Suivi et qualification des

performances ». Il a notamment pour mission de consulter et analyser les bugs détectés lors

de l’intégration aussi bien que de vérifier et qualifier les performances de l’application

produite. Cela permet de découvrir d’éventuelles anomalies ou dégradations de

performance et de pouvoir contacter les personnes concernées pour les corriger.

L’administrateur : Il utilise le cas d’utilisation « administration du système » pour

gérer les comptes des utilisateurs et leurs droits d’accès aux différents modules de

l’application.

Figure 2.2 Diagramme de cas d’utilisation



2.3. Modélisation du processus d’intégration continue

L’intégration continue constitue un processus métier global qui comporte un

ensemble de sous-processus coopératifs qui consistent chacun en un ensemble d’activités.

Comme nous pouvons bien le dégager à partir des spécifications fonctionnelles présentées

auparavant, ces sous-processus sont principalement : le processus de mise à jour et build de

versions de code source, le processus de réalisation des builds d’intégration et le processus

de suivi des bugs et qualification des performances [5].

Nous modélisons ci-après chacun de ces processus en utilisant la notation BPMN (voir

annexe A). Le choix de BPMN est justifié par le fait qu’il constitue un standard adapté

spécifiquement à la modélisation des processus métier. Son avantage est double. Il fournit,

d’une part, une notation graphique complète permettant de représenter un processus métier

en découplant les informations métiers des informations techniques. Cela constitue un

cadre de travail commun aux analystes métiers et aux développeurs. D’autre part, il

permet un mapping direct des processus modélisés vers des langages d’exécution. Une fois

un processus est modélisé par les analystes métiers et les informations techniques sont

renseignées, il est possible de générer automatiquement, et de manière standard,

l’exécutable de ce processus.

a. Processus de suivi des bugs et qualification des performances

Comme illustré dans la figure 2.3, le processus de suivi des bugs et qualification des

performances est constitué de deux activités principales effectuées par un testeur de la DGI

chargé de cette mission. Quand la DGI dispose d’un projet qui peut faire l’objet

d’intégration continue, ce dernier procède en parallèle au test et qualification des

performances de l’application en question aussi bien qu’à la consultation des bugs détectés.

Ces deux activités peuvent également être effectuées respectivement quand une mise à jour

de version de l’application a été faite dans le cadre de son intégration continue ou une

notification de bug a été reçue. En cas de détection de bugs ou de dégradation de

performance, le testeur DGI en notifie le développeur concerné pour qu’il puisse apporter

les corrections nécessaires. Sa mission ne prend fin que quand le test et l’analyse des

performances de l’application confirment son efficacité.



Figure 2.3 Processus de suivi des bugs et qualification des performances

b. Processus de mise à jour et build de versions de code source

Comme illustré dans la figure 2.4, le processus de mise à jour et build de versions de code

source est constitué d’un ensemble d’activités ou de tâches effectuées par le développeur.

Quand un besoin de changement au niveau de l’application est exprimé, celui-ci procède à

l’import d’une copie de la version du code source, puis le met à jour, exécute les tests

unitaires et lance un build privé de façon itérative jusqu’à ce qu’aucun bug n’est détecté. A

ce moment, il demande d’enregistrer (commit) la copie réalisée. S’il se trouve qu’une

version postérieure a été déjà enregistrée par un autre développeur, il est amené à reprendre

toutes les tâches précédentes, sinon la copie réalisée sera enregistrée et le développeur doit

en notifier l’intégrateur et attendre les résultats d’intégration. En cas de bugs, il doit les

consulter et procéder à nouveau à la mise à jour du code, sinon il doit informer la DGI

qu’une nouvelle version du code comprenant les changements demandés est disponible.

Aussi, sa mission est-elle partiellement terminée en attente de validation de la DGI. Au cas

échéant, il sera appelé à reprendre une autre itération de ce processus pour apporter les

changements demandés.



Figure 2.4 Processus de mise à jour et build de versions de code source

c. Processus de réalisation des builds d’intégration

Comme illustré dans la figure 2.5, le processus de réalisation des builds d’intégration est

constitué de l’activité de paramétrage de builds et la tâche de leur lancement qui sont

effectuées par l’intégrateur. Une fois, ce dernier est informé de l’enregistrement d’une

nouvelle version de l’application, il réalise d’abord les configurations nécessaires comme

la définition des paramètres de compilation et d’édition de liens aussi bien que la définition

des plans et scénarios de tests. Enfin, il lance le build d’intégration. Les résultats seront

notifiés au développeur et à la DGI une fois le build exécuté. Aussi, sa mission prend-t-elle

fin.



Figure 2.5 Processus de réalisation de build d’intégration

d. Processus global d’intégration continue

Dans ce paragraphe, nous présentons le processus global d’intégration continue

regroupant les trois sous-processus présentés auparavant. Le but est de montrer

l’interaction entre ces trois sous-processus. Comme illustré dans la figure 2.6, des

messages sont échangés entre les différents acteurs des sous-processus en question.

Notamment, le testeur DGI doit notifier des bugs ou dégradation de performances

détectées pour qu’il apporte les changements nécessaires. Le développeur doit, de sa part,

informer l’intégrateur de la mise à jour du code source et le testeur DGI de la disponibilité

d’une nouvelle version testée et intégrée. Quant à l’intégrateur, il doit informer le

développeur et le testeur DGI des résultats des builds d’intégration.



Figure 2.6 Processus global d’intégration continue

Dans ce chapitre, nous avons présenté les spécifications fonctionnelles et

conceptuelles d’une plateforme d’intégration continue. Dans la suite, nous présentons une

solution outillée pour l’intégration continue.

Chapitre III : Etude des composants de la plateforme IC et solution proposée 2011/2012


Chapitre III : Etude des composants de

la plateforme IC et solution proposée

Dans ce chapitre, nous présentons un benchmark des outils qui composent une

plateforme d’intégration continue. Ce benchmark est fondé aussi bien sur l’aspect

fonctionnel que sur les avantages et inconvénients de ces outils. Le but est de proposer

finalement une architecture logicielle globale de notre plateforme d’intégration

continue qui prévoit des composants compatibles et coopérants pour réaliser les

fonctionnalités attendues.



La mise en place d’une plateforme d'Intégration Continue (I.C) nécessite le

déploiement d’un ensemble d’outils nécessaires pour la mise en œuvre du processus

d’intégration. Plusieurs outils existent sur le marché. Le choix d’une solution adéquate

dépend des critères à prendre en considération. La complexité de liaison et la

communication entre ces différents outils sont également prises en compte dans nos choix.

Tout au long de ce chapitre, nous présentons un ensemble d’outils selon leurs fonctionnalités

et leur utilité dans le processus d’intégration continue, en commençant par ceux de gestion et

contrôle de versions, d’exécution des « builds » et tests automatisés, de suivi et qualification

des performances et de gestion de bugs, et en finissant par les serveurs d’intégration. La

solution logicielle adoptée est présentée à la fin de ce chapitre.

1. Outils de gestion et contrôle des versions

1.1. Présentation des outils existants

Le modèle le plus utilisé pour la gestion et contrôle de versions dans des

environnements de développement partagés est celui appelé « copier-modifier-fusionner ».

Dans ce modèle, chaque développeur importe sur sa machine la dernière version du

programme résidant dans le « repository ». Ainsi, chaque développeur peut alors travailler,

simultanément et indépendamment, sur une copie privée locale. Le logiciel de gestion de

versions est utilisé par la suite pour fusionner toutes les copies privées. Dans cette section,

nous présentons deux référentiels de gestion de versions les plus utilisés sur le marché, à

savoir SVN et CVS. Ces référentiels utilisent le modèle cité ci-dessus.

CVS est un outil qui permet une gestion efficace des différentes versions d’un projet

logiciel. Cela consiste notamment en des tâches de suivi de l'ensemble des fichiers du projet,

de stockage centralisé du code source sur un serveur et de gestion des accès concurrents. Ce

qui distingue CVS d'autres outils est le fait d’offrir aux développeurs la possibilité d'accéder

en même temps à un même fichier pour le modifier avec une prise en charge des

modifications. Il fonctionne principalement en mode client/serveur. Les données sont

centralisées sur le serveur et ordonnées en modules et les développeurs peuvent les importer

et demander par la suite de prendre en compte les modifications apportées. L'utilisation de

CVS se fait habituellement dans un environnement de type Unix qui permet une installation

et un paramétrage faciles du serveur. Du côté Windows, l'interface graphique

de CVSNT permet de procéder à quelques réglages et lancer les services.



Par ailleurs, SVN est un successeur de CVS. Il permet de centraliser les sources afin

de les rendre disponibles à l'ensemble des développeurs et acteurs d'un projet, et d'assurer un

suivi en conservant un historique des différents fichiers. Les avantages de SVN par rapport à

CVS se résument dans le fait qu’il permet de tracer les versions de répertoires, de fichiers et

des droits sur les fichiers, de renommer un fichier ou un répertoire tout en conservant son

historique, de réaliser des validations de versions (commit) atomiques qui ne sont prises en

considération que si tous les fichiers d’une version sont correctement validés, d’utiliser des

numéros de versions qui concernent une validation et non pas les fichiers eux-mêmes et

enfin d’utiliser le protocole HTTP.

1.2. Comparaison et outil adopté

Dans cette section, nous présentons une comparaison des deux outils cités auparavant

selon un ensemble de critères tirés de la référence [6]. Le résultat de cette comparaison est

illustré par le tableau 3.1.

Critère CVS SVN

License GNU GPL (open source) Apache (open source)

L’atomicité des Commit NON OUI

Préservation de l’historique NON OUI

Fusion intelligente après renommage

ou déplacement d’un fichier

NON NON

Copie de fichiers dans d’autres

emplacements

NON OUI

Propagation du changement d’un

répertoire à un autre

NON OUI via svn-push

Documentation Excellente (disponible sur le net ou sur la

ligne de commande)

Bonne (livre gratuit sur le net)

Facilité d’utilisation OUI Nécessite un module apache2 si on

choisit HTTP comme protocole.

Portabilité Bonne Excellente (clients et serveurs

tournent sous UNIX, WINDOWS et

MAC OS)

Capacité de travailler sur un

répertoire du référentiel

OUI OUI

Suivi des changements non validés OUI OUI

Messages de validation par fichier NON NON, mais les messages de

validations sont envoyés par rapport

à chaque changement.

Interfaces Web OUI (WebSVN, ViewSVN,

SVNBrowser, insurrectionand perl_svn)

OUI (CVSweb,ViewVC, wwCVS)

Interfaces graphiques OUI mais la plupart sont en cours de

développement

OUI ( WinCVS, Cervisia (for KDE),

TortoiseCVS (Windows Explorer

plug-in))

Tableau 3.1 Comparatif entre CVS et SVN

http://dico.developpez.com/html/642-Generalites-CVS-Concurrent-Versions-System.php

http://dico.developpez.com/html/1239-Economie-developpeur.php

http://insurrection.tigris.org/

http://www.osdevel.org/projects/show/16?lang=en



Nous constatons que SVN maintient la plupart des conventions de travail de CVS, y

compris une grande partie de l’ensemble des commandes. Par contre, les améliorations

sont notables par rapport à son prédécesseur. SVN propose, contrairement à CVS, des

commits atomiques, ce qui évite de se retrouver dans un état contradictoire si une opération

sur le repository est interrompue en plein milieu. Il permet également un déplacement ou

renommage de fichiers/répertoires sans en perdre l’historique. Enfin, il donne la possibilité

de définir des permissions d’accès aux différentes parties du repository grâce au protocole

WebDAV, tandis que CVS ne le permet que d’une façon limitée. De ce fait, nous avons

adopté l’outil SVN.

2. Outils de tests automatisés et d’exécution des builds

Les tests de logiciels varient entre tests unitaires, fonctionnels et de performance. Les

tests unitaires sont réalisés pendant la phase de développement et visent des composants

élémentaires du système (appel de méthodes, de services ou de fonctions de base). Les

tests fonctionnels permettent de vérifier l'adéquation du logiciel aux contraintes définies

dans les spécifications. Ils évaluent la réaction du logiciel par rapport à des données

d'entrées représentatives pour vérifier si le programme fait ce qu’il est censé faire. Tandis

que les tests de performance mettent l'application dans des conditions d'utilisation réelles

avec plusieurs utilisateurs effectuant des actions itératives et simultanées pour "stresser"

l'application et déterminer les goulots d'étranglements. Aussi, présentons-nous ci-après les

différents outils de test et leur comparaison selon les types de tests cités.

2.1. Outil de test unitaire JUnit

Les outils de tests unitaires sont utilisés pour appeler directement les méthodes d'une

classe de test stockée dans un fichier de code source. Compte tenu de la nature de code du

projet objet de notre travail et qui est écrit en JAVA, l’outil de test disponible sur le marché

est JUnit [7]. JUnit est une bibliothèque de test unitaire pour le langage Java. Il est intégré

par défaut dans les environnements de développement intégré Java tels

que BlueJ, Eclipse et Netbeans. Cet outil définit deux types de fichiers de tests :

Les TestCase sont des classes Java héritant de la classe junit.framework. Ils

contiennent un certain nombre de méthodes de tests et servent généralement à

tester le bon fonctionnement d'une classe.

Une TestSuite permet d'exécuter un certain nombre de TestCase déjà définis.

http://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement_int%C3%A9gr%C3%A9

http://fr.wikipedia.org/wiki/BlueJ

http://fr.wikipedia.org/wiki/Eclipse_(logiciel)

http://fr.wikipedia.org/wiki/Netbeans



2.2. Présentation et comparaison des outils de test fonctionnel

Les solutions de test fonctionnel les plus utilisées sur le marché sont SAHI,

SELENIUM et WATIR [8]. Dans cette section, nous présentons ces solutions par leurs

avantages et inconvénients comme rapporté dans le tableau 3.2. Le but est de pouvoir les

comparer pour en choisir la plus adaptée à notre projet.

SAHI SELENIUM WATIR

Avantages

1. Supporte plusieurs

navigateurs

2. Comporte son propre

IDE

3. Enregistre et ré-

exécute les tests

4. Connexion

possible à des bases

de données, Excel ou

des fichiers CSV

5. Outil de reporting


systèmes

d’exploitation

2. Comporte son propre

IDE

3. Enregistre et ré-

exécute les tests

4. S’installe en tant que

serveur ou comme

Add-on du navigateur

FireFox.


systèmes d’exploitation

2. API très riche

3. Propose WatiJ pour

les projets Java et WatiN

pour les projets .NET

Inconvénients Interface pas très

conviviale.

Nécessite un API

différent pour chaque

langage de test

Chaque navigateur nécessite

une bibliothèque différente

Tableau 3.2 comparatif des outils de tests fonctionnels

Pour notre projet, nous adoptons Sahi qui est un outil d'automatisation de tests

d’applications Web par injection de javascript dans des pages Web en utilisant un proxy.

Sahi fait abstraction de beaucoup de difficultés et offre un outil d’enregistrement. Il est

indépendant du navigateur et de la plateforme, un point très important dans notre cas

puisque l’application sur la quelle on va tester notre plateforme ne marche que sur le

navigateur Internet Explorer. En outre, il assure une interaction forte avec Java ainsi qu’un

outil de Reporting.

2.3. Présentation et comparaison des outils de test de performance

Les tests de performance peuvent être de plusieurs types, notamment :

Test de charge : utilisé pour simuler un nombre d'utilisateurs virtuels prédéfinis et

valider l'application pour cette charge.

Test de performance : utilisé pour évaluer les temps de réponse utilisateurs et

réseau ainsi que les temps de traitement d’une requête sur le(s) serveur(s).

Test de dégradations des transactions : utilisé pour simuler l'activité

transactionnelle d'un seul scénario fonctionnel pour pouvoir isoler éventuellement les

transactions qui dégradent le plus l'ensemble du système.



Test de stress : utilisé pour simuler l'activité maximale attendue en heures de pointe

de l'application.

Test de capacité et de montée en charge : utilisé pour simuler un nombre

d'utilisateurs sans cesse croissant de manière à déterminer quelle charge limite le

système est-il capable de supporter.

Test aux limites : utilisé pour simuler en général une activité bien supérieure à

l'activité normale pour voir comment le système réagit aux limites du modèle d'usage

de l'application.

Plusieurs outils de test de performance [9] existent, parmi lesquels : TestMaker[10],

JMeter[11], Dieseltest [12]et OpenSTA [13] qui sont parmi les plus connus.

TestMaker est un outil approprié pour tester les applications Web, les systèmes de

courrier électronique (e-mail), les applications basées sur l’architecture SOA (Service

Oriented Architecture) et les applications Java. Il supporte de multiples protocoles

notamment HTTP, HTTPS, SOAP.

JMeter permet de tester les performances (temps de réponse et fiabilité des réponses

aux requêtes) de sites Web, de serveurs FTP, TCP/IP et de services Web, de bases de

données accessibles via jdbc, de scripts Perl et d’objets JAVA (Applets). Il fait partie de la

suite Apache JAKARTA. Il est entièrement écrit en Java, ce qui lui permet d'être utilisé sur

tout système d'exploitation supportant une machine virtuelle Java (JVM).

Dieseltest est un outil de test de charge permettant de simuler plusieurs utilisateurs sur

une application ou un site Web. L'enregistrement des scripts par cet outil est facile et les

résultats sont fournis en temps réel.

OpenSTA est un logiciel dédié aux tests de performance développé en C++. Il permet

de simuler des centaines d'utilisateurs virtuels d’un site ou d’une application Web et de

recueillir ensuite des mesures de performance et des analyses fines du système testé.

Le tableau 3.3 présente les résultats d’une comparaison des outils cités ci-dessus selon

un ensemble de critères liés aux contraintes d’utilisation en termes de simplicité et de

richesse ainsi qu’au contexte de test (nombre d’utilisateurs, protocole prévu, langage

utilisé…). Notre choix s’est porté sur JMeter qui, d’une part, demeure le plus utilisé sur le

marché selon un sondage fait par le site developpez.net [14], et d’autre part, répond à des

contraintes spécifiques de notre projet. Il offre, notamment, des avantages qui consistent

en particulier en la possibilité de faire des tests multithread. Ceci nous permet, d’une part,



de simuler de lourds tests de montée en charge en termes de nombre d’utilisateurs, et

d’autre part, nous offre un mécanisme puissant de génération de résultats sous différentes

formes (arbre de résultats, rapports consolidés, graphes, etc.).

Outil

Critères de comparaison

Langage de

script

Support

multi-

protocoles

Max

d’utilisateurs

Tests

distribués

Support

technique

Génération

de rapports

Pré-requis IHM

OpenSTA

SCL (Script

Control

languages)*

HTTP/S

En fonction

de la

complexité

du script et la

mémoire de

la machine

OUI

Disponible

Automatique

Windows

XP

Simple et riche

en

fonctionnalités

TestMaker

Jpython

*

HTTP,

HTTPS,

SOAP

300-800 OUI Disponible Automatique JDK 1.6

ou plus

Simple et riche

en

fonctionnalités

JMeter

JAVA http, FTP En fonction

de la

complexité

du script et la

mémoire de

la machine

OUI Disponible Automatique JVM 1.4 Simple et riche

en

fonctionnalités

Dieseltest

Fichier

(format

ASCII)

*

http 200 OUI Moins

riche

Automatique Internet

explorer

min

version 5

Moins riche en

fonctionnalités

Tableau 3.3 Comparatif des outils de tests de performances

2.4. Présentation et comparaison des outils d’exécution des builds

Plusieurs outils d’exécution des Builds existent sur le marché. Parmi lesquels, Maven,

Ant, Make/Script, Ivy et Gradle. Nous en présentons et comparons dans cette section

Maven et Ant qui sont les plus privilégiés (40,83% et 38,2%) par les développeurs selon un

sondage sur le site développez.com [15].

Ant est un projet open-source de la fondation Apache. Il repose sur un fichier XML

(build.xml) qui est un ensemble de cibles (ou targets) ayant chacune un rôle bien précis

dans la construction du projet (nettoyage de répertoires, initialisation, compilation et

transfert de fichiers). Chaque cible est décomposée en un ensemble de tâches destinées à

réaliser une opération particulière.

Dans le même contexte, Maven permet de gérer les fichiers de ressources, compiler les

sources Java, compiler et exécuter les tests unitaires, créer le fichier JAR du projet et

déployer le JAR. Toutefois, il n'impose pas de créer un fichier XML décrivant précisément

les tâches que l'on doit exécuter pour construire son projet. Il suffit seulement



de décrire son projet dans un fichier pom.xml (Project Object Model) en spécifiant en

particulier : l'endroit où se situent le code source et les fichiers de ressources, la version de

Java utilisée pour compiler le code source, les dépendances directes du projet, les plugins

utilisés et les rapports techniques demandés. Dans la suite, le tableau 3.4 présente les

avantages et inconvénients des outils Maven et Ant.

Outil Avantages Inconvénients

Ant

Intégré dans la quasi-totalité des IDE

Supporté nativement par les outils d'IC

Large communauté d’utilisateurs

De nombreuses tâches sont disponibles

Facile à prendre en main, relativement intuitif

Flexible

Complexité du script due à l'écriture non

standardisée du XML

Aucun mécanisme de gestion des

dépendances

Création complexe et répétitive d'un

processus complet de création d'un

artefact JAR ou WAR (compilation, tests,

package...)

Maven 2

pom.xml raccourci

Gestion des dépendances, en particulier les

dépendances transitives

Nombreux plugins disponibles

Supporté par la majorité des outils d'IC

Création facile de nouveaux projets grâce aux

archétypes

Complexité d’utilisation dans d’autres

environnements

Complexité de définition des

dépendances

Utilisation excessive de plugins même

pour des tâches simples

Redondance dans le fichier XML

Support des IDE imparfait

Manque de souplesse (difficile de sortir

du cycle de vie par exemple)

Tableau 3.4 Avantages et inconvénients des outils de builds Maven et Ant

Maven et Ant sont tous les deux développés par Apache et ne sont en effet pas des

concurrents. Bien qu'ils aient des fonctionnalités communes, en se basant sur leurs

avantages et inconvénients, nous constatons qu’il est préférable d'utiliser l’un ou l’autre

selon le cas à traiter. Dans notre contexte, nous avons opté pour Ant vu qu’il peut

facilement intégrer des outils de la plateforme IC dans le serveur d’intégration que nous

avons adopté et que nous présentons plus loin.

3. Outils de suivi et qualification des performances

La qualité logicielle ne réside pas uniquement dans le fait d’avoir un logiciel

opérationnel, mais également dans l’évaluation par rapport à des objectifs mesurables de

qualité. Notamment, la qualimétrie logicielle est la discipline qui vise à s’assurer qu’un

code informatique est produit selon des normes établies et mesurables, dans l’optique de

l’optimisation de la performance, de l’efficacité, de la sécurité et de la maintenabilité. La

plupart des outils d’analyse logicielle sont des analyseurs statiques de code qui calculent

des métriques pouvant contribuer à évaluer sa qualité. Ces métriques concernent

principalement la capacité fonctionnelle (capacité des fonctionnalités à répondre aux



besoins des utilisateurs), la fiabilité (performance des résultats indépendamment des

conditions d’exploitation), la facilité d’utilisation, le rendement (rapport entre la quantité

des ressources utilisées et la quantité de résultats délivrés), la maintenabilité (effort réduit

de correction d’erreurs, de localisation de bugs et de transformation) et la portabilité

(facilité de migration vers un nouvel environnement).

De nombreux outils de qualimétrie existent sur le marché [16] et peuvent être distingués

selon leur objectif spécifique. Nous en citons au niveau des tests unitaires, l’outil

Cobertura. Celui-ci permet de vérifier si les tests unitaires établis sont suffisants et

couvrent tous les aspects et parties du code. Au niveau d’analyse de code, nous citons

Checkstyle, PMD et Findbugs qui peuvent être utilisés dans un contexte Java.

Checkstyle permet de faire respecter des standards de codage précis. Il prévoit une liste

assez complète de règles paramétrables (environ 130 règles) pour vérifier par exemple que

les lignes n'excèdent pas une certaine longueur, que la Javadoc est bien présente et que les

standards de nommage sont bien respectés. Il permet aussi d'améliorer l'écriture et la

qualité de son propre code, en indiquant par exemple quelles expressions peuvent être

simplifiées, quels blocs peuvent être supprimés et quelle classe doit être déclarée finale.

Par ailleurs, PMD permet de scanner le code Java à la recherche de problèmes potentiels,

tels que : les bogues possibles, les blocs de code vides, le code "mort" (méthodes privées

ou paramètres non utilisés), les expressions lourdes, les mauvaises utilisations des

opérateurs de boucles et les duplications de code. Quant à Findbugs, il apporte une analyse

assez fouillée de programmes Java et permet de détecter des problèmes assez complexes. Il

informe sur différents aspects tels que l’utilisation de vulnérabilités de certains bouts de

code, la possibilité de perte de performances, la gestion du multithreading et les problèmes

de sécurité. Par ailleurs, au niveau du reporting des résultats, l’outil Sonar se présente

comme un serveur de contrôle de qualité logicielle, développé par la société Hortis. Il

fournit une synthèse des résultats des différents outils de contrôle de qualité et d’analyse de

code utilisés et permet d’évaluer la qualité globale du projet.

L’ensemble des outils de qualimétrie cités précédemment n’ont pas les mêmes objectifs.

Choisir l’un ou l’autre pour notre projet ne serait pas un choix adéquat. Ces outils sont en

fait complémentaires et rien n’empêche de les utiliser tous en même temps. Toutefois,

l’analyse des rapports générés par chaque outil risque d’être coûteuse en temps mais cela

peut être évité par l’utilisation de Sonar qui donne une vue générale sur les différentes

composantes du projet.

http://pmd.sourceforge.net/

http://findbugs.sourceforge.net/

http://www.hortis.ch/



4. Outils de gestion de bugs

Un système de suivi de problèmes (issue tracking system) est un logiciel qui permet

d'aider les développeurs à améliorer la qualité d'un logiciel à travers la gestion des bugs

techniques, fonctionnels et liés au respect des règles de gestion (réglementation). Un

composant majeur d'un tel système est une base de données qui enregistre les

caractéristiques des bugs connus. Ces caractéristiques peuvent inclure le nombre de fois

que le bug a été reporté, sa rigueur, le comportement problématique, et comment le

reproduire ainsi que l'identité de la personne qui a reporté le bug et le programmeur chargé

le résoudre.

De nombreux outils de gestion de bugs existent sur le marché. Le tableau 3.5 [17]

présente les caractéristiques principales de quelques uns parmi les plus connus sur le

marché.

Nom Éditeur Licence Langage de

programmation Base de données Date création

Dernière

version

B-Hive Bee Software Propriétaire PHP MySQL 2008 2012

Bontq Assembla Propriétaire Ruby MySQL 2008

Tuleap Enalean GPLv2 PHP MySQL 2004 2011, v. 4.0.22

Bugzilla Mozilla

Foundation MPL Perl MySQL, Oracle, PostgreSQL 1998 2011, v. 4.1.1

Mantis Bug

Tracker

Multiples

(Contributions

Open Source)

GPLv2 PHP ADOdb (MS SQL Server, MySQL,

PostgreSQL…) 2000 2011, v. 1.2.8

Plain Ticket Turbine

interactive Propriétaire Java MySQL 2011 2012, v. 1.8

Redmine Jean-Philippe

Lang GPLv2 Ruby on Rails MySQL, PostgreSQL, SQLite 2006 2011, v. 1.2.1

TRAC Edgewall

Software BSD Python MySQL, PostgreSQL, SQLite 2006 2010, v. 0.12

Codendi Xerox GPLv2 PHP MySQL 2001 2011, v. 4.3 RC

JIRA Atlassian

Propriétaire

Gratuit pour

usage non

commercial

Java

MS SQL

Server, MySQL, Oracle,PostgreSQ

L

2003 2010, v. 4.4

Flyspray N.R. LGPL PHP MySQL, PostgreSQL 2003 2009, v. 0.9.9.6

The Bug

Genie N.R. MPL 1.1 PHP MySQL, PostgreSQL 2002 2011, v. 3.0.1

Request

Tracker

Best Practical

Solutions,

LLC

GPL Perl MySQL, Oracle, PostgreSQL, SQL

ite

1999

Tableau 3.5 Caractéristiques des outils de gestion de bugs

http://fr.wikipedia.org/wiki/Logiciel

http://fr.wikipedia.org/wiki/D%C3%A9veloppeur

http://fr.wikipedia.org/w/index.php?title=B-Hive&action=edit&redlink=1

http://fr.wikipedia.org/wiki/Bontq

http://fr.wikipedia.org/wiki/Tuleap

http://www.enalean.com/

http://fr.wikipedia.org/wiki/Bugzilla

http://fr.wikipedia.org/wiki/Mantis_Bug_Tracker

http://fr.wikipedia.org/wiki/Mantis_Bug_Tracker

http://fr.wikipedia.org/wiki/Plain_ticket

http://fr.wikipedia.org/wiki/Redmine

http://fr.wikipedia.org/wiki/Trac_(logiciel)

http://fr.wikipedia.org/wiki/Codendi

http://fr.wikipedia.org/wiki/JIRA

http://fr.wikipedia.org/wiki/Flyspray

http://fr.wikipedia.org/w/index.php?title=The_Bug_Genie&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=The_Bug_Genie&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=Request_Tracker&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=Request_Tracker&action=edit&redlink=1



Pour notre projet, nous avons opté pour Jira. Il prévoit d’abord une licence gratuite. En

outre, il peut interagir avec les outils SVN et Hudson qui servent respectivement à la

gestion des versions et l’intégration, et ce par le biais du plugin Hudson JIRA qui facilite

la communication entre le serveur d’intégration Hudson et l’outil de gestion de bugs JIRA.

L’intégration de JIRA est facilitée par les utilitaires d’importation permettant d’effectuer

une migration depuis d’autres outils de bugtracking tel que Bugzilla ou Mantis.

5. Serveurs d’intégration continue

Il existe plusieurs serveurs d’intégration sur le marché. Toutefois, il n’y a pas de

serveurs parfait ni de « meilleur serveur ». Cela dépend de l’environnement d’utilisation et

de l’entreprise ou l’organisme cible. Le tableau 3.6 dresse une comparaison des solutions

disponibles [18] selon un ensemble de critères particulièrement techniques et qui sont dans

notre cas liés aux composants de la plateforme prévue.

CruiseContr

ol

Cruise Anthill

Professional

Anthill Bamboo Hudson LuntBuild

Open Source OUI NON NON OUI NON OUI OUI

Gratuit OUI Version d’essai Pour les projets

libres

OUI Pour les projets

libres

OUI OUI

Nombre de

développeurs actifs

5 - - - 4+ Entre 5 et 10

étendu à 20

(plugins)

3

Support SCM : CVS OUI NON OUI OUI OUI OUI OUI

Support SCM :

Subversion

OUI OUI OUI OUI OUI OUI OUI

Builds parallèles OUI OUI OUI NON OUI OUI OUI

Builds distribués OUI via

contrib

OUI OUI NON OUI OUI NON

Builds manuels

forcés

OUI OUI OUI OUI OUI OUI OUI

Authentification

d’utilisateurs

OUI OUI OUI NON OUI OUI OUI

Fichier de

configuration

XML XML XML NON NON XML NON

Support de ANT OUI OUI OUI OUI OUI OUI OUI

Support de

MAVEN

OUI OUI via la ligne

de commande

OUI NON OUI OUI OUI

Tableau 3.6 Comparaison des serveurs d’intégration

En se référant au tableau 3.6 et tenant compte des choix de technologies faites dans les

chapitres précédents, à savoir l’outil de build Ant et l’outil de contrôle de versions Sahi, en

plus du sondage établi par le site www.developpez.com [19] qui montre que Hudson est le

plus utilisé parmi les serveurs d’intégration continue avec un pourcentage de 31,91%, nous

avons opté pour ce dernier comme serveur d’intégration. En effet, Hudson possède un

support pour Sahi et Ant [20] et se distingue par le nombre de développeurs qui peuvent



travailler en parallèle et qui peut s’étendre jusqu’à 20. En plus, ce serveur est gratuit et est

utilisé après authentification de ses utilisateurs.

6. Architecture logicielle de la plateforme proposée

Dans les paragraphes précédents, nous avons survolé les différents composants d’une

plateforme d’IC utilisés dans le marché et qui concernent les serveurs d’intégration et les

outils de gestion et contrôle de versions, d’exécution des builds et tests automatisés, de

suivi et qualification des performances et de bugtracking. En conclusion de l’étude faite de

ces différents composants et compte tenu des choix des outils pour lesquels nous avons

opté, nous présentons dans la figure 3.1 l’architecture logicielle globale de la solution

proposée. L’orchestre de la plateforme est le serveur d’intégration Hudson qui est en

mesure de communiquer avec tous les autres composants. Aussi, peut-il lancer des tests

automatisés en appelant l’outil de builds et d’automatisation de tests (Ant), grâce à un

ensemble de scripts qui sont configurés dans le serveur d’intégration et qui ont pour rôle de

définir les tâches de build ou de test à exécuter. Hudson permet également de lancer les

outils de tests (Sahi, JMeter et Junit) et de qualimétrie (Sonar). Il permet aussi d’effectuer

un suivi des bugs en assurant la communication avec Jira, et d’assurer le contrôle de

versions en faisant appel à SVN. Or la communication entre Jira et SVN est aussi

obligatoire, vu que l’outil de gestion de build (Jira) doit avoir une traçabilité concernant les

versions des projets. Ceci est dû au fait qu’un bug fait référence à deux versions de code :

la première version contenant le bug et la deuxième version où la correction est apportée.

Figure 3.1 Architecture de la solution logicielle de la solution proposée

Chapitre IV : Implémentation de la plateforme IC 2011/2012


Chapitre IV : Implémentation de la

plateforme IC

La dernière phase de notre projet consiste en la mise en place de la solution logicielle

présentée dans le chapitre précédant. Aussi, ce chapitre présente-il l’implémentation de la

plateforme proposée d’intégration continue qui a consisté après installation de ses

composants en leur configuration en tenant compte des paramétrages nécessaires et

contraintes d’extensions. Nous décrivons ce travail en cinq volets relatifs aux fonctionnalités

du processus d’intégration continue, à savoir le serveur d’intégration et les systèmes de

gestion de versions, de test, de gestion de bugs et de qualimétrie.



1. Configuration de serveur d’intégration Hudson

Pour la configuration du serveur d’intégration Hudson, nous avons suivi trois étapes (voir

Annexe B) :

L’identification des chemins des composants de la plateforme : Etant donné que

Hudson est l’orchestre de la plateforme d’intégration continue devant appeler ses

différents composants, il était nécessaire de préciser les chemins de certains composants

comme Ant et SVN à travers un écran spécifique et les autres composants à travers des

plugins.

La création de profils et attribution de rôles : Il était question à cette étape de créer

d’abord quatre profils correspondant aux acteurs définis dans notre projet :

l’administrateur, le développeur, le testeur et l’utilisateur DGI, ensuite d’autoriser les

utilisateurs à s’inscrire et créer leurs propres comptes avant de définir leurs différents

rôles. Le tableau 4.1 présente les rôles principaux correspondant à chaque profil.

La création de jobs : Il s’agit de créer le nombre de jobs nécessaires correspondant aux

différentes fonctionnalités attendues. Chaque job doit être défini principalement par un

nom et un URL. Pour la gestion et contrôle de versions, à titre d’exemple, nous avons

dû créer un job en précisant l’URL du repository et choisissant la méthode que nous

souhaitons adopter pour le déclenchement des builds (périodique ou suite à une

scrutation de l’outil de gestion de version par Hudson).

Profil Machine esclave Jobs Consultation Gestion de

versions

Configurer Supprimer Créer Supprimer Configurer Lire Build

Admin

Développeur Testeur

Utilisateur

DGI

Tableau 4.1 Profils et principaux rôle correspondant

2. Configuration et migration vers l’outil de gestion et contrôle de versions

SVN

La mise en place de l’outil de gestion et contrôle de versions SVN a consisté en quatre

étapes :

La migration de CVS vers SVN : Etant donné que le Service de Développement

d’Applications au sein de la DGI utilisait avant l’outil CVS qui est une solution moins



performante que SVN, il était nécessaire de migrer d’abord vers SVN au moyen de

l’outil cvs2svn (voir Annexe D).

La création des utilisateurs : Il s’agit d’enregistrer les utilisateurs concernés ainsi que

leurs mots de passe cryptés dans un fichier "passwd" à créer dans le dossier svn.

L’attribution des droits d’accès : Il est question de définir pour chaque utilisateur ses

droits d’accès (en lecture seule, lecture et écriture, etc.) aux dépôts (repositories), et ce

dans un fichier « authz ».

La configuration des projets : Il s’agit de fournir dans un fichier de configuration

« svnserve.conf » des détails sur le projet (nom de dépôt, utilisation de ssl, fichiers

« authz » et « passwd »).

3. Configuration des tests nécessaires

Dans cette section, nous donnons les détails de configuration et de réalisation des différents

types de test prévus : unitaires, fonctionnels et de performance.

3.1 Automatisation et génération du reporting des tests unitaires

La configuration de tests unitaires automatiques a nécessité deux étapes de configuration :

la programmation des tâches de test au niveau d’un script Ant avec intégration de

la librairie JUnit : Nous avons, notamment, dû programmer les différentes tâches de

builds à exécuter tout en programmant également les tâches de tests unitaires

nécessaires et en rajoutant la librairie JUnit parmi les librairies de Ant. La figure 4.1

illustre un exemple d’une tâche de test unitaire programmé au niveau d’un script Ant.

L’intégration de JUnit au niveau de Hudson : Il s’agit de configurer le projet pour

qu’il supporte les tâches Ant à exécuter lors du lancement d’un build et de configurer un

plugin « Publish Performance test result report » pour que Hudson puisse localiser le

fichier XML ou Html des résultats de JUnit. Suite à ces opérations, Hudson devient

capable de lancer des tests unitaires automatiques et d’en générer également le reporting

des résultats. La figure 4.2 illustre les résultats d’un exemple de test unitaire.



Figure 4.1 Script d’automatisation d’une tâche de test unitaire

Figure 4.2 Exemple d’arbre de résultats d’un test unitaires

3.2 Réalisation des tests fonctionnels

a) Configuration des tests fonctionnels automatiques

Pour la réalisation des tests fonctionnels, nous étions amenés à suivre deux phases :

La configuration des tests au niveau de l’outil Sahi : Il s’agit d’enregistrer le scenario

de test en question à travers la fonctionnalité « Record », créer un script (script.sah) qui

va balayer les pages et exécuter les actions selon le scénario indiqué, remplacer les



données de ce script par des variables et enfin construire des fichiers CVS contenant les

jeux de données à considérer.

L’intégration de Sahi avec Hudson : Pour ce faire, nous avons programmé une tâche

au niveau de l’outil Ant en précisant l’URL de la liste des scripts Sahi à exécuter et les

caractéristiques du navigateur (N° du port et type) et ensuite intégré les tests Sahi dans

Hudson en appelant cette tâche. Cette opération permet de déclencher la tâche en

question lors de l’exécution du build du code et d’obtenir par la suite le graphe des

résultats du test.

b) Exemple de test fonctionnel réalisé

Dans cette section, nous présentons un cas de test fonctionnel que nous avons réalisé. Ce test

concerne le transfert du contribuable. Pour le définir, nous avons respecté le cycle suivant :

Analyse du besoin métier : A ce stade, en analysant le fait qu’un contribuable peut

changer le lieu de ses activités et donc le secteur fiscal, nous avons conclu la nécessité

de créer un acte de transfert lié à la fonction « Mise à jour Référentiel de contribuable »

du module de gestion de contribuables.

Spécifications fonctionnelles : A ce niveau, nous avons pu dégager le fait qu’un acte de

transfert passe par trois étapes : la prise en charge de l’acte de transfert, sa validation et

la validation de la réception du dossier physique.

Identification des cas d’utilisation : Selon les spécifications fonctionnelles, trois cas

ont été identifiés, à savoir : Création d'un acte de transfert, Validation de la réception

d’un acte de transfert et Validation de la réception du dossier physique.

Production du plan de test : A cette étape, nous avons défini l’ensemble des tests

nécessaires tout en précisant les champs d’entrée de tests et le résultat attendu.

Identification de l’emplacement du cas cible de test dans la structure fonctionnelle

de l’application : suivant un modèle Top-Down dont les détails sont fournis dans

l’annexe C, le cas cible de notre exemple de test est « Acte de transfert » qui est un cas

d’utilisation de la fonction transfert d’un contribuable du module Gestion de

contribuables faisant partie des assiettes traitées au niveau du projet SIT.

Automatisation du test à exécuter : Pour pouvoir exécuter automatiquement le test

défini, nous avons créé le script correspondant comme illustré dans la figure 4.3.



Figure 4.3 Extrait du script d’un exemple de test fonctionnel

3.3 Réalisation des tests performances

a) Configuration des tests de performance

Pour définir et réaliser les tests de performance, nous avons suivi deux phases :

La définition et configuration des tests au niveau de l’outil Jmeter : Il s’agit de

définir la stratégie et plan des tests (identifier les objectifs, les cas d’utilisation ainsi que

les métriques à superviser), préparer l’environnement des tests et les scénarios de tests

et des données (configurer le plan de charge, développer et variablisier les scénarios de

test) et enfin exécuter les tests pour obtenir les résultats et établir un diagnostic.

L’intégration de JMeter dans Hudson : Pour ce faire, nous avons d’abord installé un

plugin « Performance » disponible dans le gestionnaire de plugins avant d’invoquer une

tâche Ant, chargée de corréler Hudson et JMeter, à travers un script. Ce script contient

le répertoire de JMeter, la tâche devant déclencher les tests ainsi que le format souhaité

des résultats de tests (html). Les rapports de performance (graphiques de temps de

réponse et pourcentages d’erreurs) fournis par JMeter sont ainsi obtenus via Hudson.

b) Exemple de tests de performance réalisés

Dans cette section, nous présentons un exemple de tests que nous avons réalisés. Ce test



concerne le module PVC (Programmation vérification contrôle) du projet SIT. Après avoir

défini le périmètre métier de ce module, nous avons procédé à la définition et création des

scénarios de tests correspondants avant de lancer leur exécution. Notamment, le module en

question prévoit un processus de programmation qui permet de centraliser les demandes de

vérification des contribuables. Il a pour objectif de maintenir une homogénéité en matière de

gestion, traitement et suivi de la programmation des vérifications et d’offrir un système de

sélection des dossiers à soumettre au contrôle fiscal. Pour choisir les scénarios de tests

appropriés, nous avons utilisé des statistiques d'utilisation de l'application (voir Annexe C)

pour découvrir les fonctions fréquentes ou critiques. La figure 4.4 illustre un exemple de

scénarios de tests de performance du suivi de la programmation. La figure 4.5 illustre les

résultats obtenus informant sur la moyenne et la valeur minimale et maximale du temps de

réponse à l’ensemble des requêtes ainsi que le pourcentage de résultats marquant des erreurs.

Figure 4.4 Exemple de scénario de test de performance



Figure 4.5 : Exemple de résultats d’un test de performance

4. Automatisation de la gestion des bugs

Pour automatiser la gestion des bugs, quatre étapes de configuration et paramétrage

étaient nécessaires :

La définition du workflow de résolution de bugs : A ce stade, comme illustré dans la

figure 4.6, nous étions amenés à définir au niveau de l’outil Jira le flux de résolution des

bugs entre les différents acteurs du processus d’IC, à savoir, l’utilisateur DGI, le testeur

et le développeur. Notamment, lorsqu’une anomalie est détectée, l’équipe DGI la

décrit précisément en formalisant la démarche à suivre pour reproduire l’anomalie

(conditions d’apparition), les résultats constatés et les résultats attendus. Aussi,

l’utilisateur DGI peut-il signaler l’anomalie au développeur qui se chargera de la

corriger. Une fois le bug résolu, une vérification de la correction apportée sera effectuée



par le testeur et la résolution du bug sera clôturée par le développeur s’il y a

satisfaction. Enfin, le bug peut être rouvert par l’utilisateur DGI le cas échéant ou s’il

réapparaît de nouveau. Un bug passe en effet par quatre états : ouvert, en progrès

(quand sa résolution est en cours), résolu et rouvert (si la correction n’est pas

satisfaisante ou quand il réapparaît). Un bug résolu se trouve d’abord à l’état

fixé (quand le développeur apporte les corrections nécessaires) puis non

reproductible (quand le développeur ne peut pas reproduire le bug après les

changements effectués) ou dupliqué (si le bug réapparaît après les changements

effectués). Par ailleurs, au cours de la résolution des bugs, le développeur peut créer des

dépendances entre les anomalies et l’ensemble d’acteurs peut visualiser l’historique des

anomalies. Notamment, conserver une vision sur l’avancement du traitement des bugs,

permet à l’équipe DGI de disposer d’indicateurs importants comme le nombre

d’anomalies relevées (par lot de livraison ou par fonctionnalité) qui renseigne sur la

qualité des réalisations, les délais moyens de correction qui donnent une indication sur

la réactivité de la maîtrise d’œuvre, et les délais de clôture (mesurés entre la date de

livraison de la correction et la clôture de l’anomalie) qui informent sur la réactivité de

l’équipe de recette.

Figure 4.6 Workflow de résolution des bugs



La création d’un projet de gestion de bugs au niveau de Jira : Cela consiste à

introduire un ensemble d’informations : détails du projet, types de demande,

workflows définis, autorisations et notifications prévues, etc. Cette opération permet

par la suite aux utilisateurs de créer des demandes de gestion des différents bugs.

La configuration de communication entre Jira et Hudson : Pour ce faire, il a fallu

d’abord introduire l’URL de Jira, l’utilisateur concerné et son mot de passe au niveau

de Hudson, et ensuite, activer l’option accepter les appels d’API à distance dans la

configuration générale de Jira pour que l’utilisateur désigné puisse se connecter à Jira

à travers Hudson. Finalement, la mise à jour des notifications de Bugtracking de Jira

devait être activée.

La migration de l’outil Bugzila vers Jira : A cette étape, nous avons dû migrer de

l’outil utilisé auparavant par la DGI pour la gestion de bug vers l’outil Jira. Plus de

détails sur cette opération sont fournis dans l’annexe D).

5. Configuration des outils de suivi et qualification des performances

L’audit du projet SIT, visant à relever les non conformités existantes du code, est effectué au

sein de la DGI en ciblant deux volets : l’audit par échantillonnage fonctionnel et l’audit par

outillage. Le premier type d’audit porte sur un échantillon de fonctionnalités critiques dans le

but d’évaluer leur respect des règles métier de gestion et des contrôles de données permettant

d’éviter des incohérences de celles-ci, et également la fréquence de leur utilisation qui ne doit

par exemple pas déclencher plusieurs transactions quand un appel unique est suffisant. Le

deuxième type d’audit procède par l’utilisation d’outils informatiques pour analyser le code en

terme de respect de normes de codage, de non redondance, de non complexité, etc. Notre

contribution s’inscrit au niveau de ce deuxième type d’audit. Nous avons notamment procédé à

la mise place et configuration des différents outils de suivi et qualification de performance

nécessaires, à savoir : Corbertura, PMD, Checkstyle et Sonar. Les détails de configuration de

chacun de ces outils sont présentés ci-après.

5.1 Configuration de Corbertura pour l’évaluation des tests

Corbertura est un outil qui permet d’évaluer un test effectué en terme de pourcentage de

code source qu’il couvre. Il détermine quels fragments de code ou quelles méthodes ont été

exécutés et fournit une mesure calculée en évaluant le rapport du nombre de lignes de code

exécutées sur le nombre de lignes total du code source. Pour le configurer, nous avons procédé

à :



La programmation d’une tâche spécifique au niveau de Ant : Cette tâche permet,

après instrumentation des classes compilées et exécution des tests unitaires, de générer

des rapports sur le pourcentage de couverture de code par les tests effectués.

L’intégration de Corbertura et Hudson : Cela a consisté à fournir l’URL de la tâche

Ant programmée au niveau de Hudson. La figure 4.7 illustre un exemple de rapport de

couverture de code généré suite au lancement d’un build.

Figure 4.7 : Rapport de couverture de code source

5.2 Configuration du PMD pour l’évaluation du respect des règles de codage

PMD est un outil qui permet de vérifier le respect d’un certain nombre de règles de codage.

Pour le configurer, nous avons procédé à :

La configuration d’un fichier XML de règles : Ce fichier XML contient un ensemble

de règles dont chacune est l’implémentation du contrôle d’une convention. Nous citons

par exemple la règle consistant à ce que tous les paquetages du projet commencent par

net.



L’intégration du PMD et Hudson : Pour ce faire, nous avons programmé une tâche

Ant qui se charge de lancer PMD une fois qu’un Build est exécuté. La figure 4.8 illustre

le script de la tâche Ant programmée.

Figure 4.8 : Script d’une tâche Ant chargée de lancer PMD

5.3 Configuration de Checkstyle pour l’évaluation du respect de normes de

développement

Checkstyle est un outil qui permet de vérifier le respect d’un certain nombre de normes de

développement. Comme illustré dans la figure 4.9, ces normes concernent la non duplication

du code, l’import des classes et paquets, les conventions de nommage, la non complexité du

code et sa longueur en terme de lignes. Pour l’intégrer avec Hudson, nous avons programmé

une tâche Ant chargée de lancer Checkstyle une fois qu’un build est exécuté. La figure 4.10

illustre le script de la tâche Ant programmée.

Figure 4.9 : Normes de développement vérifiées par Checkstyle



Figure 4.10 : Script d’une tâche Ant chargée de lancer Checkstyle

5.4 Configuration de Sonar pour l’assurance qualité

Les outils d’analyse statique de code (PMD / Checkstyle / Findbugs, etc.) permettent de

contrôler le code source mais pas l’architecture applicative. Sonar s’avère un outil simple

permettant de vérifier la qualité d’une application à un haut niveau d’abstraction en couvrant

plusieurs aspects illustrés dans la figure 4.10. Il utilise en fait les différents outils d’analyse de

code cités précédemment pour extraire les métriques de qualimétrie souhaitées.

Figure 4.11 : Aspects vérifiés par Sonar

Après son installation, nous avons suivi deux étapes pour le configurer :

La programmation d’une tâche spécifique au niveau d’Ant : Cette tâche, dont le

script est illustré dans la figure 4.11, permet de lancer Sonar suite à l’exécution d’un

build.



La configuration du plugin Sonar au niveau de Hudson : Cela a consisté à fournir les

informations suivantes : l’URL du serveur sonar, l’URL de la base de données sonar et

le nom et mot de passe de l’administrateur de sonar. Aussi, suite à l’exécution d’un

build, serait-il possible de visualiser les résultats de test d’assurance qualité au niveau

du tableau de bord de Sonar. Ces résultats, comme illustré dans la figure 4.12,

sont représentés sous forme de chiffres et statistiques renseignant sur le nombre de

lignes de code, le nombre éventuel de violations relevées, le nombre de duplications

ainsi que le niveau de complexité du code. Par ailleurs, la nature des violations

mineures ou majeures relevées serait également explicitée plus amplement à travers une

section Violations Drilldown. Notamment, certaines erreurs détectées peuvent être

visualisées comme illustré dans la figure 4.13.

Figure 4.12 : Script d’une tâche Ant de lancement de Sonar



Figure 4.13 : Exemple de statistiques d’assurance qualité générés par Sonar

Figure 4.14 : Exemple de violations détectées par Sonar



Ce chapitre rapporte en résumé les différentes étapes que nous avons suivies pour

l’implémentation de la plateforme d’intégration continue, en particulier, la configuration des

différents outils d’automatisation des tests fonctionnels et de performance, de gestion de bugs

et de suivi et qualification des performances aussi bien que du serveur d’intégration. Il expose

également des exemples de tests que nous avons réalisés et les résultats obtenus. Nous notons

que l’implémentation de la plateforme d’intégration continue a constitué une tâche technique

délicate. Sa complexité dérive du nombre et de la diversité des outils déployés.

Conclusion 2011/2012


Conclusion et perspectives

Une plateforme d’intégration continue peut considérablement contribuer à

optimiser la qualité logicielle d’une application en rendant ses fonctionnalités plus fiables

et performantes. Grâce à un processus automatique, elle peut également assurer un

déploiement rapide et conforme aux délais des applications aussi complexes qu’elles

soient. Notre projet de fin d’étude s’inscrit dans cette optique. Au terme de notre travail,

nous avons pu définir et mettre en place une plateforme d’intégration continue. Cette

plateforme assure des fonctionnalités d’automatisation de tests, de gestion et contrôle de

versions, de gestion de bugs et de suivi et qualification des performances. Afin de mettre

en place cette plateforme et après avoir établis une étude conceptuelle conforme au

mécanisme standard d’intégration continue, nous avons été amenés d’abord à chercher et

étudier un ensemble d’outils d’intégration continue existant sur le marché afin d’en choisir

ceux adaptés aux besoins et contraintes de notre projet. Notre choix a porté sur les outils

suivants : SVN, Ant, JUnit, Sahi, JMeter, Sonar, Jira et Hudson comme serveur

d’intégration. Cette opération a été conclue par l’installation de l’ensemble de ces outils

mais aussi l’établissement de paramétrages et configurations nécessaires pour assurer la

communication entre ces différents outils. Par ailleurs, en vue de valider la performance de

la plateforme proposée et mise en place, nous avons également procédé à la réalisation de

certains tests. Ces tests ont ciblé un projet de développement réel au sein de la DGI, dans le

but de couvrir toutes les phases d’intégration continue. Cependant, vu les délais accordés à

notre projet, nous n’avons pas eu la possibilité de poursuivre des tests plus poussés.

En conclusion, nous aimerions noter l’intérêt de ce projet qui d’une part, nous était

d’une grande importance puisqu’il nous a permis de travailler sur des aspects aussi bien

théoriques que techniques de l’assurance qualité et d’approfondir nos connaissances en

gestion de projet et de conception de projets réels. D’autre part, nous pensons que ce projet

apporte une solution qui contribuerait à l’amélioration de la qualité et la livraison rapide

des applications développées au sein de la DGI.

En perspective de ce travail, une période d’expérimentation de la plateforme mise

en place est envisagée. Notamment, le projet SIT est un projet énorme avec un contexte

métier assez complexe. Toute faille technique au niveau de la plateforme surgira des

conséquences néfastes, d’où la nécessité de valider sa performance avant de généraliser

son utilisation.

Bibliographie 2011/2012

Projet de Fin d’Etudes

Bibliographie

[1] Concepts d’UML. http://uml.free.fr/. Consulté le 16/02/2012.

[2] Concepts de base du BPMN. http://www.omg.org/news/meetings/workshops/soa-bpm-

mda-2006/00-T4_White.pdf. Consulté le 18/02/2012.

[3] Marc Chatton, « Intégration continue – concepts théoriques », Septembre 2010.

[4] Document sur l’intégration continue.

http://jfdidgeridoo.wordpress.com/2011/04/04/lintegration-continue/. Consulté le

20/02/2012.

[5] Processus d’intégration continue.

https://wiki.nci.nih.gov/display/Suite/The+Suite+2.0+Continuous+Integration+Architectu

re. Consulté le 23/02/2012.

[6] Comparaison entre les outils de gestion et contrôle de versions. http://better-

scm.shlomifish.org/comparison/comparison.html. Consulté le 24/02/2012

[7] Pourquoi JUnit. http://www-igm.univ-mlv.fr/~dr/XPOSE2003/JUnit_tour/. Consulté le

26/02/2012.

[8] Logiciels de tests fonctionnels. http://stackoverflow.com/questions/606550/watir-vs-

selenium-vs-sahi. Consulté le 28/02/2012.

[9] Outils de tests de performance.

http://fr.wikipedia.org/wiki/Test_de_performance#Acteurs_et_outils_du_march.C3.A9.

Consulté le 02/03/2012.

[10] Présentation de TesMarker. http://sourceforge.net/projects/testmaker/. Consulté le

04/03/2012.

[11] Tutoriel d’utilisation de JMeter. http://blog.milamberspace.net/index.php/jmeter-pages.

Consulté le 04/03/2012.

[12] DieselTest. http://sourceforge.net/projects/dieseltest/. Consulté le 04/03/2012.

[13] Lambert M. Surhone sous la direction de Mariam T. Tennoe. OpenSTA : Webserver

Benchmarking, Apache Bench, Application Center Test.

[14] Comparaison entre des outils d’exécution de tests automatiés.

http://www.developpez.net/forums/d944207/java/edi-outils-java/tests-performance/outils-

test-analyse-performance-charge-utilisez-pourquoi/. Consulté le 06/03/2012.

http://uml.free.fr/

http://www.omg.org/news/meetings/workshops/soa-bpm-mda-2006/00-T4_White.pdf

http://www.omg.org/news/meetings/workshops/soa-bpm-mda-2006/00-T4_White.pdf

http://jfdidgeridoo.wordpress.com/2011/04/04/lintegration-continue/

https://wiki.nci.nih.gov/display/Suite/The+Suite+2.0+Continuous+Integration+Architecture

https://wiki.nci.nih.gov/display/Suite/The+Suite+2.0+Continuous+Integration+Architecture

http://better-scm.shlomifish.org/comparison/comparison.html

http://better-scm.shlomifish.org/comparison/comparison.html

http://www-igm.univ-mlv.fr/~dr/XPOSE2003/JUnit_tour/

http://stackoverflow.com/questions/606550/watir-vs-selenium-vs-sahi

http://stackoverflow.com/questions/606550/watir-vs-selenium-vs-sahi

http://fr.wikipedia.org/wiki/Test_de_performance#Acteurs_et_outils_du_march.C3.A9

http://sourceforge.net/projects/testmaker/

http://blog.milamberspace.net/index.php/jmeter-pages

http://sourceforge.net/projects/dieseltest/

http://www.developpez.net/forums/d944207/java/edi-outils-java/tests-performance/outils-test-analyse-performance-charge-utilisez-pourquoi/

http://www.developpez.net/forums/d944207/java/edi-outils-java/tests-performance/outils-test-analyse-performance-charge-utilisez-pourquoi/

Bibliographie 2011/2012


[15] Comparaison entre des outils d’exécution de builds.

http://linsolas.developpez.com/articles/java/outils/builds/. Consulté le 07/03/2012.

[16] Fabrice Bellingard. Présentation des outils de qualimétrie open source pour Java. Club

Qualimétrie. 2007.

[17] Comparatif des outils de gestion de bugs.

http://www.commentcamarche.net/forum/affich-2510371-outil-de-gestion-de-bug-

cherche-outil. Consulté le 08/03/2012.

[18] Comparatif des serveurs d’intégration.

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix. Consulté le

08/03/2012.

[19] Sondage des meilleurs serveurs d’intégration.

http://www.developpez.net/forums/f1001/general-developpement/conception/usine-

logicielle/integration-continue/. Consulté le 09/03/2012.

[20] Hudson. http://linsolas.developpez.com/articles/hudson. Consulté le 09/03/2012.

http://linsolas.developpez.com/articles/java/outils/builds/

http://www.commentcamarche.net/forum/affich-2510371-outil-de-gestion-de-bug-cherche-outil

http://www.commentcamarche.net/forum/affich-2510371-outil-de-gestion-de-bug-cherche-outil

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

http://www.developpez.net/forums/f1001/general-developpement/conception/usine-logicielle/integration-continue/

http://www.developpez.net/forums/f1001/general-developpement/conception/usine-logicielle/integration-continue/

http://linsolas.developpez.com/articles/hudson

Annexe A: Standard BPMN 2011/2012


Annexe A : Standard BPMN

Un processus métier décrit un ensemble de tâches. Sa modélisation peut être définie comme

la suite des activités métiers et du support d’information. Le Business Process Modeling

Notation (BPMN) est une notation graphique standardisée pour la modélisation des processus

d'affaires dans un workflow. Il constitue un standard récent adapté pour ce faire. Notamment,

BPMN présente certains avantages par rapport à UML quand il s’agit de modélisation des

processus métier. D’une part, il offre une modélisation technique des flux de processus qui est

plus propice. D’autre part, il s'adresse en principe aux analystes business, alors qu'UML

s'adresse plutôt aux développeurs pratiquant de la programmation objet. BPMN permet aussi

de passer rapidement de la théorie à la pratique. En effet, une fois la modélisation d’un

processus est validé par simulation, il est possible de générer l’exécutable opérationnel de ce

processus.

Nous présentons, dans le tableau ci-après, certaines notations de base utilisées dans BPMN :

Type Nomenclature Signe Description

Activité

Représente une tâche exécutée dans

un processus métier.

Evénement

Représente un fait qui peut se

déclencher lors d’un processus métier

et qui peut causer un déclenchement

d’une autre activité.

Passerelle (Gateway) Les passerelles sont des éléments de

de contrôle de la séquence de flux

d’activités.

Sequence Flow

Message Flow

Association

Montre l’ordre dans lequel les

activités seront menées.

Représente le flux de messages entre

les entités.

Permet d’associer les informations et

les artefacts avec les « Sequence

Flow ».

Flows

Objects

Connecteur

s

Annexe B: Configuration de Hudson 2011/2012


Annexe B : Ecrans de configuration de

Hudson

Configuration d’outils à intégrer à Hudson

Autorisation de l’inscription des utilisateurs

Annexe B: Configuration de Hudson 2011/2012


Gestion des rôles de l’utilisateur « Admin »

Exemple de création du job « projet SIT »

Choix de l’option de déclenchement des builds

Annexe C: Scénarios de tests 2011/2012


Annexe C : Scénarios de tests

1) Les scénarios de tests fonctionnels du module Assiette :

Référence libelle pré requis

CMJ-CR-01

Création d'un acte de

transfert avec toutes

les conditions

requises

•Gestionnaire assiette

•Contribuable faisant partie des US de restriction de

l'utilisateur

CMJ-CR-02


transfert manquant

d'un ou plusieurs

champs



l'utilisateur

CMJ-CR-03


transfert en saisissant

une date de

déclaration antérieure

à la date de transfert



l'utilisateur

CMJ-CR-04

créer un acte de

transfert pour un

contribuable ne

faisant pas partie des

US de restriction du

gestionnaire


•Contribuable ne faisant pas partie des US de restriction

de l'utilisateur

CMJ-CR-05

créer un acte de

transfert pour un

contribuable ayant un

acte de transfert pré-

validé


•acte de transfert pré-validé


l'utilisateur

CMJ-VRT-01

Validation de la

réception du transfert

manquant d'un ou de

plusieurs champs

obligatoires •Gestionnaire assiette

•Acte de transfert pré-validé

CMJ-VRT-02

Validation de la

réception du transfert

réussie •Gestionnaire assiette

•Acte de transfert pré-validé

CMJ-VRDP-01

Validation de la

réception du dossier

physique manquant

d'un ou de plusieurs

champs obligatoires •Gestionnaire assiette

•Réception de l'acte de transfert validé

CMJ-VRDP-02

Validation de la

réception du dossier

physique réussie •Gestionnaire assiette

•Réception de l'acte de transfert validé

Annexe C: Scénarios de tests 2011/2012


2) Les scénarios de tests de performance du module Programmation :

Domaines Scénarios Définition scénarios

Gestion des

propositions

PGV-GE-CrP Création d’une proposition

PGV-GE-CON Consultation d’une proposition

PGV-GE-MODF Modification d’une proposition

PGV-GE-TL Transfert d’un lot de proposition

Gestion des

connexions

PGV-GC-CrC Création d’une connexion

PGV-GC-MC-IC Modification des informations de la

connexion( nom et description )

PGV-GC-MC-AP Modification de la connexion:Ajout de

proposition avec lien de connexion

PGV-GC-MC-SP Modification de la connexion: Suppression

de proposition avec lien de connexion

PGV-GC-CoC Consultation d’une connexion

Gestion des

monographies

PVC-GM-CrM Création d’une monographie

PVC-GM-CoM Consultation d’une monographie

PVC-GM-SM Suppression d’une monographie

PVC-GM-MM Modification des monographies

Fiche de

renseignement

Batch de chargement des données de la FR

FR-GN Consultation de la fiche de renseignement

Suivi de la

programmation

PVC-SP-GS Génération des statistiques

PVC-SP-OVA Ordres de vérification en attente

(impression)

PVC-SP-DV Dossiers de vérification (impression)

Annexe D: Migration des outils 2011/2012


Annexe D : Migration des outils

L’intérêt de pouvoir effectuer la migration et de pouvoir conserver l’historique du travail

réalisé sur le projet PVC. Un historique important vu que le projet s’est étalé sur une longue

durée. Cette phase de migration doit permettre de conserver l’historique des commits et

des versions précédentes du projet et pouvoir ainsi garder une trace exploitable des différentes

manœuvres exécutées sur l’application.

Le projet PVC dispose initialement du SCM (Source Configuration Management) CVS qui

sert de référentiel pour les codes sources et les ressources de l’application. Son utilisation se

fait à travers le plugin CVS dans l’IDE RAD. Pour la fonctionnalité de bugtracking, on

passera de Bugzilla vers JIRA. Il faudra tenir compte alors de deux contraintes lors de

cette migration :

Migration CVS SVN : Cette migration doit pouvoir garder l’historique des

modifications et les différentes versions stockées sur le référentiel central CVS.

Migration Bugzilla JIRA : Pouvoir retrouver les différents compte crées à

l’intention des utilisateurs et répertorier l’état et le parcours des bugs.

1. Déroulement de la migration de CVS vers SVN:

CVS et SVN sont tous deux des SCM centralisés permettant de partager les sources

d’un projet sur un serveur commun. Ces systèmes constituent donc le pilier principal d’un

environnement d’intégration continue. La migration signifie donc de redéfinir le dépôt de

référence de code source et l’historique des commits du projet d’un environnement vers

l’autre. Pour cela nous serons amenés à utiliser l’outil cvs2svn qui permettra d’effectuer cette

migration tout en garantissant la cohérence des données et la cohérence des référentiels et en

passant par les étapes suivantes :



1. copie des modules CVS dans un répertoire intermédiaire :

$ cd /tmp/cvs

$ mkdir newcvsrepo

$ mkdir newcvsrepo/CVSROOT

$ cp -r /tmp/cvs/oldcvsrepo/projetA newcvsrepo

$ sudo svnadmin create --fs-type fsfs /var/svn/myproject

2. Création du fichier dump contenant les référentiel CVS :

$ mkdir svndump; cd svndump

$ cvs2svn --dump-only /tmp/cvs/newcvsrepo/projetAsudo cvs2svn --existing-

svnrepos -s /var/svn/myproject /var/cvs/myproject

3. Créer le répertoire pour le projet :

$ svn mkdir file:///home/svn/projetA -m "Ajout répertoire pour projetA"

4. Charger le dumpfile avec svnadmin load :

$ cd /tmp/migcvs/svndump

$ svnadmin --parent-dir projetA load /home/svn < cvs2svn-dump

2. Déroulement de la migration de Bugzilla vers JIRA:

Bugzilla et JIRA sont deux outils de bugtracking. Ils répertorient les demandes sous

formes de clés associes au projet. Afin de passer de Bugzilla vers JIRA, nous

pourrons utiliser le plugin de migration installé dans JIRA. Il faut cependant respecter

plusieurs contraintes pour que la migration puisse s’effectuer avec succès.A titre d’exemple,

l’importateur JIRA Plugin nécessite que la base de données Bugzilla soit de type MySQL ou

PostgreSQL.

a. Avant de commencer, il faut sauvegarder les données JIRA.

b. Dans le système Bugzilla, exécuter le bilan de santé de veiller à ce que les

données soient sans erreur.

c. Se connecter à JIRA en tant qu’ utilisateur avec une autorisation globale

d’administration

d. Afficher la page d'administration en cliquant sur le lien Administration dans la barre de

navigation supérieure. Sur le panneau de navigation de gauche, cliquer sur système

d'importation externe, puis sélectionner Bugzilla.

e. Suivre les consignes de l’assistant d’importation.



f. Il faut aussi indiquer la connexion à la base de données Bugzilla

jdbc:mysql:host[:port]/databasename?parameters Enfin Après l’import il est possible

d’ajouter de nouvelles entrées et informations dans JIRA.

Présentation de l’organisme d’accueilrime.emi.ac.ma/ressources_numériques/Mise en place... ·...

Documents

Transcript of Présentation de l’organisme d’accueilrime.emi.ac.ma/ressources_numériques/Mise en place... ·...