Rapport d`étude

Transcription

Rapport d`étude

Gestion de projets en environnement
Eclipse/SVN/TRAC
Rapport d’étude
Gestion de projets en
environnement Eclipse/SVN/TRAC
RÉSUMÉ
Depuis quelques années, la demande de logiciels par les entreprises est de plus en plus forte. Les logiciels
actuels réalisent des tâches de plus en plus complexes.
La réalisation d’un logiciel actuel nécessite alors plusieurs acteurs avec des profils qui différent : chef de
projets, concepteur, développeur, graphiste, formateur, ergonome...
Pour gérer un projet informatique lorsque plusieurs personnes travaillent de concert, de bons outils s’avèrent
nécessaires.
Ce document est un rapport d’étude sur le potentiel des outils de gestion de projets dans le domaine du
développement de logiciels. L’étude se concentre sur la mise en œuvre de 3 outils informatiques :

Eclipse : un éditeur de codes sources

Apache Subversion : un système de gestion de versions de fichiers

TRAC : un logiciel gérant la communication et le suivi autour d’un projet informatique
Bien que de natures différentes ces outils utilisés ensemble permettent de piloter de façon efficace le cycle
de vie d’un logiciel à partir de la phase de codage.
L’étude a pour objectifs :

De recenser les bonnes pratiques du travail en équipe

De démontrer l’intérêt des outils informatiques dans le développement logiciel

De tester l’efficacité des outils Eclipse, Apache Subversion et TRAC
Un petit projet informatique écrit avec le langage PHP accompagne l’étude théorique. Ce projet permet de
réaliser des essais en conditions réelles sur les outils analysés.
Les résultats de cette étude démontrent l’efficacité de l’environnement Eclipse/ Apache Subversion/TRAC
pour la mise en œuvre de projets informatiques.

La mise en place d’un outil de gestion de versions comme Apache Subversion améliore le partage des
tâches entre développeurs. Un développeur a la liberté de travailler seul. Il peut suivre les évolutions
des autres développeurs par le déploiement d’un dépôt sur Internet. Les branches dans Apache
Subversion apportent la stabilité des logiciels livrés par la création de branches dédiés aux correctifs.

L’environnement de développement Eclipse rassemble tous les outils nécessaires aux développeurs.
Il est compatible avec les nouvelles technologies de développement de logiciels : Apache Subversion,
PHP, gestions de projets, prototypages... Eclipse améliore leurs utilisations en fournissant des
interfaces simples et améliore les échanges entre ces outils.

Bien maîtrisé, le logiciel de gestion de projets TRAC facilite la coordination des acteurs au sein d’un
projet. Le projet est découpé en tâches. La visibilité de ces tâches permet de connaître l’état
d’avancement du projet. L’outil de gestion des tickets assure le suivi des incidents à régler avant les
livraisons.
L’implémentation d’un wiki comme gestionnaire de contenus est moteur pour l’écriture des
documentations d’installation et d’utilisation du programme en cours de développement.
2/55
Rapport d’étude
La mise à disposition de l’environnement Eclipse/Apache Subversion/TRAC pour une équipe de développeurs
pose une base saine pour débuter un projet informatique. Il contraint les acteurs à bien travailler en équipe.
MOTS-CLÉS
Eclipse, Apache Subversion, TRAC, gestion de versions, gestion de projets
3/55
Rapport d’étude
Sommaire
1. Généralités .............................................................................................. 7
1.1. Informations du devoir .......................................................................................... 7
1.2. Mots-clés .......................................................................................................... 7
2. Introduction.............................................................................................. 8
3. Problématiques ......................................................................................... 10
3.1. Problématique dans la phase de codage ................................................................... 10
3.1.1. Difficultés de communiquer en équipe ................................................................... 10
3.1.2. Difficultés d’individualiser les tâches ..................................................................... 10
3.1.3. Perte des compétences une fois le projet effectué .................................................... 10
3.1.4. La chaîne de production est mal organisée .............................................................. 10
3.1.5. Les livraisons ne sont pas stables .......................................................................... 10
3.1.6. Pas de suivi des évolutions ................................................................................. 10
3.2. Problématique de l’environnement de développement ................................................ 11
3.2.1. Trop d’outils de développement........................................................................... 11
3.2.2. Difficultés de manipulations des outils ................................................................... 11
3.3. Problématique dans la gestion de projets ................................................................. 11
3.3.1. Manque de documentations ................................................................................ 11
3.3.2. Difficultés d’accès aux documents du projet ............................................................ 11
3.3.3. Difficultés de suivre l’avancement du projet ............................................................ 11
3.3.4. Difficultés de suivre les problèmes de maintenance ................................................... 12
4. Manipulations ........................................................................................... 13
4.1. Apache Subversion ............................................................................................. 13
4.1.1. Installation et configuration ................................................................................ 13
4.1.2. Création d’un dépôt ......................................................................................... 14
4.1.3. Travail sur la copie locale .................................................................................. 18
4.1.4. Applications des changements ............................................................................. 19
4.1.5. Livraison du projet ........................................................................................... 21
4.1.6. Gestion des conflits .......................................................................................... 23
4/55
Rapport d’étude
4.2. Eclipse ........................................................................................................... 26
4.2.2. Création d'un projet Eclipse ................................................................................ 30
4.2.3. Travail en local ............................................................................................... 32
4.2.4. Applications des changements ............................................................................. 34
4.2.5. Synchronisation de la copie locale ........................................................................ 37
4.3. TRAC ............................................................................................................. 38
4.3.2. Répartition des tâches ...................................................................................... 40
4.3.3. Gestion des incidents ........................................................................................ 41
4.3.4. Mise en place d’un wiki ..................................................................................... 46
4.3.5. Suivi des évolutions .......................................................................................... 47
5. Analyse des résultats .................................................................................. 50
5.1. Outil de gestion de versions ................................................................................. 50
5.1.1. Bonne communication en équipe .......................................................................... 50
5.1.2. Individualisation des tâches possible...................................................................... 50
5.1.3. Les compétences et les communications restent ....................................................... 50
5.1.4. Les livraisons sont stables .................................................................................. 50
5.1.5. La chaîne de production est organisée ................................................................... 50
5.1.6. Suivi des évolutions .......................................................................................... 50
5.2. Environnement de développement ......................................................................... 50
5.2.1. Un seul outil de développement ........................................................................... 50
5.2.2. Facilité de manipulations des outils ...................................................................... 51
5.3. Gestion de projets ............................................................................................. 51
5.3.1. Abondance des documentations ........................................................................... 51
5.3.2. Facilité d’accès aux informations ......................................................................... 51
5.3.3. Simplicité de la gestion d’avancement du projet ....................................................... 51
5.3.4. Suivi des problèmes de maintenance amélioré .......................................................... 51
6. Conclusions ............................................................................................. 53
7. Glossaire ................................................................................................ 54
5/55
Rapport d’étude
8. Références .............................................................................................. 55
6/55
Rapport d’étude
1. GENERALITES
1.1. Informations du devoir
Travaux pratiques n°1
Sujet : gestion de projets en environnement Eclipse/SVN/TRAC
1.2. Mots-clés
Eclipse, Apache Subversion, TRAC, gestion de versions, gestion de projets
7/55
Rapport d’étude
2. INTRODUCTION
Le génie logiciel est l’art de faire de bons logiciels.
Dans le cadre de travaux pratiques, l’environnement de développement Eclipse/Apache Subversion/TRAC est
manipulé. Ces manipulations vont permettre de statuer sur les bénéfices apportés à l’utilisation de ces outils
dans le cadre de la réalisation d’un projet informatique.
La gestion de projets informatiques est difficile. Elle nécessite d’élaborer des principes de génie pour livrer
des projets fiables et économiques.
Les lacunes dans le domaine de la gestion de projets sont multiples et font l’objet du premier chapitre de ce
rapport :
Problématique dans la phase de codage :

