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
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
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
4.2. Eclipse... 26 4.2.1. Installation et configuration... 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.1. Installation et configuration... 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
8. Références... 55 6/55
1. GENERALITES 1.1. Informations du devoir Travaux pratiques n 1 Sujet : gestion de projets en 1.2. Mots-clés Eclipse, Apache Subversion, TRAC, gestion de versions, gestion de projets 7/55
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
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
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
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
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
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 HP-UX Solaris Centos Linux NetBSD SUSE Linux Debian Linux OpenBSD Ubuntu Linux Fedora Linux Mac OS X Windows FreeBSD Red Hat Linux 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
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
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
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
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
Synchronisation de la copie locale : 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
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
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
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
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
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\ : Mise à jour de la copie locale : 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
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 1 travaille sur le fichier formgenerator.php 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
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
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 4.2.1. Installation et configuration 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
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
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
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
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
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 Identifiant : jerome Mot de passe : glg105 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
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
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
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
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
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
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 Mise à jour 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 Synchronisation de la copie locale : 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
4.3. TRAC 4.3.1. Installation et configuration 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 Identifiant : jerome Mot de passe : glg105 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
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
Identifiant : jerome Mot de passe : glg105 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
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
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
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
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
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
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 == texte Titres Texte en gras 46/55
* valeur 1 * valeur 2 * valeur 3 [http://trac.edgewall.org/ TRAC] {{{ #!php Liste à puces Lien cliquable 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
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
49/55