Mise en place d`un..

Transcription

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
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.
Projet de Fin d’Etudes
Page 1
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.
Page 2
2011/2012
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é.
Page 3
2011/2012
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
Page 4
2011/2012
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
Page 5
2011/2012
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.
Page 6

2011/2012
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.
Page 7
2011/2012
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é.
Page 8
Phase
Tâches
Cadrage du projet et
 Etude de l'existant
étude préalable
 Analyse des besoins
2011/2012
Estimation
Début
Fin
7%
Livrable
Rapport de cadrage du
07/02/12
16/02/12
projet.
24/02/12
Dossier des
 Définition des objectifs et
motivations
Spécification
fonctionnelle et
conceptuelle de la
plateforme
 Environnements de la
plateforme IC
 Spécifications fonctionnelles
de la plateforme
10%
16/02/12
spécifications
 Spécifications conceptuelles de
la plateforme
 Modélisation BPMN
Etude comparative
 Choix de l'outil SCM
des composants de la
 Choix de l’outil de gestion des
builds
plateforme
 Choix des outils de tests
 Choix des outils de qualimétrie
10%
24/02/12
09/03/12
 Choix du serveur d'intégration
Rapport de Benshmark
des outils
 Choix de l’outil de
Bugtracking
Implémentation de la
plateforme
 Mise en Place de Hudson
 Mise en place de SVN
 Rapport technique.
 Mise en place de JIRA
 Mise en place de SAHI
 Scripts des tests
73%
09/03/12
 Mise en place de JMETER
 Mise en place des outils
13/05/12
fonctionnels
 Scripts des tests de
performance.
(checkstyle, pmd,
sonar,cobertura)
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.
Page 9
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].
Page 10
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
Page 11
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.
Page 12
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.
Page 13

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 :
Page 14

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
Page 15
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é.
Page 16
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.
Page 17
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.
Page 18
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.
Page 19
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.
Page 20
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.
Page 21
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.
Page 22
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
License
L’atomicité des Commit
Préservation de l’historique
Fusion intelligente après renommage
ou déplacement d’un fichier
Copie de fichiers dans d’autres
emplacements
Propagation du changement d’un
répertoire à un autre
Documentation
CVS
GNU GPL (open source)
NON
NON
NON
SVN
Apache (open source)
OUI
OUI
NON
NON
OUI
NON
OUI via svn-push
Bonne (livre gratuit sur le net)
Facilité d’utilisation
Excellente (disponible sur le net ou sur la
ligne de commande)
OUI
Portabilité
Bonne
Capacité de travailler sur un
répertoire du référentiel
Suivi des changements non validés
Messages de validation par fichier
OUI
Interfaces Web
OUI (WebSVN, ViewSVN,
SVNBrowser, insurrectionand perl_svn)
Interfaces graphiques
OUI mais la plupart sont en cours de
développement
OUI
NON
Nécessite un module apache2 si on
choisit HTTP comme protocole.
Excellente (clients et serveurs
tournent sous UNIX, WINDOWS et
MAC OS)
OUI
OUI
NON, mais les messages de
validations sont envoyés par rapport
à chaque changement.
OUI (CVSweb,ViewVC, wwCVS)
OUI ( WinCVS, Cervisia (for KDE),
TortoiseCVS (Windows Explorer
plug-in))
Tableau 3.1 Comparatif entre CVS et SVN
Page 23
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.
Page 24
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
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
Avantages
Inconvénients
SELENIUM
1. Supporte plusieurs
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.
Nécessite un API
différent pour chaque
langage de test
Interface pas très
conviviale.
WATIR
1.
Supporte plusieurs
systèmes d’exploitation
2.
API très riche
3.
Propose WatiJ pour
les projets Java et WatiN
pour les projets .NET
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.
Page 25
 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,
Page 26
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.).
Critères de comparaison
Outil
OpenSTA
TestMaker
JMeter
Dieseltest
Langage de
script
Support
Max
Tests
multid’utilisateurs distribués
protocoles
En fonction
SCL (Script HTTP/S de la
OUI
Control
complexité
languages)*
du script et la
mémoire de
la machine
Jpython
HTTP,
300-800
OUI
*
HTTPS,
SOAP
JAVA
http, FTP
En fonction
OUI
de la
complexité
du script et la
mémoire de
la machine
Fichier
http
200
OUI
(format
ASCII)
*
Support
technique
Génération Pré-requis
de rapports
Disponible Automatique
Windows
XP
Disponible Automatique JDK 1.6
ou plus
Disponible Automatique
Moins
riche
JVM 1.4
Automatique Internet
explorer
min
version 5
IHM
Simple et riche
en
fonctionnalités
Simple et riche
en
fonctionnalités
Simple et riche
en
fonctionnalités
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
Page 27
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
 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
Ant
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
Inconvénients
 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...)
 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
Page 28
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.
Page 29
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
Multiples
Mantis Bug
(Contributions GPLv2
Tracker
Open Source)
PHP
ADOdb (MS SQL Server, MySQL,
2000
PostgreSQL…)
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 2003
L
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 1999
ite
Tableau 3.5 Caractéristiques des outils de gestion de bugs
Page 30
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
Open Source
OUI
Gratuit
OUI
Cruise
NON
Anthill
Professional
NON
Version d’essai Pour les projets
libres
-
5
Nombre de
développeurs actifs
Support SCM : CVS OUI
Anthill
OUI
OUI
-
Bamboo
NON
Pour les projets
libres
4+
Hudson
LuntBuild
OUI
OUI
OUI
OUI
NON
OUI
OUI
OUI
Entre 5 et 10
étendu à 20
(plugins)
OUI
3
OUI
Support SCM :
Subversion
Builds parallèles
OUI
OUI
OUI
OUI
OUI
OUI
OUI
OUI
OUI
OUI
NON
OUI
OUI
OUI
Builds distribués
OUI via
contrib
OUI
OUI
OUI
NON
OUI
OUI
NON
OUI
OUI
OUI
OUI
OUI
OUI
OUI
OUI
OUI
NON
OUI
OUI
OUI
XML
XML
XML
NON
NON
XML
NON
OUI
OUI
OUI
OUI via la ligne
de commande
OUI
OUI
OUI
NON
OUI
OUI
OUI
OUI
OUI
OUI
Builds manuels
forcés
Authentification
d’utilisateurs
Fichier de
configuration
Support de ANT
Support de
MAVEN
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
Page 31
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
Page 32
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.
Page 34
2011/2012
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
Configurer
Admin

Jobs
Supprimer
Créer


Supprimer
Configurer Lire
Build



Développeur
Testeur
Utilisateur
DGI

Consultation











Gestion de
versions



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
Page 35
2011/2012
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.
Page 36
2011/2012
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
Page 37
2011/2012
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.
Page 38
2011/2012
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
Page 39
2011/2012
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
Page 40
2011/2012
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
Page 41
2011/2012
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
Page 42
2011/2012
 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é
à:
Page 43
2011/2012
 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.
Page 44
2011/2012
 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
Page 45
2011/2012
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.
Page 46
2011/2012
 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
Page 47
2011/2012
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
Page 48
2011/2012
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.
Page 49
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.
Page 50
Bibliographie
2011/2012
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-bpmmda-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://betterscm.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-vsselenium-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/outilstest-analyse-performance-charge-utilisez-pourquoi/. Consulté le 06/03/2012.
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-bugcherche-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/usinelogicielle/integration-continue/. Consulté le 09/03/2012.
[20] Hudson. http://linsolas.developpez.com/articles/hudson. Consulté le 09/03/2012.
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
Représente une tâche exécutée dans
Activité
un processus métier.
Représente un fait qui peut
Flows
Evénement
se
déclencher lors d’un processus métier
et qui peut causer un déclenchement
Objects
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
 Montre
l’ordre
dans lequel
les
activités seront menées.
Message Flow
 Représente le flux de messages entre
les entités.
Association
Connecteur
s
 Permet d’associer les informations et
les artefacts avec les « Sequence
Flow ».
Annexe B: Configuration de Hudson
2011/20 12
Annexe B : Ecrans de configuration de
Hudson
Configuration d’outils à intégrer à Hudson
Autorisation de l’inscription des utilisateurs
Annexe B: Configuration de Hudson
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
2011/20 12
2011/2012
Annexe C : Scénarios de tests
1) Les scénarios de tests fonctionnels du module Assiette :
Référence
libelle
CMJ-CR-01
Création d'un acte de
transfert avec toutes
les conditions
requises
CMJ-CR-02
CMJ-CR-03
CMJ-CR-04
CMJ-CR-05
CMJ-VRT-01
CMJ-VRT-02
CMJ-VRDP-01
CMJ-VRDP-02
transfert manquant
d'un ou plusieurs
champs
transfert en saisissant
une date de
déclaration antérieure
à la date de transfert
créer un acte de
transfert pour un
contribuable ne
faisant pas partie des
US de restriction du
gestionnaire
créer un acte de
transfert pour un
contribuable ayant un
acte de transfert prévalidé
Validation de la
réception du transfert
manquant d'un ou de
plusieurs champs
obligatoires
Validation de la
réception du transfert
réussie
Validation de la
réception du dossier
physique manquant
d'un ou de plusieurs
champs obligatoires
Validation de la
réception du dossier
physique réussie
pré requis
•Gestionnaire assiette
•Contribuable faisant partie des US de restriction de
l'utilisateur
l'utilisateur
l'utilisateur
•Contribuable ne faisant pas partie des US de restriction
de l'utilisateur
•acte de transfert pré-validé
l'utilisateur
•Acte de transfert pré-validé
•Acte de transfert pré-validé
•Réception de l'acte de transfert validé
•Réception de l'acte de transfert validé
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
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
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
Gestion des
connexions
Gestion des
monographies
Fiche de
renseignement
Suivi de la
programmation
Batch de chargement des données de la FR
FR-GN
Consultation de la fiche de renseignement
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 :
2011/2012
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 --existingsvnrepos -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
2011/2012
à 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.

Mise en place d`un..

Transcription

Documents pareils

Daedalus Spiff up v1.2 - MetaGames-EU

HUDSON NORD

Plan CHU Sainte

sur la mode à prix ordinaire et de solde pour femme. Jusqu

Mars 2011

Specialiste du lobbying, Maxim Peter rejoint Hudson pour prendre la

Les erreurs de logiciels, le plus cher feu d`artifice de tous les temps

The Roles We Recruit For

David Bâby - Sybille Sasse

7 choses savoir sur bugs bunny - Bugs une production looney tunes