Difficultés de communiquer en équipe

Difficultés d’individualiser les tâches

Perte des compétences une fois le projet effectué

La chaîne de production est mal organisée

Les livraisons ne sont pas stables

Pas de suivi des évolutions
Problématique de l’environnement de développement :

Trop d’outils de développement

Difficultés de manipulations des outils
Problématique dans la gestion de projets :

Manque de documentations

Difficultés d’accès aux documents du projet

Difficultés de suivre l’avancement du projet

Difficultés de suivre les problèmes de maintenance
Pour répondre à ces problématiques, les outils suivants ont été identifiés comme pouvant être bénéfiques :

Eclipse : un éditeur de codes sources

Apache Subversion : un système de gestion de versions de fichiers

TRAC : un logiciel gérant la communication et le suivi autour d’un projet informatique
Eclipse :
Eclipse est plus qu’un simple éditeur de codes sources, c’est un environnement de développement intégré
(IDE en anglais) : il regroupe un ensemble d'outils pour le développement de logiciels. En règle générale, un
EDI regroupe un éditeur de texte, un compilateur, des outils automatiques de fabrication, un débogueur et
des connexions aux outils de gestion de versions.
Apache Subversion :
8/55
Rapport d’étude
Apache Subversion est un outil permettant d’historiser les modifications de fichiers d’un projet informatique.
Il facilite la sauvegarde du projet et les manipulations par plusieurs développeurs. Le système propose le
partage des sources de façon centralisée : une seule machine serveur regroupe toutes les sources du projet.
TRAC :
TRAC est une interface Web permettant de gérer et de suivre toutes les actions d’un projet. Il a l’avantage
de pouvoir se connecter à des dépôts Apache Subversion. Il propose des fonctionnalités telles que :
la gestion d’incidents, la gestion de contenus avec un Wiki…
Un projet informatique accompagne les manipulations.
La nature du projet choisit permet d’assurer une démonstration complète de l’analyse de l’environnement de
développement Eclipse/ Apache Subversion/TRAC.
Il s’agit d’un framework écrit avec le langage PHP. Le programme est destiné à aider les développeurs PHP à
implémenter rapidement et facilement un formulaire sur une interface Web. Le projet se nomme Form
Generator.
Le développement du code source est orienté objets.
Le projet informatique se compose d’une API de développement et d’un exemple d’utilisation de cette API.
Les manipulations des outils dévoileront l’ensemble du projet.
Le dépôt réalisé dans le cadre du projet informatique est accessible sur Internet, ainsi que la gestion de projets
TRAC. Les informations d’accès à cette plateforme de démonstration sont disponibles dans les annexes de ce
document.
9/55
Rapport d’étude
3. PROBLEMATIQUES
3.1. Problématique dans la phase de codage
3.1.1. Difficultés de communiquer en équipe

Echanges par mails non interceptés par tous

Réunions de suivis insuffisantes

Informations pas toujours communiquées à tous les niveaux

Les outils de développement sont parfois multiples et pas compatibles entre eux (chaque développeur
a son outil de prédilection)

Difficultés d’avoir les dernières sources réalisées par les développeurs
3.1.2. Difficultés d’individualiser les tâches

La répartition des tâches est difficile car un projet informatique ne peut pas toujours se découper de
manière à ce que chaque développeur puisse travailler en autonomie sur sa partie

Perte de temps lorsqu’il faut fusionner le travail de chacun
3.1.3. Perte des compétences une fois le projet effectué
Aucune constitution de bases de connaissances : un développeur qui reprend le projet doit souvent repartir
de zéro. Les connaissances et compétences se perdent généralement dès lors que la personne en charge part
de l’entreprise.
3.1.4. La chaîne de production est mal organisée

Difficultés à répartir les tâches

Difficultés à fusionner le travail de chacun
3.1.5. Les livraisons ne sont pas stables

Trop de bugs dans les versions livrées aux clients
Cause : la version livrée à un instant T contient à la fois des correctifs de la version précédente et à la fois
des améliorations par rapport à la version précédente. Les améliorations génèrent de nouveaux bugs.

Pas assez de phases de tests
3.1.6. Pas de suivi des évolutions

Difficultés d’énumérer précisément les modifications apportées à un projet

Difficultés de connaître précisément la version du logiciel dans laquelle un changement a été effectué.
10/55
Rapport d’étude
Exemple : un développeur décide d’utiliser une fonction PHP en remplacement d’une autre. On
découvre que le code plante chez un client. Difficultés pour savoir si d’autres clients auront le même
problème si chaque client possède une version différente.

Pas de numéros de versions des logiciels
3.2. Problématique de l’environnement de développement
3.2.1. Trop d’outils de développement

Nécessite plusieurs installations de logiciels

Les mises à jour provoquent des différences de versions de logiciels sur les postes des développeurs

Outils onéreux

Les outils sont trop dédiés à des langages : un outil par langage de programmation.
Exemple : un éditeur par langage de programmation, un compilateur par langage de programmation.
3.2.2. Difficultés de manipulations des outils

Interrogation uniquement possible via une commande shell

Installation sur des systèmes d’exploitation différents
3.3. Problématique dans la gestion de projets
3.3.1. Manque de documentations

Manque de documentations d’installation, d’utilisation et développement
3.3.2. Difficultés d’accès aux documents du projet

Accès difficile aux documents d’un projet : chaque document peut se situer sur un serveur différent
et accessible avec un outil différent.
Exemple : les documents de réponses d’offres sont sur le partage Windows de l’ordinateur du chef de
projets, les coordonnées des clients sont sur l’outil de GRC...

Informations indisponibles si on n’a pas les bons outils (Exemple : client FTP nécessaire pour accéder
à des documents) et informations indisponibles en dehors du travail (Exemple : intranet).

Les documents sont rédigés dans des technologies incompatibles avec d’autres. Difficultés de partager
les documents en plusieurs formats (DOCX, PDF…).
3.3.3. Difficultés de suivre l’avancement du projet

Qui est responsable de cette tâche ?

Quelles sont les évolutions du logiciel dans cette version ?
11/55
Rapport d’étude
3.3.4. Difficultés de suivre les problèmes de maintenance

Difficultés d’avoir une liste exhaustive des problèmes rencontrés. Exemple : le client envoie des mails
à des personnes différentes

Difficultés de suivre l’avancement des corrections de bugs pendant la phase de maintenance

Difficultés de prioriser la correction de certains bugs

Les clients n’ont pas de réponses à leurs demandes de corrections de bugs et ne savent pas dans quels
états d’avancement sont les corrections

Pas de mesures du temps passés à la correction d’un bug

Pas de mesures du temps global passé pour un client sur un projet
12/55
Rapport d’étude
4. MANIPULATIONS
4.1. Apache Subversion
4.1.1. Installation et configuration
Apache Subversion est un logiciel disponible pour plusieurs systèmes d’exploitations :





AIX
Centos Linux
Debian Linux
Fedora Linux
FreeBSD





HP-UX
NetBSD
OpenBSD
Mac OS X
Red Hat Linux




Solaris
SUSE Linux
Ubuntu Linux
Windows
La licence Open Source d’Apache Subversion facilite sa diffusion. Les choix d’installation sont nombreux :

compilation manuelle à partir des sources (serveur)

installation des commandes pour une interface en lignes de commandes (serveur)

installation clé en main des commandes (serveur) et d’une interface visuelle d’administration (client)
Pour les manipulations, le choix s’est porté sur une installation des commandes serveurs sur le système
d’exploitation Windows à partir du package proposé par la société VisualSVN. Ce package VisualSVN est gratuit.
La version des sources Apache Subversion est 1.7.2.
Adresse Web de téléchargement des packages tous systèmes d’exploitations :
http://subversion.apache.org/packages.html#windows
Adresse Web de téléchargement du package VisualSVN :
http://www.visualsvn.com/downloads/
Installation d’Apache Subversion avec le package VisualSVN :
Le téléchargement du package VisualSVN a pour résultat une archive au format ZIP.
Cette archive est décompressée dans le répertoire c:\svn
Il en résulte un répertoire bin contenant l’ensemble des fichiers exécutables en lignes de commandes suivants :

svn.exe : programme client

svnadmin.exe : créé ou modifie un dépôt

svndumpfilter.exe : filtre les flux d’un dépôt

svnlook.exe : explore un dépôt

svnrdump : exporte une copie d’un dépôt sur un serveur distant

svnserve : programme serveur pour la communication avec un dépôt via le protocole svn

svnsync.exe : synchronise une copie d’un dépôt sur un serveur distant

svnversion.exe : explore l’état d’une copie locale
13/55
Rapport d’étude
Liste des fichiers du package VisualSVN
4.1.2. Création d’un dépôt
Dans Apache Subversion les informations relatives aux évolutions des fichiers sont stockées sur un espace.
Cet espace se nomme un dépôt (en anglais : repository).
Le dépôt est généralement installé sur une machine serveur pour en partager l’accès.
Les administrateurs réseaux qui font l’installation du dépôt décident des règles d’accès :

Pour héberger des projets confidentiels, le dépôt est accessible uniquement dans le réseau interne
de l’entreprise.

Pour héberger des projets publics (licences Open Source, communautés sur Internet…), le dépôt est
accessible sur Internet en dehors du réseau interne de l’entreprise.
Un dépôt peut rassembler plusieurs projets de développement. Des règles d’accès différentes peuvent être
appliquées à chaque projet. Ainsi, un même dépôt peut héberger une version gratuite d’un logiciel et sa
version commerciale.
Les règles d’accès sont définies par l’attribution de comptes utilisateurs.
Création du dépôt :
La commande svnadmin permet de créer un dépôt :
14/55
Rapport d’étude
Le dépôt se nomme depot01 et est situé dans le répertoire svn\depots\depot01\ :
Le lancement de la commande a créé un répertoire du même nom que le dépôt. Ce répertoire contient déjà
une arborescence de fichiers :
15/55
Rapport d’étude
Initialisation du dépôt et copie locale :
Une copie locale est un emplacement de travail où sont regroupés les fichiers en cours de développement.
Dans le système Apache Subversion chaque développeur peut avoir son propre espace de travail en local sur
son ordinateur. Les commandes d’Apache Subversion permettent de fusionner et de partager le travail de
chacun.
Le dépôt depot01 va accueillir le projet réalisé pour les manipulations : la librairie PHP Form Generator.
Pour initialiser le dépôt, 3 fichiers sont créés dans un répertoire local :
16/55
Rapport d’étude

formgenerator.php : fichier principal à inclure par les développeurs qui désirent utiliser l’API

form.class.php : contient la classe objet de définition d’un formulaire Web

views.inc.php : contient les fonctions permettant l’affichage du formulaire
La commande svn checkout permet d’initialiser le dépôt :
Cette syntaxe est une URL locale permettant d’atteindre le dépôt :
file:///c|/svn/depots/depot01
Import des fichiers pour initialiser le dépôt :
Les messages retournés par la commande indiquent que les 3 fichiers ont été ajoutés au répertoire projet01.
Numéros de révisions :
Un numéro est associé à chaque modification du système de fichiers d’Apache Subversion.
Ce numéro est attribué à l’ensemble du dépôt et est incrémentiel.
Lorsque le dépôt est vide, le numéro de révision est 0.
Après le premier import des fichiers pour initialiser le dépôt, le numéro de révision est 1.
Synchronisation de la copie locale :
Dans les étapes précédentes, les premières sources du projet ont été placées dans un répertoire local :
C:\Software\Wampserver\www\projet01\
Bien que ce répertoire contienne les sources du projet, il n’est pas synchronisé avec le dépôt. Tant que la
synchronisation n’est pas faite, les modifications futures apportées au dépôt ne pourront pas être importées
dans le répertoire local.
La commande svn checkout permet de synchroniser la copie locale avec le dépôt :
17/55
Rapport d’étude
Afin de vérifier le bon fonctionnement de la synchronisation, le répertoire local a été vidé avant l’opération.
Les 3 fichiers sont réapparus dans le répertoire local : la copie locale est prête et synchronisée avec le
dépôt.
Remarque : sans précisions la copie locale s’est synchronisée automatiquement avec la version la plus
récente des sources du dépôt.
4.1.3. Travail sur la copie locale
La copie locale est créée et synchronisée avec le dépôt. Il est désormais possible de travailler librement sur
les fichiers en local.
Apache Subversion permet d’effectuer toutes opérations sur les fichiers sans en perdre l'historique :
renommage, copie, déplacement, suppression, modification, création...
Voici les commandes les plus courantes :

svn add : créé un fichier

svn copy : copie un fichier

svn delete : supprime un fichier

svn move : renomme ou déplace un fichier

svn mkdir : créé un nouveau répertoire
Pour améliorer la structure de fichiers du projet Form Generator, des sous-répertoires sont créés, des fichiers
sont déplacés et de nouveaux fichiers sont créés :
18/55
Rapport d’étude

formgenerator.php

classes/form.class.php

classes/text.class.php

views/views.inc.php

demos/ex1.php

README.txt
Voici les commandes effectuées sur la copie locale pour avoir la nouvelle structure :
Les sous-répertoires ont été créés directement dans la copie locale, les opérations sur les fichiers sont faites
à la commande.
On peut remarquer que les commandes sur les fichiers ont automatiquement modifiées la structure de la
copie locale.
Remarque : il est conseillé d’effectuer toutes les opérations de renommage et de déplacement via les
commandes d’Apache Subversion. Toutes modifications externes pourraient provoquer des conflits et
empêcher la copie locale de se synchroniser correctement.
4.1.4. Applications des changements
Les modifications précédentes sur la structure des fichiers de la copie locale ont été prises en compte par
Apache Subversion. Cependant tant qu’une confirmation n’est pas faite les fichiers sources du dépôt ne sont
pas modifiés.
Ceci peut se vérifier en créant une nouvelle copie locale. La synchronisation avec le dépôt provoque la
récupération des 3 premiers fichiers (révision 1) :
19/55
Rapport d’étude
La confirmation des modifications s’effectue avec la commande svn commit :
Application des changements :
La validation a fonctionné et a incrémenté le numéro de révision du dépôt à 2.
Mise à jour d’une copie locale :
Le dépôt est désormais en révision 2. Le développeur qui souhaite travailler avec les nouveaux fichiers
importés dans le dépôt va donc mettre à jour sa copie locale.
La commande svn update permet de mettre à jour sa copie locale avec les récentes sources du dépôt :
Mise à jour de la copie locale :
20/55
Rapport d’étude
La mise à jour a fonctionné. La copie locale du deuxième développeur contient désormais les modifications
validées par le premier développeur.
4.1.5. Livraison du projet
La livraison du projet Form Generator consiste à packager les sources du projet dans une archive au format
ZIP. Avant livraison, le développeur qui la prépare doit effectuer ces étapes :

récupérer les dernières évolutions des fichiers sur le dépôt

s’assurer que la dernière révision sur le dépôt est stable
Les branches de dépôt :
Il est commun de travailler avec des branches sur Apache Subversion afin de mieux gérer les évolutions d’un
programme. En effet, un problème récurrent dans la gestion des projets à grande envergure est l’instabilité
des livraisons. Ce problème est la conséquence d’une évolution constante du programme : corrections,
évolutions, ajout de nouvelles fonctionnalités... Il est très difficile pour une équipe de développeurs de livrer
une version stable du projet puisque cela nécessiterait avant la livraison :

de corriger les derniers bugs recensés

de mettre en pause le développement de nouvelles fonctionnalités (les nouvelles fonctionnalités
génèrent de nouveaux bugs)
Une solution est d’utiliser des branches dans Apache Subversion : une branche est un moyen de travailler sur
une copie d’un projet sans en altérer le projet original.
La solution du problème précédent est la création de branches à chaque livraison. Ces branches assurent les
mises à jour correctives du programme pendant que les nouvelles fonctionnalités sont développées dans le
tronc commun.
Ici le schéma expliquant la méthode de branches mise en place pour le CMS open source Ovidentia
(http://www.ovidentia.org) :
21/55
Rapport d’étude
Explications du schéma :
La version 6.5.0 est validée par l’équipe de développement comme stable car elle contient peu de nouvelles
fonctionnalités. Cette version est diffusée sur Internet et une branche PATCHS-6-5-0 est créée.
La branche est une copie de la version stable 6.5.0. Les évolutions effectuées sur cette branche seront
uniquement de nature corrective.
Ainsi au fur et à mesure de l’utilisation de la version 6.5.0 par la communauté Internet, l’équipe de
développement va stabiliser la version 6.5 en appliquant des patchs correctifs. Des versions 6.5.1, 6.5.2
verront le jour sur Internet.
En parallèle, l’équipe de développement ajoute de nouvelles fonctionnalités sur le dépôt principal : HEAD est
un mot-clé d’Apache Subversion pour identifier le tronc commun qui contient les récentes évolutions.
Cette méthode permet d’avoir des versions très stables de programmes, mais elle a une faiblesse : il est
difficile de stabiliser les versions pour créer de nouvelles branches (6.5.0, 6.6.0, 6.7.0…).
Remarque : ici les numéros de versions sont indépendants des numéros de révisions : les numéros de versions
du programme correspondent aux noms des branches.
Livraison du projet :
Pour la livraison du projet PHP, les étapes suivantes sont respectées :

Corrections des bugs pour stabiliser les sources du dépôt

Création d’une branche pour les correctifs futurs
22/55
Rapport d’étude

Mise à jour de la copie locale qui va servir pour l’archive au format ZIP

Réalisation d’une archive au format ZIP avec toutes les sources
Opérations :
La branche « version-1-0-0 » est créée dans le répertoire c:\svn\depots\branches\projet01\ :
Une archive au format ZIP est créée à partir des fichiers de la copie locale mise à jour.
Remarque : la copie locale contient un répertoire nommé .svn contenant des fichiers propres à l’usage
d’Apache Subversion. Ce répertoire ne doit pas être ajouté à l’archive livrée.
4.1.6. Gestion des conflits
Apache Subversion facilite le partage des fichiers et leurs évolutions parallèles : plusieurs développeurs
peuvent modifier les mêmes fichiers sans gêne et sans perte de données.
Pour cela chaque développeur travaille dans sa copie locale, valide ses modifications (commande commit) et
fusionne avec le dépôt (commande update).
Bien que ce système soit intéressant, des conflits peuvent exister.
Les conflits sont dus à la méthode choisie par Apache Subversion pour gérer le travail en parallèle : la méthode
copier-modifier-fusionner. Lorsque deux développeurs travaillent sur le même projet, ils ont tous deux une
copie locale de travail. Ils effectuent leurs modifications sur leurs copies locales puis vont appliquer leurs
modifications sur le dépôt.
La méthode verrouiller-modifier-libérer évite les fusions en empêchant quiconque de modifier un fichier
lorsque celui-ci est déjà en cours de modification. L’empêchement est réalisé par un système de verrou.
La phase de fusion de la méthode copier-modifier-fusionner est la source de plusieurs conflits.
Voici quelques exemples de conflits mineurs :

2 développeurs travaillent dans leurs copies locales sur un même fichier. Un développeur effectue
une modification dans le fichier et la valide sur le dépôt. L’autre développeur ne met pas à jour ses
sources : il travaille donc sur une révision plus ancienne. Lorsque ce développeur voudra valider ses
modifications, le système va l’alerter d’un conflit parce qu’une version plus récente du fichier existe
déjà sur le dépôt.
23/55
Rapport d’étude
La solution est simple : le développeur doit mettre à jour ses sources (commande update) avant de
valider ses modifications. La mise à jour va effectuer une fusion des modifications.

2 développeurs travaillent sur leurs copies locales sur un même fichier dans la même révision. Ils
modifient tous deux la même ligne du fichier avec des valeurs différentes. Un développeur valide ses
modifications sur le dépôt. L’autre développeur va logiquement avoir un conflit au moment où il
voudra lui aussi valider ses modifications. La mise à jour des sources ne va pas résoudre le conflit
(contrairement à l’exemple précédent) car le système Apache Subversion ne pourra pas choisir la
ligne de code appropriée.
La solution est complexe : le développeur doit nécessairement comparer manuellement les
modifications apportées par l’autre développeur et valider le fichier.
Exemple pas à pas d’un conflit :
Un dépôt Apache Subversion est accessible par l’url file:///c|/svn/depots/depot01.
Deux développeurs travaillent sur le même projet :
projet01 du dépôt depot01
Développeur 1
Développeur 2
Le développeur 1 désire une copie locale sur son disque à
l’emplacement c:\dev1\projet01
Le développeur 2 désire une copie locale sur
son disque à l’emplacement c:\dev2\projet01
Le développeur 1 synchronise sa copie locale avec le dépôt :
Le développeur 2 synchronise sa copie locale avec le dépôt :
Le
développeur
formgenerator.php
1
travaille
sur
le
fichier
Le développeur 2 travaille sur le fichier
formgenerator.php
Le développeur 1 modifie la ligne 10 du fichier formgenerator.php : il désire changer l’emplacement d’un
fichier inclut dans le programme.
Puis le développeur 1 valide sa modification sur le dépôt :
24/55
Rapport d’étude
Les sources du dépôt sont désormais en révision 7.
Le développeur 2 modifie la ligne 10 du fichier formgenerator.php : il désire renommer un fichier inclut
dans le programme. Il travaille sur la révision 6 du fichier formgenerator.php :
Puis le développeur 2 valide sa modification sur le dépôt :
Le développeur 2 observe un conflit lors de la validation de sa modification !
Le message retourné par Apache Subversion alerte que le fichier formgenerator.php n’est pas à jour : une
version plus récente existe sur le dépôt.
Le développeur 2 met à jour sa copie locale avec le dépôt :
Le développeur 2 observe un nouveau conflit lors de la mise à jour de sa copie locale !
En effet, le système Apache Subversion n’a pas réussi à fusionner les modifications du développeur 1 car
les modifications des deux développeurs ont été faites sur la même ligne de code. Apache Subversion ne
peut pas décider du bon code.
Apache Subversion propose au développeur 2 plusieurs solutions pour résoudre le conflit :
Le développeur 2 choisit de solutionner ce problème manuellement en comparant son fichier local à celui
du dépôt. Il choisit donc l’option de résolution de conflit ‘p’ qui indique à Apache Subversion que le
conflit sera géré plus tard.
25/55
Rapport d’étude
Le développeur 2 a désormais une copie de chaque révision du fichier formgenerator.php dans sa copie
locale :
formgenerator.php.mine : version en cours de développement par le développeur 2
formgenerator.php.r6 : version correspondant à la révision qui précède la correction du développeur 2 : la
révision 6
formgenerator.php.r7 : version la plus récente sur le dépôt : révision 7
Le développeur 2 compare les versions du fichier formgenerator.php et discute des évolutions avec le
développeur 1. Il est décidé par un commun accord de garder la correction du développeur 1 : révision 7
sur le dépôt.
Le développeur 2 résout le conflit avec la commande svn resolve :
Le conflit est résolu ! Les versions .mine, .r6 et .r7 du fichier formgenerator.php disparaissent de la copie
locale du développeur 2 :
4.2. Eclipse
La plateforme XP-Dev.com :
Le système de gestion de versions Apache Subversion a été testé précédemment sur une installation locale.
Pour les besoins des manipulations suivantes, un dépôt est créé sur la plateforme Internet XP-Dev.com afin de
simuler un vrai projet.
26/55
Rapport d’étude
Le site XP-Dev.com est un service qui propose une gestion complète des projets de développements.
Les services proposés sont les suivants :

Hébergement de dépôts de systèmes de gestion de versions : Apache Subversion, GIT et Mercurial

Interface de gestion partagée

Mise en place de l’outil de gestion de projets TRAC

Mise en place d’un wiki

Mise en place d’un système de suivi des tickets d’incidents

…
L’inscription gratuite aux services propose un hébergement limité :

200 Mo d’espace disque

2 projets référencés au maximum
Les inscriptions payantes fournissent :

des connexions sécurisées avec le serveur

la création sans limite de projets

plusieurs Go de stockage

sauvegarde externe des projets
Création des comptes sur XP-Dev.com :
L’inscription gratuite a été choisie pour ce projet.
Jérôme est l’administrateur du projet.
Pour accéder à la console d’administration du site XP-Dev.com :
Adresse Web : http://xp-dev.com/login
Identifiant : jerome
Mot de passe : glg105
Plusieurs comptes de profils développeurs ont été créés :
Identifiant : guillaume.andre
Mot de passé : glg105
27/55
Rapport d’étude
Identifiant : michel.beige
Mot de passé : glg105
Les permissions d’accès en écriture sur le projet ont été affectées aux 2 développeurs :
Les notifications ont toutes été activées sur le compte principal :
Choix de l’environnement de développement :
Pour les manipulations, le choix s’est porté sur l’environnement de développement Eclipse pour sa
compatibilité avec le langage PHP et le logiciel Apache Subversion.
Eclipse est un environnement de développement complet et libre. Il est programmé avec le langage Java, ce
qui lui permet d’être installable sur plusieurs systèmes d’exploitation.
28/55
Rapport d’étude
Eclipse a été installé sur un système d’exploitation Windows. La version du logiciel Eclipse est 3.6.0.
Il existe plusieurs packages d’Eclipse. Tous proposent des outils spécifiques à des environnements de
développement différents. Le projet Form Generator étant développé avec le langage PHP, le package
Eclipse PDT (PHP Development Tools) a été sélectionné.
Adresse Web de téléchargement d’Eclipse tous systèmes d’exploitation :
http://www.eclipse.org/pdt/downloads/
Installation du plugin Subclipse d’Eclipse :
Après une première utilisation d’Eclipse, on découvre que l’environnement ne permet pas d’accéder à un
dépôt Apache Subversion (uniquement CVS). L’installation d’une extension (plugin) est nécessaire pour
communiquer avec les dépôts Apache Subversion.
Le choix s’est porté sur l’extension Subclipse. Le développement de l’extension est actif (dernière contribution
en juillet 2011).
Adresse Web de téléchargement du plugin Subclipse pour Eclipse :
http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
L’installation de l’extension Subclipse peut se faire directement depuis le logiciel Eclipse en précisant
l’adresse Web du dépôt des sources de l’extension :
http://subclipse.tigris.org/update_1.8.x
Eclipse propose alors d’installer ces composants associés :
Un redémarrage d’Eclipse est nécessaire après l’installation de l’extension.
29/55
Rapport d’étude
Création du dépôt Apache Subversion sur XP-Dev.com :
Pour accueillir notre projet, un dépôt Apache Subversion est créé sur la plateforme Internet XP-Dev.com :
Le dépôt Apache Subversion est privé et se nomme GLG10511.
Le dépôt est accessible à l’adresse Web suivante :
http://xp-dev.com/svn/GLG10511
4.2.2. Création d'un projet Eclipse
L’interface d’Eclipse se présente comme un éditeur de texte. Le package Eclipse PDT propose un explorateur
des projets PHP.
30/55
Rapport d’étude
Pour travailler sur le projet Form Generator, un projet PHP doit être créé sur Eclipse. Ce projet permet la
synchronisation des sources avec le dépôt Apache Subversion. Il permet également l’activation de l’indexation
des sources afin de bénéficier d’une auto-complétion à l’écriture du code.
Ajout du projet PHP dans Eclipse :
Menu File / New / Project : affiche le formulaire de choix du type de projet.
Le type de projet « Checkout Projects from SVN » est sélectionné.
Eclipse garde en mémoire les configurations d’accès aux dépôts.
Une configuration d’accès est définie avec le dépôt présent sur XP-Dev.com. L’exemple reprend la
configuration du développeur Jérôme :
Adresse Web : http://xp-dev.com/svn/GLG10511
Pour travailler uniquement sur le tronc commun du dépôt, le projet Eclipse est synchronisé avec le répertoire
trunc sur la révision HEAD. Le répertoire pourra contenir tous les projets de développement.
31/55
Rapport d’étude
Pour finir, le projet est spécifié comme projet de type PHP. Ceci permet d’activer d’éventuels outils de
développement spécifique au langage PHP :
L’emplacement de la copie locale du dépôt se situe :
C:\Software\Wampserver\www\GLG10511\
Le projet se nomme GLG10511 est se retrouve dans l’explorateur de projets sur Eclipse :
4.2.3. Travail en local
32/55
Rapport d’étude
Tous les développeurs ont configuré leurs environnements Eclipse : chaque développeur peut travailler sur sa
copie en local. L’auteur de chaque modification validée sur le dépôt Apache Subversion sera identifié.
Repérage des modifications sous Eclipse :
L’explorateur de projets PHP facilite la vision des fichiers modifiés. Après une modification rapide de la
configuration de la coloration des fichiers dans l’explorateur, on peut distinguer :

En rouge les fichiers modifiés dans la copie locale

En noir les fichiers non modifiés depuis la dernière mise à jour avec le dépôt
De plus, des icônes sont associées à chaque état des fichiers :

Le point d’interrogation indique un nouveau fichier qui n’a pas encore été validé sur le dépôt

Une étoile indique un fichier modifié qui n’a pas encore été validé sur le dépôt

Le signe + indique un fichier déplacé qui n’a pas encore été validé sur le dépôt
Les icônes d’états apparaissent aussi sur les répertoires :

Le signe + indique un répertoire contenant un fichier déplacé qui n’a pas encore été validé sur le
dépôt

Le point d’interrogation indique un nouveau répertoire qui n’a pas encore été validé sur le dépôt
Réalisation du projet Form Generator :
3 développeurs travaillent sur le projet Form Generator.
La réalisation du code est répartie en 3 parties :

Réalisation de la classe principale de définition d’un formulaire Web

Ecriture des classes associées au formulaire Web : les classes des champs de formulaires (texte, case
à cocher, liste…)

Gestion de l’affichage du formulaire et création d’un exemple d’utilisation de la librairie
Voici des exemples du travail de chaque développeur :
33/55
Rapport d’étude
Jérôme initialise le dépôt avec les premiers fichiers :
Guillaume André modifie la structure des fichiers en ajoutant des sous-répertoires et en déplaçant des
fichiers :
Michel Beige ajoute le répertoire demos et débute le code de l’exemple 1 (fichier ex1.php) :
4.2.4. Applications des changements
Validation des modifications sous Eclipse :
L’extension Subclipse facilite la communication avec le dépôt Apache Subversion.
Pour valider des modifications (commande commit), il suffit de sélectionner les répertoires/fichiers à valider
et d’utiliser le menu déroulant accessible après un clic du droit :
Team / Commit : affiche le formulaire de validation des modifications
34/55
Rapport d’étude
Dans l’exemple ci-dessus, le développeur a souhaité ajouter le répertoire FormGenerator au tronc commun.
Le formulaire permet d’indiquer un commentaire de validation.
Un clic sur le bouton OK valide les modifications sur le dépôt.
Gestion des conflits :
L’extension Subclipse gère les conflits avec le dépôt Apache Subversion.
Les conflits sont souvent le résultat de mise à jour impossible de la copie locale avec le dépôt.
Voici un exemple montrant l’efficacité de l’extension Subclipse lors d’un conflit :
Le développeur Michel Beige a souhaité modifier le fichier form.class.php. Lorsqu’il a effectué une validation
de ses modifications, le serveur Apache Subversion l’a alerté d’un conflit :
35/55
Rapport d’étude
Le conflit est la cause d’une modification du fichier form.class.php dans une révision ancienne. En effet
avant que Michel Beige valide ses modifications, le fichier form.class.php a été déplacé par le développeur
Guillaume André.
Pour vérifier les modifications, Michel Beige a la possibilité de comparer son fichier avec celui du dépôt.
Clic droit sur le fichier form.class.php / Compare With / Latest from repository : affiche la comparaison
entre le fichier local et le fichier du dépôt :
Pour résoudre ce conflit, Michel Beige décide d’annuler ses modifications et de mettre à jour sa copie locale
avec les sources récentes du dépôt :
36/55
Rapport d’étude
Clic droit sur le fichier form.class.php / Replace With / Latest from repository
Clic droit sur le projet PHP / Team / Update from HEAD
4.2.5. Synchronisation de la copie locale
L’extension Subclipse facilite la communication avec le dépôt Apache Subversion.
En effet toutes les commandes d’Apache Subversion sont exécutables depuis le menu clic droit d’Eclipse.
Lorsqu’un développeur veut mettre à jour sa copie locale avec les sources récentes du dépôt, il lui suffit de
cliquer du droit sur son projet PHP et d’utiliser le menu :
Team / Update to HEAD : met à jour la copie locale avec les sources du dépôt
Pour faciliter la vision des évolutions du dépôt, les développeurs peuvent synchroniser leur copie locale avec
les sources du dépôt.
Cette opération permet de visualiser les évolutions du dépôt avant d’effectuer l’opération de mise à jour des
fichiers dans la révision la plus récente.
Il est alors possible pour le développeur de choisir les fichiers qu’il désire mettre à jour avec le dépôt.
La synchronisation est accessible sur Eclipse par un clic droit sur le projet PHP :
Clic droit sur le projet PHP / Team / Synchronize with repository
Une vue explorateur affiche la liste des fichiers du dépôt en comparaison de ceux de la copie locale du
développeur. Des icônes indiquent l’état des fichiers :

Le signe + indique un nouveau fichier sur le dépôt

Le signe – indique un fichier supprimé sur le dépôt

Le losange rouge indique un fichier modifié dans la copie locale qui n’a pas été validé sur le dépôt
La mise à jour avec le dépôt peut s’effectuer à partir de l’explorateur de fichiers du dépôt :
Clic droit sur un fichier / Team / Update from repository
37/55
Rapport d’étude
4.3. TRAC
TRAC est un logiciel sous licence Open source développé avec le langage Python. Il est disponible pour plusieurs
systèmes d’exploitation.
Pour les besoins du projet, l’installation de TRAC est réalisée avec la plateforme XP-Dev.com. Le dépôt Apache
Subversion du projet Form Generator existe déjà sur XP-Dev.com. Les services gratuits d’XP-Dev.com
proposent l’installation de TRAC comme gestionnaire de projets.
Pour rappel, pour accéder à la console d’administration du site XP-Dev.com :
Adresse Web : http://xp-dev.com/login
Installation du projet TRAC :
Le projet GLG10511 existe sur la plateforme XP-Dev.com. Il héberge un dépôt Apache Subversion.
TRAC est une interface Web qui se base sur Apache Subversion. TRAC se compose d’interfaces Web pour la
gestion de projets :

Système de gestion de contenus Wiki

Explorateur des sources Apache Subversion

Suivi des tickets d’incidents

…
38/55
Rapport d’étude
Il est logique que la plateforme XP-Dev.com gère TRAC comme un composant additionnel du dépôt Apache
Subversion. A la création du dépôt il est demandé de choisir le logiciel qui va gérer les évolutions du projet
(Issue Tracking) :
La configuration de TRAC est accessible par l’administrateur du projet GLG10511 via l’onglet TRAC du menu
principal :
Les notifications par e-mails sont actives.
Les statuts de traitement des tickets d’incidents sont reportés sur l’interface de ligne de temps (timeline).
L’activation du logiciel TRAC créée une interface Web accessible à l’adresse suivante :
http://xp-dev.com/trac/glg10511
Les informations du projet sont privées. Seuls les développeurs et l’administrateur du projet GLG10511
peuvent y accéder.
Adresse Web : http://xp-dev.com/trac/glg10511/login
39/55
Rapport d’étude
Interface vierge de l’outil TRAC déployé pour le projet GLG10511 :
Configuration du projet TRAC :
L’administrateur a la possibilité de configurer finement l’ensemble des outils de TRAC.
La configuration choisie pour le projet Form Generator est expliquée dans les chapitres qui suivent.
4.3.2. Répartition des tâches
La réalisation de la librairie de génération de formulaires Web (Form Générator) a déjà commencé.
Mais il n’est pas trop tard pour définir les objectifs du projet :
Un bon chef de projets doit préparer la phase de développement. Il doit :

définir les enjeux du projet

définir les fonctions principales du projet

répartir la réalisation des tâches à des responsables
Les objectifs sont révisés. Les points-clés ou jalons (milestones) du projet sont les suivants :

Rédaction de la documentation d’installation et d’utilisation

Développement de la classe principale de définition d’un formulaire Web

Définition des classes objets des champs de formulaires (texte, case à cocher, liste…)

Création du thème graphique pour la démonstration accompagnant la librairie

Préparation d’un prototype pour le client avant la livraison du projet
Les points-clés constituent ici les tâches du projet Form Generator.
Dans le logiciel TRAC, les tâches du projet sont liées aux tickets d’incidents.
40/55
Rapport d’étude
Via le menu d’administration de TRAC, l’administrateur définit les tâches du projet :
Répartition des tâches du projet Form Generator aux responsables :

Jérôme : développement de la classe principale de définition d’un formulaire

Guillaume André : développement des classes définissant les champs de formulaires (texte, case à
cocher, liste…)

Michel Beige : gestion de l’affichage du formulaire et création de l’exemple pour la démonstration
4.3.3. Gestion des incidents
Configuration de l’outil de suivi de tickets d’incidents :
L’administrateur de TRAC a la possibilité de configurer finement l’outil de gestion de tickets d’incidents :

Déclaration des numéros de versions du projet

Définition des types de tickets d’incidents

Définition des gravités des tickets d’incidents

Définition des états de traitement des tickets d’incidents

Définition des priorités des tickets d’incidents
Voici les paramètres choisis pour le projet Form Generator :
Deux versions sont référencées afin de distinguer les incidents reproduits sur la version en cours de
développement et les incidents après la première livraison du projet :
Les incidents référencés peuvent être des erreurs du langage PHP, des erreurs de compatibilité avec les
navigateurs Web, des demandes d’améliorations ou d’autres natures :
41/55
Rapport d’étude
Pour simplifier la déclaration des incidents, seuls deux gravités sont disponibles : mineure et majeure :
Les statuts de traitement des tickets sont : en cours de traitement, invalide, corrigé :
Trois priorités de traitement des tickets sont prévues : mineure, majeure, bloquante :
Déclaration d’incidents :
L’interface de création d’un ticket est accessible dans TRAC via le menu de navigation principal :
Le formulaire de saisie d’un ticket a été personnalisé par l’administrateur de TRAC.
Les champs définis répondent au besoin du projet. Afin de simplifier la déclaration des incidents, la saisie est
guidée. Les listes pré-remplies sont volontairement simples pour éviter toute incompréhension par les
rédacteurs.
42/55
Rapport d’étude
Form Generator est une librairie libre développée avec le langage PHP. Les différentes natures d’un ticket
sont définies pour ce type de projet : erreur PHP, erreur de compatibilité avec un navigateur Web…
Les tickets sont liés aux tâches du projet ce qui facilite la répartition des corrections.
Menu principal de TRAC / New ticket : affiche le formulaire de création d’un incident :
Pendant la phase de développement du projet Form Generator, plusieurs tickets ont été créés :

Les valeurs des paramètres envoyées au constructeur de la classe Form ne sont pas vérifiées

Problème de compatibilité d’affichage avec le navigateur Internet Explorer 8

Les champs de formulaires n’apparaissent pas au complet
Liste des tickets actifs sur TRAC :
Résolution d’incidents :
Voici la procédure de traitement d’un ticket :

Un incident est déclaré dans TRAC. Le statut de traitement du ticket indique un nouveau ticket.
43/55
Rapport d’étude

Une notification par e-mail est envoyée aux acteurs du projet

Le responsable de la tâche liée avec le ticket prend automatiquement en charge la résolution du
ticket

Le responsable analyse le problème. Il fait une première estimation du temps nécessaire à la
résolution.

Le responsable accède au formulaire de traitement du ticket sur l’interface de TRAC. Il modifie les
informations du ticket si nécessaire : gravité, priorité... Il peut aussi terminer le traitement du ticket
en l’invalidant s’il juge que l’incident n’en est pas un. Il indique la durée de résolution nécessaire
ainsi qu’une estimation de la date à laquelle la correction sera disponible.

Le responsable résout le problème.

Le responsable accède au formulaire de traitement du ticket sur l’interface de TRAC. Il indique le
ticket comme traité.
Les tickets sont liés aux tâches du projet. Pour le projet Form Generator il a été décidé que les tickets sur
une tâche devaient être pris en charge par le responsable de la tâche.
Exemple : les tickets concernant le thème graphique sont assignés à Michel Beige.
Exemple de résolution d’un ticket :
Une erreur de compatibilité d’affichage avec le navigateur Internet Explorer 8 a été détectée par un
développeur pendant la phase de développement du projet.
L’auteur du ticket est Guillaume André. Le ticket a été affecté à Michel Beige qui gère l’affichage des
composants dans le projet.
Michel Beige découvre un ticket dont il est responsable du traitement.
Il reproduit le problème avec la procédure expliquée dans le ticket : sur la capture d’écran ci-dessous les
champs de textes chevauchent leurs labels de quelques pixels :
44/55
Rapport d’étude
Michel répond à Guillaume en ajoutant un commentaire sur le ticket.
Il indique qu’il a reproduit le problème et qu’il a estimé sa résolution à 1 heure de travail.
La gravité du ticket est modifiée : le ticket est désormais en gravité mineure.
Michel confirme la prise en charge de la résolution et change le statut de traitement pour ‘en cours de
traitement’ :
Plus tard, Michel corrige le problème.
Il valide sa correction sur le dépôt Apache Subversion.
Afin de repérer la validation (commande commit), un mot-clé est ajouté au commentaire de validation :
#TICKET2 :
45/55
Rapport d’étude
Michel retourne sur l’interface TRAC pour indiquer que le problème est résolu : le statut de traitement du
ticket devient ‘résolu et fixé’.
Il indique le numéro de révision des sources du dépôt Apache Subversion qui contiennent cette correction :
13.
La révision 12 ne contient donc pas encore la correction.
Le problème de chevauchement des champs textes est résolu :
4.3.4. Mise en place d’un wiki
Le wiki de TRAC est un système de gestion de contenus qui a plusieurs avantages :

Des droits d’édition des contenus pour tous les acteurs du projet

Un système de gestion des versions d’articles

Une syntaxe de rédaction simple
La syntaxe du wiki de TRAC est très proche des syntaxes populaires sur Internet (ex : projet Wikipedia).
Voici quelques exemples de syntaxe :
= Titre niveau 1 =
== Titre niveau 2 ==
Titres
’’texte’’
Texte en gras
46/55
Rapport d’étude
* valeur 1
* valeur 2
* valeur 3
Liste à puces
[http://trac.edgewall.org/ TRAC]
Lien cliquable
{{{
#!php
Coloration syntaxique de code PHP
include 'formgenerator/formgenerator.php';
}}}
Pour le projet Form Generator, la page d’accueil de l’environnement TRAC a été modifiée afin de présenter
le projet. La page est volontairement rédigée en anglais pour prévoir une communauté large de visiteurs.
Sur la page sont affichés :

une introduction du projet Form Generator

la méthode d’installation

des conseils d’utilisation de la librairie

l’adresse d’accès au dépôt Apache Subversion

l’archive ZIP du projet Form Generator en version 1.0 stable
Page d’accueil du projet Form Generator :
4.3.5. Suivi des évolutions
47/55
Rapport d’étude
TRAC garde un historique de toutes les opérations effectuées sur l’interface. TRAC communique aussi avec
Apache Subversion et affiche les modifications sur les sources du dépôt.
L’historique des modifications de la page d’accueil du Wiki :
Menu principal / Wiki / History
L’historique dans la ligne de temps (Timeline) :
Cet historique affiche la liste de toutes les modifications relatives au projet. Ainsi on peut voir les
commentaires sur les tickets, les modifications de pages wiki, les commentaires de validations sur Apache
Subversion...
Menu principal / Timeline
L’historique des tickets d’incidents :
Menu principal / View tickets / All tickets (including closed)
48/55
Rapport d’étude
49/55
Rapport d’étude
5. ANALYSE DES RESULTATS
5.1. Outil de gestion de versions
5.1.1. Bonne communication en équipe
 Le dépôt Apache Subversion permet de centraliser les sources
 Le dépôt est accessible facilement : aucune contrainte sur le choix de l’outil pour les manipulations
sur le dépôt
5.1.2. Individualisation des tâches possible
 Le dépôt Apache Subversion assure la liberté de chaque développeur. A tout moment un développeur
peut valider et partager ses modifications.
5.1.3. Les compétences et les communications restent
 Le dépôt Apache Subversion sauvegarde le code source
 Toutes les informations et communications sur le projet sont historisées : la constitution d’un
wiki permet de rédiger des documentations d’utilisation, des documentations d’installation, des
documentations développement, de renseigner des références privées sur le client, l’envergure du
projet, les contacts, le contexte de l’offre…
5.1.4. Les livraisons sont stables
 La création de branches dans Apache Subversion permet livrer des projets stables par la séparation
des améliorations et des correctifs
5.1.5. La chaîne de production est organisée
 Les équipes peuvent se synchroniser sur le dépôt d’Apache Subversion
5.1.6. Suivi des évolutions
 Historique des fichiers et des commentaires
 Les fichiers sont versionnés
 Les logiciels livrés aux clients peuvent aussi être versionnés (branches)
5.2. Environnement de développement
5.2.1. Un seul outil de développement
 Eclipse est un environnement complet de développement
50/55
Rapport d’étude
5.2.2. Facilité de manipulations des outils
 Affranchissement du système d’exploitation des outils installés. Les moyens de communications dans
Eclipse avec les outils externes (base de données, gestion de versions) sont indépendants de
l’installation ou du lieu.
 Interfaces visuelles ergonomiques : plus d’interrogation à la commande shell, des interfaces sont
prévues pour ça.
5.3. Gestion de projets
5.3.1. Abondance des documentations
 Le wiki de TRAC Incite à la rédaction car :

Apprentissage rapide de la syntaxe du moteur de wiki

Moteur moderne populaire

Le wiki de TRAC est le seul outil à utiliser en commun
5.3.2. Facilité d’accès aux informations

L’accès aux informations sur TRAC nécessite uniquement une connexion Internet et un navigateur

Site disponible partout (intranet, internet) et quand on veut (heures de travail, chez soi)

Qualité des documents réalisés :
Le code wiki s’affranchit de la mise en page. Les textes facilement convertibles dans d’autres
formats : PDF, impression, doc...
5.3.3. Simplicité de la gestion d’avancement du projet

Création de feuille de route / Roadmap

Renseignement possible des technologies à l’étude

Historique des évolutions du projet
5.3.4. Suivi des problèmes de maintenance amélioré

L’outil de suivi des tickets d’incidents permet d’avoir une liste exhaustive des problèmes rencontrés.
Bien qu’un client puisse envoyer des mails à des personnes différentes, tous les problèmes seront
rassemblés dans TRAC.

Les bugs sont associés à des états d’avancement et à des états de priorités

Les clients comme les intervenants peuvent suivre les corrections des tickets

Les tickets peuvent être associés à une mesure du temps de corrections. Ce qui permet de faire des
statistiques (mesure du temps global passé pour un client sur un projet) et de réévaluer le contrat de
maintenance avec les clients
51/55
Rapport d’étude

Du fait de l’association d’un bug avec une correction effectuée sur un dépôt Apache Subversion, il est
possible d’associer les commentaires de corrections de bugs aux tickets. Il pourrait être intéressant
de mettre à disposition une liste des évolutions du logiciel à chaque livraison d’une nouvelle version.
52/55
Rapport d’étude
6. CONCLUSIONS
Les manipulations sur l’environnement Eclipse/Apache Subversion/TRAC ont démontré l’importance d’avoir
de bons outils dans la résolution des projets informatiques. De bons outils peuvent améliorer significativement
la qualité de la production des logiciels.
Le « génie » pour un chef de projets est de trouver le meilleur environnement de gestion de projets pour son
équipe.
53/55
Rapport d’étude
7. GLOSSAIRE
Eclipse
Environnement de développement complet
Gestion de versions
Outil permettant d’historiser les modifications d’un code source
Apache Subversion
Outil de gestion de versions
SVN
Autre nom donné à Apache Subversion
TRAC
Interface Web de gestion de projets lié à Apache Subversion
Commit
Opération de validation des modifications sur un outil de gestion de versions
Diff
Opération pour comparer des modifications sur un outil de gestion de versions
Update
Opération de mise à jour d’une copie locale sur un outil de gestion de versions
Dépôt
Espace où se situe les sources des projets historisés par un outil de gestion de
versions
Révision
Numéro de version d’un projet dans un outil de gestion de versions
Wiki
Outil de gestion de contenus avec une syntaxe simple sans mise en forme du texte
54/55
Rapport d’étude
8. REFERENCES
Ben Collins-Sussman, Brian W. Fitzpatrick & C. Michael Pilato, « Gestion de projets avec Subversion »
O’Reilly (2004)
55/55

Rapport d`étude

Transcription

Documents pareils

1 Syllabus Cours : Techniques d`expression orale française Année

Bleu SPADUNYA

Auto-massage - B

Recherche sur Internet en quatre étapes (PRI) Feuille de route

Comment faire votre .jar sous Eclipse

Articles sur le thème "eclipse" - Thegeekcorner

dossier_de_presse_trac

DOMAINES DE COMPETENCES • Systèmes d`exploitation : Windows

Frédéric BIGOT

Vaincre le trac