Rapport de stage. Intégration technique et fonctionnelle entre Ofbiz et Neogia. Peter Goron

Transcription

1 Rapport de stage Intégration technique et fonctionnelle entre Ofbiz et Neogia Peter Goron

2 Rapport de stage: Intégration technique et fonctionnelle entre Ofbiz et Neogia Peter Goron

3

4 Table des matières Remerciements... viii Introduction... ix I. Présentation Présentation de Néréide Néréide Le réseau Libre-Entreprise Le réseau Libre Partage Présentation d'ofbiz Une architecture Un framework L'Entity Engine Le Service Engine Le Control Servlet Des applications Présentation de Néogia Les enjeux de la génération de code Les applications Néogia II. Développements réalisés Mise en place de procédures de gestion de configuration Présentation de la gestion de configuration Notion de listes des changements Notion de branches Organisation initiale du projet Néogia Présentation Ses défauts Solution mise en oeuvre Choix du système de gestion de version Réorganisation du projet Néogia Utilisation de branches de développement Utilisation de tags Méthodologie de développement au sein du projet Néogia Définition des différents type de développement Procédure d'intégration de corrections simples Procédure d'intégration de correction de bugs Néogia Procédure d'intégration de correction de bugs Ofbiz Procédure d'intégration de nouveaux développements Amélioration du MRP Amélioration du processus de lancement du MRP Intégration du MRP avec le module de gestion des stocks Prise en compte des magasins de stockage Prise en compte de la méthode de réapprovisionnement d'un article Mise en place de DocBook pour la documentation du projet Néogia Présentation Organisation hiérarchique Informations relatives au document Intérêt Intégration dans OfbizNéogia III. Bilan Conclusion Bilan professionnel iv

5 Rapport de stage 2. Bilan personnel IV. Annexes A. Procédure de synchronization d'ofbiznéogia avec Ofbiz Objet Pré-requis Procédure B. Création d'un projet client basé sur neogia Pré-requis Préparation du serveur Configuration du référentiel Activation des logs Configuration des verrous CVS Configuration des fichiers binaires Import d'ofbiznéogia dans le référentiel CVS Procédure de sauvegarde et de restauration du référentiel Sauvegarde Restauration C. Procédure de mise à jour d'un projet client basé sur Néogia Déterminer quelle est la dernière version STABLE d'ofbiznéogia Récupérer la dernière version STABLE d'ofbiznéogia Importer de la nouvelle version d'ofbizneogia dans le référentiel client Résolution des conflits dans la branche de développement D. Diagramme UML du MRP Bibliographie v

6 Liste des illustrations 2.1. Architecture n-tiers d'ofbiz Architecture J2EE d'ofbiz Boucle d'évènements d'une application Ofbiz Schéma MDA utilisé par Néogia Illustration du Branch by version Illustration du Branch by purpose Illustration de l'utilisation d'une branche stable Utilisation de la branche STABLE d'ofbiznéogia Utilisation de la branche EXPERIMENTAL d'ofbiznéogia Utilisation des branches dans un projet Client Exemple de fusion de branches Interfaces graphiques initiales du MRP Nouvelle interface de lancement du MRP Visualisation des résultats du MRP Organisation des magasins de stockage dans OfbizNéogia Processus de génération d'un document au format DocBook Processus de génération mis en oeuvre Feuille de style utilisée pour générer la documentation du projet vi

7 Liste des exemples 6.1. Exemple minimaliste d'un document DocBook Exemple d'article DocBook Exemple d'informations relatives au document vii

8 Remerciements Mes remerciements s'adressent en premier lieu à mon maître de stage, Olivier Heintz, pour sa disponibilité et pour m'avoir laissé travailler sur des développements importants pour la société. Je tiens aussi à remercier toute l'équipe Néréide pour avoir fait de Néréide un lieu où il fait toujours aussi bon travailler. viii

9 Introduction On ne présente plus les logiciels libres, aujourd'hui reconnus pour leur qualité et leur ouverture. Ils ont démontré leur efficacité dans plusieurs domaines, notamment Internet, avec par exemple, le serveur web Apache et le système d'exploitation Linux. Aussi, de nombreuses entreprises et gouvernements ont commencé la migration de leurs systèmes d'information vers des solutions libres. En conséquence, on commence à trouver ces logiciels dans des secteurs traditionnellement réservés aux logiciels propriétaires, en particulier, les PGI ou Progiciels de Gestion Intégrés. Ainsi, les GNU Enterprise, Ofbiz, Compiere et autres viennent empiéter sur les terres de BAAN, SAP, ORACLE, etc. Cependant, ce type d'application joue un rôle stratégique au sein des entreprises qui les utilisent. Il requiert un très haut niveau de technicité et de compétences que ces dernières ne sont pas prêtes à laisser aux mains de développeurs éparpillés aux quatre coins du monde. C'est pourquoi, comme pour les logiciels propriétaires, est apparue la nécessité d'avoir des entreprises prestataires de services spécialisées en logiciels libres. Ce besoin s'est renforcé avec la rationalisation des coûts liés aux systèmes d'information depuis l'éclatement de la bulle Internet. Néréide, société dans laquelle j'ai effectué mon stage de 3ème année entre le 6 juin et le 23 septembre 2005, est une de ces nouvelles SSLL (Société de Services en Logiciels Libres). Elle propose à ses clients un PGI basé sur le logiciel libre Open For Business (Ofbiz) pour lequel elle peut développer des besoins spécifiques pour chacun d'entre eux. Au cours de ce stage, mon travail a consisté à mettre au point les procédures de gestion de configuration aussi bien pour les projets internes de Néréide que pour ses projets clients; à améliorer l'utilisation du module MRP de l'application de gestion de la production de son MRP; et à mettre au point un système de documentation basé sur le format ouvert DocBook. ix

10 Présentation

11 Chapitre 1 Présentation de Néréide 1. Néréide Néréide est une jeune société de services en logiciels libres (SSLL) spécialisée dans l'intégration de l'erp Open Source OfbizNéogia. Créée en mars 2004 sous la forme d'une SARL à capital variable, elle est située à 10 km à l'est de Tours. Outre l'intégration d'ofbiznéogia, elle propose à ses clients toute une gamme de services centrés autour de l'erp : développements spécifiques, administration système, infogérence, maintenance et support applicatif. Étant membre du réseau Libre-Entreprise, cette offre peut être étendue selon les services que proposent les membres de ce réseau (cf. section suivante). L'équipe Néréide compte 7 personnes : Éric Barbier, Gérant de l'entreprise; Olivier Heintz, Directeur de projet; Jean-Luc Malet, Directeur de projet; Yannick Thebault, Architecte. Pierre Gaudin, Développeur; Spohie Benaroch, Chargée d'affaires; Catherine Heintz, Responsable communication - administration Durant ma période de stage, 3 stagiaires étaient présents : Géraud Buxerolles, Département informatique de Polytech' Tours; Majid El Drissi, Département informatique de Polytech' Tours; Thomas Brant, BTS informatique en alternance. 11

12 Présentation de Néréide 2. Le réseau Libre-Entreprise Le réseau Libre-Entreprise regroupe des entreprises ayant des spécialités proches ou complémentaires, en particulier dans le domaine du logiciel libre. Toutes partagent les mêmes valeurs et modes de fonctionnement, basés sur la clarté et la compétence. Le groupe est présent en France (Biarritz, Marseille, Montpellier, Mulhouse, Nantes, Paris, Tours, Vandoeuvre-lès-Nancy), en Belgique (Bruxelles) et au Canada (Montréal). L'organisation en réseau permet à tous les membres de bénéficier d'une offre commerciale étendue homogène et de disposer d'un ensemble de ressources spécialisées dans chaque domaine d'intervention grâce aux partages des connaissances. En outre, un ensemble d'outils de travail collaboratif est mis à la disposition des membres du réseau pour simplifier la communication au sein du réseau et pour les aider dans leurs démarches : documentations partagées : documents sur la création d'entreprise, documents techniques, modèles de documents; calendrier partagé; listes de diffusion partagées; serveur de messagerie instantanée (Jabber); le laboratoire Libre-Entreprise : une plateforme d'hébergement de projets informatiques tel que le célèbre SourceForge. Elle offre les mêmes services, à savoir, site web, espace ftp, accès cvs, mailing-lists, etc. Planet Libre-Entreprise : c'est un agrégateur de contenu qui permet de suivre l'activité des membres du réseau. Pour faire partie du réseau, les sociétés doivent envoyer un compte-rendu mensuel d'activité sur la liste de diffusion "réseau" afin que tous les membres puissent connaître l'évolution de chaque entreprise. La forme exacte de ce rapport n'est pas définie mais certaines informations sont nécessaires, comme une rapide présentation de l'entreprise, l'effectif, les finances, les affaires en cours et les affaires probables. 12

13 Présentation de Néréide 3. Le réseau Libre Partage Libre Partage est un réseau de partage d'informations entre ses membres (des entreprises, des indépendants, des associations) permettant à tous de progresser et d'atteindre les objectifs de qualité et de méthodes de travail demandés par le réseau Libre-Entreprise. Les seules conditions d'adhésion sont : avoir un fonctionnement démocratique; être contrôlé par les personnes qui y travaillent; souhaiter partager l'information avec les autres membres du réseau; accepter de suivre des règles de bonnes moeurs; et utiliser des logiciels libres. 13

14 Chapitre 2 Présentation d'ofbiz Open For Business, ou Ofbiz, est un projet de progiciel de gestion intégré (PGI) libre initié par deux développeurs américains, Andy Zeneski et David E. Jones, en mai L'objectif de ce projet est de fournir un ensemble de composants homogènes permettant de développer aisément et rapidement des logiciels libres de gestion. À terme, il est prévu d'obtenir tous les composants nécesssaires à un PGI intégrant les modules de gestion suivants : un ERP (Enterprise Resource Planning); un SCM (Supply Chain Management); un CRM (Customer Relationship Management); un MRP (Manufacturing Resource Planning); un CMS (Content Management System); un CMMS (Computerized Maintenance Management System); et une plateforme d'ebusiness / ecommerce; Pour atteindre ces objectifs, Ofbiz se base sur de nombreux logiciels libres tels que Subversion, ant, Tomcat, JPublish, FreeMarker, etc. Ces logiciels sont reconnus pour leur qualité et ils assurent l'indépendance du projet. De même, Ofbiz respecte de nombreux standards pour garantir un maximum de compatibilité avec les systèmes existants et futurs, notamment J2EE et XML. Ce dernier est largement utilisé dans tout le projet pour décrire les données et les traitements. Par ailleurs, le code source du projet est publié sous la licence MIT qui est libre et permissive, c'est-à-dire qu'elle ne fixe aucune obligation et/ou interdiction quant à l'utilisation, la modification, l'extension et la commercialisation du logiciel. Grâce à l'ouverture du code, une véritable communauté d'utilisateurs et de développeurs s'est formée. Cette dernière assure ainsi la réactivité et la qualité du projet. Cependant, de par sa taille et sa complexité, ce type de logiciel nécessite de gros investissements humains, matériels et financiers pour son développement mais aussi pour être reconnu. Les auteurs initiaux ont donc créé une société, Undersun Consulting, qui offre des services autour d'ofbiz tout en les rémunérant pour leur travail de développement. Plusieurs sociétés du même type se sont créées un peu partout dans le monde dont Néréide pour la France. Elles participent ainsi au projet en tant que sponsors. Généralement, ces sociétés proposent quatre types de services : l'installation et l'adaptation si nécessaire d'ofbiz; le développement d'extensions spécifiques à l'entreprise; la maintenance du système; 14

15 Présentation d'ofbiz la formation des utilisateurs. 1. Une architecture Ofbiz est une application java client-serveur compatible avec la spécification J2EE qui définit une architecture logicielle standard. On retrouve ainsi les trois éléments caractéristiques d'une architecture 3-tiers : les clients : ici des clients légers, typiquement des machines peu puissantes disposant d'un navigateur internet; un serveur exécutant les différentes applications Ofbiz; et une ou plusieurs bases de données stockant le système d'information de l'entreprise. Figure 2.1. Architecture n-tiers d'ofbiz Néanmoins, l'architecture d'ofbiz peut aussi être considérée comme une architecture n-tiers car elle peut faire appel à des applications externes via des services. Ces derniers ne sont pas forcément exécutés sur la même machine, on les appelle alors WebServices. Ce type d'architecture présente de nombreux avantages. Elle permet de distribuer plus librement la logique applicative, ce qui facilite la répartition de la charge entre tous les niveaux. Elle facilite l'intégration de l'application avec celles déjà existantes. Enfin, elle permet d'accéder à un très grand nombre de fonctionnalités. 15

16 Présentation d'ofbiz Figure 2.2. Architecture J2EE d'ofbiz Une des caractéristiques principales d'ofbiz est la modularité de son architecture. En effet, tout est composant. Cette approche favorise une meilleure réutilisation des composants logiciels, un développement modulaire donc plus rapide et enfin une meilleure qualité. Ce type d'architecture permet aussi de remplacer un composant par un autre très facilement dans le cas où il existe plusieurs implémentations différentes. Ofbiz se décompose en deux parties : le serveur et les composants. Le serveur, ou base, propose un environnement d'exécution homogène et performant pour les applications qu'il fait tourner. Il fournit tout un ensemble de mécanismes de gestion de cache et de pools de connexions qui permettent une meilleure montée en charge et une meilleure réactivité du système. Les composants, quant à eux, représentent les plus petites briques logicielles gérées par le serveur. Ils peuvent fournir un ensemble de ressources permettant de construire tout ou partie d'une application Ofbiz. Ces ressources peuvent correspondre à : un jeu de données, un modèle de données, des services, une ou plusieurs applications web, du code java. Généralement, un composant est spécialisé pour une fonctionnalité donnée. L'architecture d'ofbiz se décompose en une multitude de composants qui, regroupés ensemble, forment un PGI complet. Toutefois, tous n'ont pas le même rôle au sein du PGI, c'est pourquoi on les classe selon trois niveaux d'abstraction : le framework qui permet de développer des applications métier rapidement; les applications de base que l'on retrouve dans tout type d'organisation; les applications de haut-niveau et/ou applications métier. 2. Un framework Ofbiz est en premier lieu un «framework d'application d'entreprise» dans lequel chaque composant représente une brique logicielle pouvant être réutilisée pour construire des applications diverses. Ce framework repose sur trois composants essentiels sans lesquels une application standard ne pourrait pas fonctionner : l'entity Engine, le Service Engine et le 16

17 Présentation d'ofbiz ControlServlet L'Entity Engine L'Entity Engine est un composant Ofbiz qui se charge de la gestion des données de tous les autres composants Ofbiz. Les données sont représentées selon un modèle Entité-Relation largement utilisé dans les applications d'entreprise et compatible avec la plupart des bases de données relationnelles. Le principal objectif de ce composant est d'éliminer tout code spécifique à la persistance des données dans un système transactionnel. Ses principales caractéristiques sont : accès aux données via une interface unique, le «GenericDelegator»; supporte l'accès transparent à plusieurs base de données; les entités sont définies dans de simples fichiers XML; tous les types java de base ont un équivalent en base de données; supporte les transactions distribuées; suppporte un mécanisme de trigger appelé «EECA 1» même si le SGBD sous-jacent n'implémente pas cette fonctionnalité Le Service Engine Le Service Engine est l'équivalent de l'entity Engine pour tous les traitements des composants Ofbiz. Les traitements sont appelés Services et peuvent être exécutés localement ou à distance. Le principal intérêt de ce composant est qu'il permet de lancer des services sans avoir besoin de connaître leur localisation et leur implémentation. C'est le ServiceDispatcher qui se charge alors de trouver l'implémentation du service et de son exécution. Un autre intérêt est la possibilité de rendre disponible tout service Ofbiz vers l'extérieur. Les services sont définis dans des fichiers XML dans lesquels il faut indiquer pour chaque service : son nom; son implémentation (java, beanshell, minilang, etc); sa localisation; la méthode à invoquer lors de son appel; la nécessité ou non d'être authentifié pour pouvoir l'appeler; ses paramètres d'entrée; ses paramètres de sortie. Un service est un traitement qui prend des paramètres en entrée et des paramètres en sortie. Ces paramètres sont vérifiés avant et après l'appel d'un service. Le traitement peut être asynchrone ou synchrone. L'accès aux entités à partir d'un service se fait automatiquement par l'intermédiaire d'une transaction ainsi en cas d'échec du service, la cohérence des bases de données est conservée. 1 Entity Event-Condition-Action 17

18 Présentation d'ofbiz 2.3. Le Control Servlet Le ControlServlet est l'élément clé de la communication entre les utilisateurs et les applications web d'ofbiz. Implémenté selon le modèle MVC (Modèle-Vue-Controleur), il gère la boucle d'évènements de l'interface graphique et les différents moteurs de rendu de l'application. Les réponses aux intéractions de l'utilisateur s'effectuent par l'intermédiaire d'évènements qui peuvent être implémentés sous la forme de services, de méthodes java, de scripts Beanshell ou Minilang. Figure 2.3. Boucle d'évènements d'une application Ofbiz Voici l'ensemble des opérations effectuées suite à une intéraction avec l'utilisateur pour lui afficher une page à l'aide de JPusblish et FreeMarker (cf. Figure 2.3, «Boucle d'évènements d'une application Ofbiz»): 1. L'utilisateur clique sur un lien hypertexte ou valide un formulaire. Le navigateur envoie alors une requête HTTP au serveur Ofbiz qui est interceptée par Tomcat et transmise au ControlServlet de l'application web correspondante. 2. Le ControlServlet vérifie si l'uri demandée est définie par l'application. Le cas échéant, il appelle le ou les événements associés à cette URI. Dans le cas contraire, il renvoie une erreur au navigateur web de l'utilisateur (Erreur HTTP 404 : page non trouvée). 3. Si l'évènement généré doit appeler un service, il vérifie que les paramètres de la requête correspondent aux attributs du service. 4. Si l'évènement généré doit appeler un service, il convertit les paramètres de la requête sous forme textuelle en objets Java correspondant. 5. L'évènement appelle un service ou un gestionnaire d'évènements (méthode java statique). 6. Le service ou le gestionnaire d'évènements peuvent effectuer des actions sur le modèle de données. 18

19 Présentation d'ofbiz 7. L'EntityEngine convertit ces actions en requêtes SQL pour le serveur de base de données. 8. Le service ou le gestionnaire d'évènement renvoie le résultat de leur action. 9. L'évènement transmet ce résultat au ControlServlet. 10. À partir du résultat de l'évènement, le ControlServlet sélectionne la vue à afficher et appelle le moteur de rendu adéquat. 11. À partir de la définition d'une vue, le moteur de rendu construit les différents sous-éléments de cette dernière. 12. Pour chaque sous-élément, il peut appeler des scripts BeanShell qui récupèrent et mettent en forme les données à afficher. 13. Pour chaque sous-élément, il appelle le moteur de template qui se charge de générer le code HTML correspondant. 14. Le moteur de rendu assemble les différents sous-éléments pour former une page web complète. 15. Le ControlServlet transmet la page générée au navigateur web de l'utilisateur. 3. Des applications Un des avantages d'ofbiz par rapport à d'autres frameworks, est qu'il fournit un certain nombre d'applications par défaut, qui couvrent quasiment tous les domaines de l'entreprise. Elles sont livrées prêtes à l'emploi; il ne reste plus qu'à saisir les données spécifiques à l'entreprise. On distingue deux types d'application au sein d'ofbiz : les applications de base que l'on retrouve dans toute organisation et les applications haut-niveau et/ou métiers, spécifique à un secteur d'activité. 19

20 Chapitre 3 Présentation de Néogia Bien qu'ofbiz soit un logiciel écrit en Java, ses auteurs ont privilégié une approche Entité-Relation plutôt qu'une approche orientée objet pour la modélisation du système d'information de l'entreprise. Ce choix est motivé par un souci de simplicité et de généricité au niveau de la couche de persistence de données d'ofbiz (Entity Engine). Cependant, ce type de modélisation présente le problème de s'attacher plus aux données qu'à la dynamique du système. En conséquence, on est souvent amené à manipuler directement les tuples de la base de données ce qui peut poser des problèmes de cohérence et de duplication de code. De plus, cette approche ne permet pas d'utiliser le haut niveau d'abstraction qu'offre le langage de programmation. Pour pallier cet inconvénient, Néréide a entrepris en mai 2004 le développement d'un nouveau projet appelé Néogia, publié sous la licence GPL. L'objectif de ce projet est de fournir à la communauté un ensemble d'outils et d'extensions permettant de développer des applications Ofbiz à l'aide d'une modélisation objet. Ces extensions se présentent sous la forme de composants Ofbiz générés à partir de diagrammes UML. Le temps gagné par la technique de génération de code employée dans Néogia permet aux développeurs de se consacrer principalement à la modélisation de leur application et donc d'augmenter la qualité du produit final. Les outils de génération de code utilisés par le projet Néogia se basent sur une technologie mise au point par Code-Lutin, une société de services en logiciels libres nantaise, membre du réseau Libre-Entreprise et spécialisée dans le développement applicatif en Java. Cette technologie, appelée LutinGenerators, permet à partir d'une modélisation UML stockée dans un fichier XMI 1 de générer n'importe quel type de fichier dès l'instant qu'un générateur correspondant existe. L'utilisation de cette technologie est le fruit d'une collaboration entre Néréide et Code-Lutin dans le cadre d'un transfert de compétences au sein du réseau Libre-Entreprise. 1 Format XML permettant l'échange de modèles UML entre outils de développement logiciel. 20

21 Présentation de Néogia 1. Les enjeux de la génération de code Les applications d'un progiciel de gestion sont en général très complexes du fait du grand nombre de fonctionnalités développées et du volume de données très important à manipuler de façon sécurisée. Ceci implique un temps de développement très long. Or, les problématiques actuelles de conception de logiciels libres sont en totale oppposition. En effet, du fait du nombre réduit de développeurs, la conception d'un logiciel libre nécessite de : limiter le temps de développement; assurer la souplesse de la plateforme notamment lors d'un changement de technologie; limiter les efforts liés à la maintenance du code. Dans ce contexte, la génération de code qui consiste à automatiser la création du code dit d'architecture, est un enjeu important pour les sociétés de services dans le logiciel libre. En effet, cela permet à la société de concentrer ses efforts non sur le codage d'architecture qui ne sera pas source de valeur ajoutée mais sur la demande spécifique des clients qui quant à elle, sera génératrice de valeur ajoutée. Dans le cas de Néogia, les développements sont réalisées via une approche MDA (Model Driven Architecture) dans laquelle tout développement passe par la définition d'un modèle UML qui sera ensuite utilisé pour générer le code de l'application. Figure 3.1. Schéma MDA utilisé par Néogia. Les générateurs de code de Néogia se chargent de créer toute la couche de persistance de données entre les objets issus de la modélisation et les entités gérées par l'entity Engine d'ofbiz, et de créer l'interface graphique et les services associés. L'intérêt des composants générés par Néogia par rapport aux composants Ofbiz est qu'ils sont issus de diagrammes UML et que leur code est généré à 70 %. L'un des reproches qui est souvent fait aux outils de génération de code est de ne pas pouvoir distinguer les éléments générés des éléments développés lors de générations successives. Les générateurs de Neogia ont été conçus pour éviter ce genre de cas en séparant les parties développées des parties générées. 21

22 Présentation de Néogia Voici quelques générateurs fournis par Néogia : générateur de services; générateur d'entités; générateur de la couche d'abstraction Objet-Entité; générateur d'interfaces graphiques par défaut pour les objets modélisés; générateur des formulaires de recherche; générateur des fichiers d'internationalisation; etc. 2. Les applications Néogia Afin de démontrer l'efficacité de l'approche MDA pour le développement d'applications métiers pour Ofbiz, Néréide a recréé entièrement le module de gestion de production d'ofbiz via cette approche. Les résultats étant au rendez-vous, les applications de gestion des stocks et de comptabilité ont elles aussi été refaites. Par la suite, d'autres composants d'ofbiz ont été partiellement porté sur cette nouvelle architecture pour faciliter l'intégration des deux projets. La modélisation UML de ces applications à été realisée à partir de l'expérience acquise lors de la mise en oeuvre d'autres ERP et également à partir des retours d'expérience de l'utilisation d'ofbiz. Pour éviter des confusions entre les applications Ofbiz et les applications Néogia, l'erp a été renommer OfbizNéogia. 22

23 Développements réalisés

24 Chapitre 4 Mise en place de procédures de gestion de configuration Un ERP se distingue d'une application traditionnelle par le haut niveau d'intégration qui existe entre ses différents composants. Ainsi, le module de gestion des ventes peut être amené à utiliser la gestion des stocks et la gestion de la clientèle pour passer des commandes, et être lui-même utilisé par le module de comptabilité pour établir les factures. Cette intégration poussée nécessite une vigilance particulière pour maintenir l'ensemble du progiciel cohérent et fonctionnel à tout instant, et ne peut être obtenue sans l'utilisation de procédures de gestion de configuration bien établies. Par ailleurs, un ERP occupe une place stratégique au sein du système d'information de l'entreprise du fait de son coût de mise en oeuvre et du haut niveau de disponibilité requis pour les utilisateurs du système. C'est pourquoi, les clients exigent souvent un maximum de visibilité sur les évolutions apportées au système, notamment lorsqu'il s'agit de logiciels libres en constante évolution. Cette visibilité ne peut être obtenue que si l'on est capable de savoir précisément quelle version du logiciel comporte telle fonctionnalité. Enfin, dans le cadre du déploiement d'ofbiznéogia chez des clients, il est nécessaire d'avoir plusieurs environnements configurés différemment, par exemple : un environnement d'intégration dans lequel on intègre des développements spécifiques, un environnement de recette sur lequel on passe les tests de recette du client, un environnement de production correspondant à la version finale utilisée dans l'entreprise, etc. La gestion de la configuration doit permettre de gérer ces différents environnements et suivre l'évolution des développements spécifiques. En effet, souvent ces projets contiennent des extensions qui ne peuvent pas être réintégrées au projet Néogia car elles sont trop spécifiques. Dans ce cas, le projet client diverge et il devient donc important de connaître les modifications apportées par rapport au projet initial pour simplifier la maintenance par la suite. Néréide m'a donc demandé de mettre au point les procédures de gestion de configuration permettant d'atteindre les quatre besoins suivants : assurer la stabilité du projet; permettre le suivi des évolutions projet Néogia; permettre le suivi des spécificités apportées aux projets clients; permettre la gestion des différents environnements des projets clients. 24

25 Mise en place de procédures de gestion de configuration 1. Présentation de la gestion de configuration La gestion de configuration consiste à gérer la description technique d'un système (et de ses divers composants), ainsi qu'à gérer l'ensemble des modifications apportées au cours de l'évolution du système. La gestion de configuration est utilisée pour la gestion de systèmes complexes : en informatique en aéronautique en automobile En informatique, la gestion de configuration est utilisée de manière à stocker et tracer les différentes versions ou révisions de toute information destinée à être utilisée par un système (logiciel, document, donnée unitaire). Ceci est réalisé à l'aide de logiciels de gestion de versions, commerciaux, payants ou gratuits (exemple CVS). Utilisée dans le suivi de version de logiciels, la gestion de configuration permet par exemple de gérer les codes sources. Utilisée dans le suivi de version de documents, elle permet de tracer toutes les modifications qui sont intervenues sur les informations contenues dans le document Notion de listes des changements Parmi les fonctionnalités dont peuvent disposer les gestionnaires de configuration, on trouve le regroupement de modifications (changeset). En général, une modification concerne une tâche, et il est rare qu'une tâche n'affecte qu'un seul fichier. Aussi, pour éviter de rechercher dans l'intégralité d'une arborescence de fichiers les modifications apportées à l'occasion de la résolution d'une tâche, l'outil va regrouper lesdits fichiers au sein d'une liste de changement. Ces regroupements permettent une atomicité dans l'évolution du système. Cette atomicité réalise alors des points d'arrêts qui constituent alors une graduation temporelle. Cette graduation est la base de la réalisation de toute métrique logicielle Notion de branches Par défaut, le développement d'un logiciel est généralement linéaire : on apporte des modifications et des ajouts de fonctionnalités jusqu'à atteindre un état stable pour pouvoir publier une nouvelle version du logiciel. On parle alors de trunc commun ou de Mainline. Cependant, au cours de l'évolution du logiciel, il se peut que cette MainLine doive à la fois suivre son cours, mais aussi répondre à une ou plusieurs contraintes qui vont amener le produit à suivre des évolutions parallèles à la MainLine. On a alors besoin de créer des branches. D'une part, après avoir publié une nouvelle version du logiciel, il faut être capable de réaliser une maintenance corrective lorsque des bugs apparaissent après la publication. Or la mainline a continué à évoluer et le bug peut avoir été corrigé ou avoir disparu pour la prochaine version. Il est donc nécessaire de maintenir plusieurs branches de développement en parallèle pour pouvoir réaliser la maintenance des versions déjà publiées. C'est ce qu'on appele le Branch by version. 25

26 Figure 4.1. Illustration du Branch by version Le branch by version consiste juste à créer une branche à chaque nouvelle version du logiciel. Elle permettra le suivi des corrections apportées à cette version. D'autre part, certains logiciels tels que les ERP exigent un développement continu durant lequel il est difficile d'obtenir un état stable pour réaliser une publication. En effet, il y a généralement toujours des développements en cours qui bloquent la sortie d'une nouvelle version du logiciel. Façe à cette contrainte, il existe deux approches : le branch py purpose ou l'utilisation d'une branche stable. Le branch by purpose consiste à créer une nouvelle branche pour tout nouveau développement afin de préserver la stabilité de la mainline. C'est lors de la fusion d'une branche de développement avec la mainline que des tests seront réalisés pour vérifier que le développement n'entraîne pas de régressions. Cette approche permet aux développeurs de travailler en toute indépendance vis-à-vis des autres développements en cours. Néanmoins cette approche n'est utilisable que si l'on dispose d'un logiciel de gestion de version avec une gestion efficace des branches. Figure 4.2. Illustration du Branch by purpose L'utilisation d'une branche stable est l'approche opposée au branch by purpose car tous les développements sont réalisés dans la mainline. Par contre, une branche qualifiée de stable est maintenue en parallèle de la mainline pour réalisée les publications de nouvelles versions. Ainsi lorsque un développement est terminé, il passe de la mainline à la branche stable. Figure 4.3. Illustration de l'utilisation d'une branche stable Ces deux approches ne sont pleinement utilisables que lorsqu'elles sont utilisées conjointement avec un outil de gestion de projet et des tests de non-régression. En effet, la personne réalisant l'intégration des développements dans la branche servant aux publications doit connaître les relations de dépendances qui peuvent exister entre les développements et être capable de les valider. 26

27 Mise en place de procédures de gestion de configuration 2. Organisation initiale du projet Néogia L'organisation initiale du projet Néogia, à savoir l'organisation de ses répertoires, son mode de distribution et son processus de mise en oeuvre, présente un certain nombre de limitations qui empêchent la mise en place des procédures de gestion de configuration. Après une rapide présentation, cette section décrit les différents problèmes soulevés par cette organisation Présentation Le projet Néogia se présente sous la forme d'un ensemble de fichiers organisés qu'il faut téléchargés sur le serveur cvs du projet. Il contient : des générateurs de code utilisés pour transformer les diagrammes UML des applications néogia en codes sources; des patchs à appliquer sur Ofbiz pour faciliter l'intégration des applications Néogia dans Ofbiz; et les applications Néogia. Néogia ne livre pas un ERP complet mais uniquement des applications destinées à remplacer ou compléter des applications existant dans Ofbiz. Il manque donc la pièce central de l'erp à savoir le framework et les applications Ofbiz. La construction de l'erp OfbizNéogia est réalisée par une procédure automatique présentée ci-dessous. Procédure 4.1. Processus de construction de l'erp OfbizNéogia 1. Télécharger Ofbiz 2. Télécharger Néogia 3. Appliquer les patchs Néogia sur Ofbiz 4. Intégrer les composants Néogia dans Ofbiz 5. Compiler l'ensemble pour obtenir OfbizNéogia 27

28 2.2. Ses défauts Cette procédure, mise au point lors de mon précédent stage chez Néréide [PG04], avait pour objectif de montrer à la communauté Ofbiz que le projet Néogia n'était pas un Fork du projet mais bien une extension. C'est pourquoi, Ofbiz n'est pas distribué avec Néogia et qu'un mécanisme à base de patchs a été mise en oeuvre pour l'intégration de Néogia dans Ofbiz. Cependant, ce mécanisme complexe est difficile à maintenir et à faire évoluer à cause de l'augmentation du nombre de patchs, de l'ordre précis à respecter lors de leur application sur Ofbiz et des chevauchements qui commencent à apparaitre entre-eux (plusieurs patchs traitant un même fichier). De plus, cette organisation est incompatible avec le souhait de pouvoir autoriser un client à développer du code spécifique pour son projet tout en bénéficiant des mises à jour du projet Néogia car le mécanisme d'application des patchs n'a pas été prévu à cet effet. Enfin, OfbizNéogia n'intègre aucune information de gestion de version du fait de la procédure d'intégration de Néogia dans Ofbiz. Il est alors impossible de récupérer les modifications apportées à ses fichiers sans passer par l'étude des patchs et des historiques des référentiels d'ofbiz et de Néogia. Pour toutes ces raisons, il a été nécessaire de revoir entièrement l'organisation du projet afin de simplifier les processus de développement et d'intégrer les procédures de gestion de configuration. 28

29 Mise en place de procédures de gestion de configuration 3. Solution mise en oeuvre Après avoir étudié les principes de la gestion de configuration et identifié les contraintes pesant sur le projet, la solution proposée repose : sur la réorganisation de Néogia afin de faciliter la mise en place d'une gestion de configuration au niveau du projet; sur l'introduction d'une branche de développement représentant la version stable d'ofbiznéogia; sur l'utilisation d'un référentiel CVS pour les projets clients ainsi que l'utilisation de plusieurs branches représentant les différents environnements : Développement, Intégration, Production Choix du système de gestion de version Lors de la mise en place des procédures de gestion de configuration, la première question posée était de savoir s'il fallait conserver l'utilisation de CVS ou bien en profiter pour utiliser un système de gestion de version plus récent tel que Subversion ou Bazaar. Subversion a été conçu par le créateur de CVS et il est sensé résoudre les principaux défauts de ce dernier. En particulier, toutes les opérations sur le référentiel sont atomiques, il est possible de déplacer un fichier dans l'arbre du projet sans perdre tout son historique et il minimise le nombre d'accès réseaux au référentiel. Cependant, son utilisation sous Eclipse sous Linux n'est pas encore stable limitant ainsi les possibilités d'usage pour le projet Néogia. Bazaar, à la différence de CVS et de Subversion, est un système décentralisé conçu initialement pour les développeurs de logiciels libres ne disposant pas de connexions Internet permanentes. Son principal avantage est de supporter la notion de liste de changements grâce à l'utilisation intensive de branches de développement (idéal pour utiliser l'approche branch by purpose). Bazaar est équivalent à Subversion en terme de fonctionnalités mais souffre de défauts de jeunesse (lenteur sur des gros projets, abscence de plugin Eclipse) qui empêchent son utilisation pour le projet Néogia. Néanmoins, il reste un produit prometteur dans le domaine des logiciels de gestion de version décentralisés Réorganisation du projet Néogia L'objectif de cette réorganisation est de simplifier la mise en oeuvre d'ofbiznéogia en se passant de la phase d'application des patchs et d'intégration des composants dans Ofbiz. Ainsi une gestion de version pourra être directement intégrée à OfbizNéogia ouvrant la voie à la mise en place des procédures de gestion de configuration. En contre-partie, Ofbiz sera directement distribué par Néogia ce qui peut passer pour un fork aux yeux de la communauté Ofbiz. Il faudra donc veiller à faire remonter les corrections de bugs sur Ofbiz pour que les relations entre les deux projets restent pérennes. Le projet Néogia a donc été subdivisé en deux sous-projets : d'une part les générateurs de code et d'autre part l'erp OfbizNéogia. Ce dernier a été ensuite ajouté au référentiel CVS de Néogia de la façon suivante : 1. Création d'un module ofbizneogia sur le référentiel CVS du projet Néogia dans lequel tous les fichiers de la version d'ofbiz utilisée par Néogia ont été importés. 2. Application de tous les patchs Néogia sur ofbizneogia. 29

30 3. Intégration des composants Néogia dans ofbizneogia Utilisation de branches de développement L'utilisation de branches de développements est essentiel lorsque l'on souhaite mettre en place une gestion de configuration car elles permettent d'isoler les développements réalisés et simplifient la gestion des spécificités de chaque branche. Pour le projet Néogia, l'approche dite en cascade a été privilégiée. Cette approche impose que le passage d'un développement d'une branche à une autre se fasse toujours dans le sens descendant pour éviter un maximum de conflits. Par la suite, nous allons distingué l'utilisation des branches pour le projet Néogia et l'utilisation des branches pour les projets clients car leur rôle diffère selon le cas. Dans le cadre du projet Néogia, l'utilisation de branches a pour objectif d'avoir à tout moment une version d'ofbiznéogia considérée comme stable, c'est-à-dire une version qui passe tous les tests fonctionnels. Cette version est utilisée pour le site de démonstration d'ofbiznéogia et sert de base pour les mises à jour des sites clients. La solution mise en oeuvre repose sur l'utilisation de quatres branches : la branche ofbiz : branche utilisée pour importer les nouvelles versions d'ofbiz sur lesquelles se base OfbizNéogia. la branche HEAD : branche dans laquelle tous les développements sont réalisés. la branche STABLE : branche dans laquelle on intègre tout nouveau développement qui ne casse pas la stabilité d'ofbiznéogia. la branche EXPERIMENTAL : branche utilisée pour réaliser de nouveaux développements ne pouvant être réalisés dans la branche HEAD. Cette branche est particulière car elle ne respecte pas l'approche en cascade. En effet, synchronisée à partir de HEAD, les développements réalisés dans cette branche ne passent pas directement dans STABLE mais doivent repasser dans HEAD. Figure 4.4. Utilisation de la branche STABLE d'ofbiznéogia 30

31 Mise en place de procédures de gestion de configuration Figure 4.5. Utilisation de la branche EXPERIMENTAL d'ofbiznéogia Dans le cadre d'un projet client, l'utilisation des branches est similaire à celui du projet Néogia mais elle doit aussi prendre en compte les différences de configuration des différents environnements déployés chez le client. la branche neogia : branche utilisée pour importer les nouvelles versions d'ofbiznéogia sur lesquelles se base le projet client. la branche HEAD : branche dans laquelle tous les développements spécifiques sont réalisés. la branche INTEGRATION : branche dans laquelle on intègre toute nouvelle fonctionnalité qui passe les tests de non-régression. la branche RECETTE ou PRODUCTION : branche dans laquelle on intègre toute nouvelle fonctionnalité qui passe les tests de recette client. Figure 4.6. Utilisation des branches dans un projet Client 31

32 3.4. Utilisation de tags Un tag sous CVS est un nom symbolyque permettant d'identifier une révision donnée d'un ensemble de fichiers. Lorsqu'un un tag est placé à la racine de l'arbre du projet, il constitue une graduation temporelle qui représente une version du projet à instant t. L'utilisation de tags est rendu obligatoire dès lors que l'on utilise des branches de développement sous CVS. En effet, lorsque l'on souhaite rapprocher deux branches pour faire passer des développements d'une branche à l'autre par exemple, il faut être capable d'identifier Figure 4.7. Exemple de fusion de branches Procédure 4.2. Fusion de branches sous CVS 1. Se placer dans la branche qui recevera le résultat de la fusion cvs update -CdP -r HEAD 2. Déterminer la branche ou le tag dont on souhaite récupérer les modifications 3. Déterminer le tag indiquant le début des modifications à prendre en contre 4. Récupérer les modifications apportées entre les deux tags précédents et les fusionner dans la brance courante cvs update -j NEOGIA_0_8_8 -j NEOGIA_0_8_9 5. Résoudre les conflits potentiels 6. Commiter le résultat de la fusion dans la branche courante cvs commit -m "merge with neogia vendor branch (NEOGIA_0_8_9)" Astuce Lorsqu'une branche a été sélectionnée au lieu d'un tag lors de l'étape 2, il faut penser à placer un tag sur tous les fichiers de la branche courant juste après le commit final. Ainsi, ce tag servira de point de départ si une fusion avec la même branche doit être recommencée plus tard. Il est possible d'éviter la multiplication du nombre de tags en reprenant toujours le même tag, par exemple EXP_LAST_HEAD_SYNC dans le cas d'une fusion entre les branches HEAD et EXPERIMENTAL. 32

33 Mise en place de procédures de gestion de configuration 4. Méthodologie de développement au sein du projet Néogia L'utilisation de CVS ne constitue pas à lui seul un outil de gestion de configuration car il n'intègre pas la notion de listes de changement présentée précédemment 1. Pour retrouver un niveau de fonctionnalités équivalent, nous allons utiliser un outil de gestion de projet fournit par le site du réseau libre-entreprise hébergeant le référentiel CVS du projet Néogia 2. Ces outils n'étant pas initialement prévus pour fonctionner ensemble, il est nécessaire d'introduire des procédures afin de formaliser leur utilisation dans les processus de développement du projet. Par ailleurs, l'utilisation de plusieurs branches de développement sous CVS demande beaucoup plus de rigueur par rapport à un véritable outils de gestion de configuration car CVS ne supporte l'atomicité des opérations au niveau de l'arbre du projet. Ainsi le passage des développements d'une branche à une autre ne doit être réalisée que par une seule personne à tout instant. D'où la nécessité de bien définir les procédures de gestion de configuration. Enfin, la mise en oeuvre de ces nouvelles méthodes de développement ne doit pas nuire à la productivité des développeurs et rendre le projet inaccessible à des personnes ayant un profil fonctionnnel plutôt que technique Définition des différents type de développement La première étape dans la mise au point des procédures de gestion de configuration est d'identifier les différents types de développement que l'on est amené à réaliser sur le projet Néogia. Ainsi on dénombre généralement trois types de développement : les corrections simples, lorsqu'elles se limitent à seul un fichier, qu'elles sont évidentes et que visiblement elles n'entraînent aucun effet de bord. Généralement, ce type de développement porte sur la correction de traductions, l'ajout/modification de commentaires, la correction d'erreurs de syntaxe ou de nommage, etc. les corrections de bugs qui font l'objet d'une déclaration sur le système de suivi des bugs du projet. On distingue les bugs spécifiques à Néogia à ceux d'ofbiz. l'ajout et/ou la modification de fonctionnalités Procédure d'intégration de corrections simples Les corrections simples sont le seul type de développement qui ne nécessite pas obligatoirement une revue de code pour passer dans la branche STABLE du projet. Cela signifie que si l'auteur de la correction dispose d'un environnement de développement basé sur la branche STABLE, il est autorisé à fusionner sa modification dans la branche STABLE en suivant la procédure décrite dans la section suivante. 1 Il n'est pas possible de rattacher plusieurs commits à une même tâche 2 Site du projet Néogia sur le Labs libre-entreprise [ 33

34 4.3. Procédure d'intégration de correction de bugs Néogia 1. Déclaration sur le système de suivi de bugs de Néogia Toute correction de bug dépassant le cadre de la correction simple définie précédemment doit faire l'objet d'une déclaration sur le tableau du projet. A l'issue de cette déclaration, un numéro de suivi sera attribué et utilisé pour identifier les modifications de fichiers se rapportant à ce bug. En outre, la description du bug doit inclure le scénario précis permettant de reproduire le bug car il sera utilisé ensuite par le relecteur pour valider la correction. 2. Correction du bug La correction du bug doit toujours être réalisée dans la branche de développement HEAD. Le passage en STABLE ne pourra être réalisé qu'après validation de la correction. Tous les commits lié à ce bug doivent inclure une référence à son numéro de suivi. Une fois corrigé, le développeur doit préfixé l'intitulé du bug par le mot clé [tobetested]. Par cette action, le relecteur sera automatiquement informé par mail pour valider la correction. 3. Revue de la correction Le relecteur désigné lors de la déclaration du bug, doit vérifier que le bug est corrigé dans les deux branches de développements. Si ce n'est pas le cas, il doit ajouter un commentaire à la déclaration du bug invitant le développeur à revoir sa correction. Lorsque le test est concluant, le relecteur remplace le prefix de l'intitulé du bug par [tostable]. Le passage en STABLE sera réalisé dans les jours qui suivent par la personne responsable du passage des développements entre les deux branches. 34

35 Mise en place de procédures de gestion de configuration 4.4. Procédure d'intégration de correction de bugs Ofbiz 1. Déclaration sur le système de suivi de bugs de Néogia Toujours déclarer les bugs Ofbiz dans le système de suivi de bugs de Néogia pour éviter des recherches sur le système de suivi de bugs d'ofbiz et permettre l'ajout de commentaires supplémentaires sur l'évolution de la correction dans Ofbiz. Le résumé du bug concernant Ofbiz doit être suffixé par [Ofbiz] et la liste des personnes assignées à ce bug doit contenir la ou les personnes responsables de la synchronisation avec Ofbiz. 2. Récupération de la dernière version d'ofbiz Pour qu'une correction de bug Ofbiz ait un maximum de chance d'être acceptée, elle doit toujours être réalisée par rapport à la dernière révision d'ofbiz. Ainsi les mainteneurs d'ofbiz n'auront aucune difficulté à l'appliquer. 3. Correction du bug dans Ofbiz Après avoir corrigé le bug, l'utilisation de la commande svn diff permet d'obtenir simplement le patch contenant la correction. À noter toutefois que cette commande ne semble pas inclure les nouveaux fichiers dans le patch. 4. Envoie de la correction sur le système de suivi de bugs d'ofbiz (JIRA) L'envoi d'un patch sur le système de suivi de bugs d'ofbiz permet d'obtenir un numéro de suivi qui sera ensuite utilisé pour identifier la correction dans OfbizNeogia. Ce numéro doit être ajouter au système de suivi de bugs de Néogia par l'intermédiaire d'un nouveau commentaire (Penser à inclure un lien direct vers JIRA). 5. Application de la correction sur OfbizNéogia L'application de la correction s'effectue toujours dans la branche de développement HEAD et le message de commit doit contenir les références au numéro de suivi de JIRA et de Néogia. Lors de l'application, le développeur doit prefixer et suffixer chaque modification par des commentaires spéciaux indiquant que la correction est en attente sur JIRA. Ces commentaires aident ensuite la personne responsable des synchronisations avec Ofbiz durant la mise à jour de la version d'ofbiz utilisée par Néogia. Exemple de commentaires pour un fichier xml : <!-- Begin JIRA-295 : Add percentsuccess in Quote -->. modification. modification. modification <!-- End JIRA-295 : Add percentsuccess in Quote --> 6. Évolution du statut du bug Lors la correction est acceptée ou refusée sur JIRA, l'auteur de la correction doit mettre à jour le système de suivi de bug en ajoutant un commentaire. En cas de refus sur JIRA, l'auteur doit indiquer si l'on conserve la correction telle quelle ou bien si une nouvelle correction doit être renvoyée sur JIRA. Le bug pourra être marqué clos s'il a été intégré lors d'une synchronisation avec Ofbiz ou s'il a été décidé de diverger par rapport à Ofbiz. 35

36 4.5. Procédure d'intégration de nouveaux développements 1. Déclaration d'une tâche sur le tableau de bord du projet Tout développement doit faire l'objet d'une déclaration de tâche sur le tableau bord du projet afin d'avoir une visibilité sur les développements en cours et de forcer une réflexion initiale sur la tâche à réaliser. Idéalement, la description de la tâche devrait contenir un maximum d'informations sur les cas d'utilisation, les scénarios de test, les implémentations envisagées et les dépendances avec d'autres tâches. Le développeur et le relecteur doivent être assignés à la tâche pour être automatiquement informés par mail de toute modification apportée à cette dernière. 2. Codage de la fonctionnalité Le codage d'une fonctionnalité se fait toujours dans la branche de développement HEAD. Chaque commit doit inclure une référence à la tâche pour aider la personne responsable des passages des développements de HEAD à STABLE à identifier les modifications pouvant être transférées. Ce formalisme permet de simuler la notion de liste de changements. Lorsque la tâche est terminée, le développeur doit préfixer le résumé de la tâche par le mot-clé [tobetested]. Par cette action, le relecteur de la tâche sera automatiquement informé par mail du changement d'état et pourra commencer la revue et le test de la fonctionnalité développée. 3. Revue de la fonctionnalité À l'aide du numéro de la tâche et des archives de la mailing-list cvscommits du projet Néogia, le relecteur pourra retrouver l'intégralité des commits réalisés pour cette tâche et vérifier dans la mesure du possible la validité du code. 4. Test de la fonctionnalité Idéalement, à partir des scénarios décris dans la tâche, le relecteur devrait être en mesure de réaliser un test de non-régression sous QAA. Ainsi, si la fonctionnalité doit être retravaillée par le développeur, le relecteur n'aura qu'à relancer le test lors de la revue suivante. De plus, ça enrichit la base des tests de non-régression, augmentant ainsi la qualité du projet. Lorsque la fonctionnalité est jugée apte à passer dans la branche STABLE, le relecteur doit changer le préfixe du résumé de la tâche à [tostable]. Sinon le relecteur ajoute un commentaire à la tâche en indiquant le refus de la validation. 5. Passage de la fonctionnalité dans la branche STABLE Le responsable du passage en STABLE des développements doit en premier lieu s'assurer que les tâches dont dépend celle-ci sont closes. Puis, pour chaque fichier modifié ou ajouté par la tâche, il doit transférer les modifications apportées dans la branche STABLE. Il doit ensuite vérifier que tous les tests de non-regression passent sans problème. Dans ce cas, il peut commiter les modifications dans STABLE et clôre la tâche sinon il ajoute un commentaire à la tâche en indiquant le refus du passage en STABLE. 36

37 Chapitre 5 Amélioration du MRP Dans le cadre d'un projet de fin d'études précédant ce stage, j'ai développé, pour l'application de gestion de production d'ofbiznéogia, le module MRP [PG05]. Un MRP est un processus de réapprovisionnement qui, à partir des demandes fermes et estimées de produits finis et des niveaux de stock courants, calcule les besoins en composants (quoi, combien et quand) permettant de répondre à la demande. Pour établir les besoins en composants le MRP se base sur la nomenclature des articles et sur les gammes opératoires. La partie la plus importante de ce projet était d'améliorer les résultats du MRP en lui ajoutant la prise en compte des capacités de production pour établir la date des besoins en composants. Bien que ce projet ait été mené à son terme, certains aspects secondaires ont du être mis de côté afin de terminer le projet dans les délais imposés. En particulier, l'intégration avec le reste de l'erp et la facilité d'utilisation de l'interface graphique nécessitent encore du travail avant d'être finalisés. 1. Amélioration du processus de lancement du MRP Lors des premières démonstrations client du MRP, une remarque est souvent revenue : la mise en oeuvre du MRP est trop complexe. En effet, pour lancer le calcul du MRP, l'utilisateur doit effectuer un certain nombre de tâches préparatoires : paramétrer une nouvelle exécution du MRP (MrpRun) : définir la date de début de l'horizon de planification, définir la durée de l'horizon de planification, définir le/les produits à étudier, définir le/les magasins de stocks à traiter; initialiser le MRP avec ces paramètres d'exécution; lancer le MRP. De plus, l'interface graphique du MRP souffrent de quelques défauts de jeunesse : l'interface propose des informations qui ne devraient pas être affichées à l'utilisateur car d'un usage interne; l'enchaînement des écrans n'est ni intuitif ni fonctionnel. Par exemple, l'affichage des erreurs rencontrées pendant l'exécution du MRP est réalisée sur une page différents des résultats du MRP. 37

38 Amélioration du MRP Figure 5.1. Interfaces graphiques initiales du MRP Après avoir mis en avant les différents éléments à revoir, le nouvel objectif est d'obtenir le lancement du MRP en un clic. Pour atteindre un tel résultat, la solution passe par un centralisation de l'interface graphique regroupant toutes les vues nécessaires à l'utilisateur et par l'enchaînement automatique des opérations pour simplifier le processus de lancement. 38

39 Amélioration du MRP Figure 5.2. Nouvelle interface de lancement du MRP La nouvelle interface de lancement se présente comme une vue de synthèse de toutes les informations liées au MRP. Elle se divise en deux parties : la partie gauche correspond aux paramètres et au statut de l'exécution du MRP, et la partie droite présente les résultats et les erreurs d'exécution rencontrées. Pour simplifier la configuration de l'exécution du MRP, les paramètres concernant l'horizon de planification sont pré-saisis en fonction de paramètres par défauts définis dans le fichier config/manufacturingparameters.properties de l'application manufacturing, et uniquement les champs utiles sont affichés. 39

40 Amélioration du MRP Figure 5.3. Visualisation des résultats du MRP 40

41 Amélioration du MRP 2. Intégration du MRP avec le module de gestion des stocks Bien que le MRP soit un module de la gestion de production de l'erp du fait de l'utilisation de nomenclatures, de gammes et d'ordres de fabrication, il est néanmoins fortement lié à la gestion des stocks. Or cet aspect du MRP n'a été que très peu traité lors de mon projet de fin d'étude. Les données d'entrée du MRP sont les demandes. Une demande peut être : la vente d'un article, un besoin pour un ordre de fabrication, etc. Elles se modélisent par des mouvements de stocks planifiés qui indiquent soit la sortie soit l'entrée dans le stock d'un magasin, d'une certaine quantité d'un produit donné à une date donnée. Initialement le MRP prend tous les mouvements de stocks, or on souhaiterait limiter l'exécution du MRP à magasin de stock donné. De plus, tous les articles ne doivent pas être traités par le MRP. En effet, il existe un paramètre de gestion qui indique quelle est la méthode de réapprovisionnement à utiliser pour un produit donné Prise en compte des magasins de stockage Dans OfbizNéogia, un magasin représente un emplacement de stockage qui peut aussi bien être un entrepôt, un magasin, une allée, une palette, etc. Les magasins sont donc organisés sous une forme hiérarchique dans la laquelle le magasin de plus haut niveau contient des sous magasins. Cette organisation permet d'avoir des paramètres de gestion spécifiques à chaque emplacement. Par exemple, lorsque l'on demande le niveau de stock d'un article à un magasin, on obtient ainsi le niveau de stock cumulé du magasin en question ainsi que ses sous-magasins. Figure 5.4. Organisation des magasins de stockage dans OfbizNéogia La règle de gestion qui nous intéresse ici est que le MRP devrait toujours être exécuté sur un magasin donné. Lorsque l'utilisateur ne fournit aucun magasin, la règle de gestion qui s'applique par défaut est d'exécuter le MRP successivement sur chacun des magasins racines (sans parent). Il donc fallu modifier le MRP en conséquence. La première étape pour ajouter la prise en compte du magasin de stockage par le MRP a été de modifier son diagramme UML (cf. Annexe D, Diagramme UML du MRP) pour ajouter une association 1->0..1 entre la configuration d'exécution du MRP (Entité MrpRun) et l'entité Magasin (NFacility). Puis à l'aide des générateurs de code, le schéma de base de données, les objets java et les interfaces graphiques ont été mis à jour grâce à une simple regénération. 41

42 Amélioration du MRP Ainsi, le magasin sélectionné par l'utilisateur sera automatiquement disponible lors de l'exécution du MRP. L'étape suivante a concerné la modification de l'algorithme du MRP pour prendre en compte ce nouveau paramètre lors de la sélection des mouvements de stock planifiés (les demandes). La règle de gestion utilisée est que le MRP ne sélectionne que les mouvements de stocks dont le magasin appartient à la descendance du magasin sélectionné par l'utilisateur. La principale difficulté dans ce type d'application réside dans l'accès à la base de données. Or on ne peut pas se permettre d'interroger la base de données pour tester chaque mouvement de stock. Ici la solution a consisté à déterminer la liste de tous les sous-magasins de celui sélectionné par l'utilisateur et de créer une requête qui ne prend en compte que les mouvements correspondant Prise en compte de la méthode de réapprovisionnement d'un article À ce jour, OfbizNéogia propose trois méthodes de réapprovisionnement automatique : par le MRP en fonction des demandes futures; au point de commande lorsque le niveau de stock passe en dessous d'un certain seuil; automatiquement à chaque commande de vente. Le MRP doit donc tenir compte de ce paramètre et ne traiter que les mouvements de stocks planifiés concernant la première méthode. La principale difficulté réside dans l'implémentation de la règle de gestion permettant de déterminer la méthode de réapprovisionnement en fonction du magasin et du produit en cours de traitement : 1. Recherche du paramètre de l'article au niveau du magasin sélectionné par l'utilisateur 2. Recherche du paramètre de l'article au niveau des magasins parents 3. Recherche du paramètre définit au niveau de l'article 4. Recherche du paramètre au niveau du centre de profit (non implémenté) 5. Recherche du paramètre par défaut dans un fichier de configuratoin (non implémenté) 42

43 Chapitre 6 Mise en place de DocBook pour la documentation du projet Néogia Initialement, la documentation du projet Néogia se présentait sous la forme de fichiers rst 1. Ce format, créé à l'origine pour la documentation des programmes écrits en python, permet la génération de pages html simples et/ou de documents imprimables de type pdf. Cependant, ce format de documentation présente quelques inconvénients : La syntaxe n'est pas évidente pour le débutant. Or, l'intégration de nouveaux contributeurs dans un projet de logiciel libre passe souvent par la rédaction de documentations pour comprendre le fonctionnement du logiciel. Contrairement à ce que laisse penser le nom du format rst, la syntaxe n'est pas très structurée. En effet, aucune grammaire ne définit les règles d'imbrication des différents éléments de structuration (chapitres, sections, sous-sections) ainsi il n'est pas possible d'assurer que toutes les documentations du projet respecteront le même formalisme au final. À la fin de mon stage précédent, j'avais proposé à Néréide d'utiliser le format de documentation DocBook à la place de rst pour le projet Néogia. Après l'avoir utilisé avec succès pour la rédaction de mon rapport de projet de fin d'étude, Néréide m'a demandé de mettre en oeuvre DocBook pour le projet Néogia et de prévoir un mécanisme de migration des documentations existantes vers DocBook. 1. Présentation DocBook est un langage de balisage conçu à l'origine pour la documentation technique informatique. C'est à l'origine une définition de type de document (DTD) SGML développée par l'éditeur O'Reilly pour les besoins de l'édition technique et plus particulièrement l'informatique. Elle a été porté depuis sous forme de schéma XML. Exemple 6.1. Exemple minimaliste d'un document DocBook?xml version="1.0" encoding="utf-8"?!doctype book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" " book lang="fr" chapter title>mon premier chapitre /title para Hello World! /para /chapter /book 1 ReStructuredText markup syntax [ 43

44 Mise en place de DocBook pour la documentation du projet Néogia 1.1. Organisation hiérarchique Il existe actuellement trois types de document DocBook : les articles (article), les livres (book), et les ensembles de livres (set). Chacun de ces types de document définit les éléments structurants que l'on pourra rencontrer au sein du document. Ainsi, un article est principalement composé de sections, de sous-sections et de paragraphes. Le type livre introduit des préfaces, des parties, des chapitres. Exemple 6.2. Exemple d'article DocBook article title Article très simple /title section title Section très courte /title para Bonjour tout le monde! /para section title sous section /title para Ceci est un autre paragraphe... /para /section /section /article 1.2. Informations relatives au document DocBook permet d'ajouter de nombreuses informations concernant le document tels que ses auteurs, sa date de publication, son éditeur, son copyright, ses différents révisions, etc. Toutes ces informations pourront ensuite apparaître sur le document final avec toujours le même formalisme. Exemple 6.3. Exemple d'informations relatives au document bookinfo title Rapport de stage /title date 1 Août 2005 /date author firstname Peter /firstname othername Goron /othername /author /bookinfo Note Il est possible de placer ces informations sur tout élément structurant (chapitre, section,...) notamment lorsque le document est rédigé par plusieurs personnes. Par ailleurs, il est important de faire figurer un maximum d'informations même si on ne souhaite pas les faire apparaître dans le document final. Il sera toujours possible de configurer leur affichage lors de la génération du document. 44

45 2. Intérêt Le principal intérêt de DocBook par rapport à d'autres outils de traitement de texte tel que TeX, réside dans l'absence totale de mise en forme au niveau du document source. Le document est ainsi complètement indépendant du média de sortie utilisé, la mise en page étant réalisée à l'aide de feuille de style XSL lors de la génération du document final. L'auteur peut alors se consacrer entièrement à son contenu plutôt qu'à sa forme. De plus, DocBook introduit un grand nombre de balises permettant de donner un sens sémantique aux mots et aux phrases afin de faciliter l'indexation des documents par des moteurs de recherche. Le nombre de médias de sortie supportés par DocBook est potentiellement infini dès l'instant que le format de sortie n'est pas binaire. Dans ce dernier cas, il faut faire appel à une représentation intermédiaire et à un outil de conversion pour obtenir le document final. Par exemple, ce rapport a été rédigé en DocBook, puis transformé en xsl-fo 2 à l'aide de la feuille de style docbook-fo, avant d'être converti en pdf par Fop 3. La transformation d'un document Docbook s'effectue à l'aide d'un processeur XSLT tels que xalan ou xsltproc qui va se charger de convertir chaque élément du langage DocBook en élément du format de sortie défini par la feuille de style. Figure 6.1. Processus de génération d'un document au format DocBook L'autre intérêt majeur de DocBook est qu'il est entrain de devenir un standard en matière de documentation technique dans l'industrie du logiciel. Maintenu par le consortium OASIS et utilisé par les plus grands groupes du secteur et par la plupart des logiciels libres, ce standard assure que la documentation restera lisible et pérenne dans le temps indépendamment des outils utilisés. Enfin, contrairement à rst, il exite de nombreux outils permettant d'éditer des documents DocBook : OpenOffice, Éditeur XML d'eclipse WTP, Vex, etc. 2 Langage permettant de formatter l'affichage et/ou l'impression d'un document XML (Extensible Stylesheet Language [ 3 Formatting Objects Processor [ 45

46 Mise en place de DocBook pour la documentation du projet Néogia 3. Intégration dans OfbizNéogia La documentation d'ofbiznéogia est gérée par une petite application de gestion de contenu développée par les stagiaires de Néréide sous le module website d'ofbiznéogia. Cette application est ensuite utilisée pour générer le site web neogia.org à partir des différents éléments de documentation du projet. Ces derniers doivent être au format HTML mais sans les balises <html> et <body> car elles seront automatiquement créées lors de la génération de la page HTML finale. L'intégration du format DocBook pour la documentation du projet a nécessité la mise en place de deux chaînes de convertion pour conserver la compatibilité avec le format RST. La première s'occupe de la conversion des fichiers rst au format DocBook : les fichiers rst sont d'abord convertis dans un format xml intermédiaire. Puis les fichiers obtenus sont ensuite convertis au format DocBook à l'aide d'une feuille de style adéquate et d'un processeur XSLT. La seconde se charge de la conversion des fichiers DocBook au format de documentation utilisé sur le site web. Cette conversion est assurée par une feuille de style Docbook vers HTML légèrement modifiée pour ne pas inclure les balises <html> et <body>. Figure 6.2. Processus de génération mis en oeuvre 46

47 <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0"> <!-- stylesheet based on docbook html stylesheet --> <!-- location of the docbook html stylesheet --> <xsl:import <xsl:param name="chunker.output.encoding">utf-8</xsl:param> <xsl:param name="section.autolabel">1</xsl:param> <!-- avoid generation of <html>, <head>, <body> stuff --> <xsl:template match="article" mode="process.root"> <xsl:apply-templates select="."/> </xsl:template> <xsl:output method="html" encoding="utf-8" indent="yes"/> </xsl:stylesheet> Figure 6.3. Feuille de style utilisée pour générer la documentation du projet 47

48 Bilan

49 Chapitre 7 Conclusion 1. Bilan professionnel L'un des attraits de ce stage était de pouvoir travailler sur des logiciels libres à la pointe de la technologie. Le développement d'applications d'entreprise dans un environnement J2EE a atteint un très haut niveau de standardisation me permettant d'acquérir une certaine expérience dans le domaine des architectures logicielles. Par ailleurs, le développement des procédures de gestion de configuration est le premier projet que je mène de sa conception jusqu'au déploiement chez un client. Ce projet m'a permis de prendre conscience de l'importance de la documentation et de la formation des utilisateurs lors de la mise en production des procédures. Outre l'aspect purement technique, le stage m'a aussi considérablement apporté sur le côté fonctionnel, notamment dans la modélisation des systèmes d'information d'entreprise. J'ai ainsi pu découvrir certains domaines de l'informatique de gestion et les règles qui s'y appliquent. 2. Bilan personnel Choisir d'effectuer un stage dans une SSLL était pour moi l'occasion de développer et de travailler entièrement avec des logiciels libres, expérience que je souhaitais mener depuis un certain temps. Mais cela m'a aussi permis de m'investir dans des projets libres et de découvrir le travail communautaire. Ce dernier point a été véritablement enrichissant grâce aux divers collaborations effectuées avec les communautés de développeurs des projets Ofbiz et Néogia. 49

50 Annexes

51 Annexe A Procédure de synchronization d'ofbiznéogia avec Ofbiz 1. Objet Cette procédure a pour objectif de mettre à jour la version d'ofbiz sur laquelle se base le projet OfbizNéogia. Elle consiste à télécharger une nouvelle version d'ofbiz et à l'intégrer dans les différentes branches de développement du projet. Les synchronisations avec Ofbiz doivent être réalisées au rythme d'une fois tous les quinze jours pour éviter que les deux projets ne divergent trop. De plus, chaque synchronisation devrait avoir lieu le même jour de la semaine pour que les développeurs sachent que tel jour est consacré à la mise à jour du projet et que des problèmes peuvent survenir suite à cette action. 2. Pré-requis Le développeur en charge de la synchronisation doit disposer d'un accès en écriture au référentiel cvs d'ofbiznéogia et doit être familier à l'utilisation des branches sous cvs. En outre, une connaissance approfondie des deux projets permet de résoudre plus rapidement les conflits potentiels lors de la synchronisation. 3. Procédure 1. Télécharger la dernière révision d'ofbiz. peter@socrate:~/projets/import$ svn export ofbiz A ofbiz A ofbiz/.classpath A ofbiz/startofbiz.sh A ofbiz/website A ofbiz/website/news.html A ofbiz/website/entity-overview.html... A ofbiz/framework/webapp/entitydef A ofbiz/framework/webapp/entitydef/entitygroup.xml A ofbiz/framework/webapp/entitydef/entitymodel.xml A ofbiz/framework/webapp/build.xml A ofbiz/build.xml Exported revision peter@socrate:~/projets/import$ Avertissement La commande svn export permet de télécharger ofbiz sans les fichiers de contrôle du référentiel subversion. Par conséquent, il ne sera pas possible de 51

52 Procédure de synchronization d'ofbiznéogia avec Ofbiz déterminer le numéro de révision d'ofbiz à l'aide de la commande svn info. Il faut donc bien noter le numéro de révision affiché car il sera nécessaire pour la suite de la procédure. 2. Importer cette nouvelle version d'ofbiz dans la branche vendor du référentiel cvs d'ofbiznéogia sous le tag OFBIZ_revision. cd ofbiz export CVS_RSH=ssh export cvs import -ko -m "Import ofbiz 5740" ofbizneogia ofbiz OFBIZ_5740 cvs import: Importing /cvsroot/neogia/ofbizneogia/framework/jotm U ofbizneogia/framework/jotm/build.xml U ofbizneogia/framework/jotm/ofbiz-component.xml... cvs import: Importing /cvsroot/neogia/ofbizneogia/framework/webapp/entitydef U ofbizneogia/framework/webapp/entitydef/entitygroup.xml U ofbizneogia/framework/webapp/entitydef/entitymodel.xml 119 conflicts created by this import. Use the following command to help the merge: cvs -j<prev_rel_tag> -jofbiz_5679 ofbizneogia Avertissement La commande cvs import est une des rares commandes de cvs où il est difficile de revenir en arrière en cas d'erreur. Il faut donc vérifier à plusieurs reprises que la commande est correctement tapée avant de la lancer. Important La branche vendor d'un référentiel cvs a un comportement particulier par rapport à une branche de développement standard : Tout nouveau fichier ajouté à la branche vendor est automatiquement ajouté à la branche HEAD. Toute modification apportée à un fichier dans la branch vendor passe automatiquement dans HEAD s'il n'a jamais été modifié dans cette branche. Tout fichier supprimé entre deux imports successifs ne sera pas supprimé de la branche vendor. Il ne sera simplement pas taggé avec le nouveau tag d'import. Donc suite à l'import de la nouvelle version d'ofbiz dans la branche vendor, une partie des modifications sont déjà passées dans la branche HEAD. Cette branche sera donc instable tant que les fichiers modifiés à la fois dans les 52

53 deux projets n'auront pas été synchronisés. 3. Remplacer de la copie locale d'ofbizneogia par la dernière version HEAD 4. Fusionner les modifications apportées entre la précédente version d'ofbiz et la nouvelle dans la branche HEAD du référentiel CVS de d'ofbiznéogia. 53

54 Procédure de synchronization d'ofbiznéogia avec Ofbiz 54

55 Annexe B Création d'un projet client basé sur neogia Ce document présente la mise en oeuvre d'un serveur CVS dans un environnement de type UNIX comme outil de gestion de configuration pour le suivi de projets client. 1. Pré-requis Disposer d'une machine équipée d'un système d'exploitation de type UNIX et avec suffisamment d'espace disque pour conserver le référentiel (généralement 3 fois la taille initiale du projet ~ 1Go). Cette machine doit disposer d'un mécanisme de sauvegarde. Les développeurs du projet doivent avoir un accès SSH à cette machine. 2. Préparation du serveur La préparation du serveur doit se faire connecté sous l'utilisateur root. Installation de CVS : soit par les sources, soit par un paquet binaire propre au système d'exploitation. root@socrate:~ # apt-get install cvs Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: cvs 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. Need to get 0B/1434kB of archives. After unpacking 3097kB of additional disk space will be used. Preconfiguring packages... Selecting previously deselected package cvs. (Reading database files and directories currently installed.) Unpacking cvs (from.../cvs_1%3a ubuntu0.1_i386.deb)... Setting up cvs ( ubuntu0.1)... root@socrate:~ # which cvs /usr/bin/cvs Création de la racine du serveur CVS root@socrate:~ # mkdir /var/cvsroot root@socrate:~ # ls -l /var grep cvsroot drwxr-xr-x 2 root root :21 cvsroot root@socrate:~ # ln -s /var/cvsroot /cvsroot root@socrate:/ # ls -l / grep cvsroot lrwxrwxrwx 1 root root :33 cvsroot -> /var/cvsroot Création du répertoire contenant les verrous CVS root@socrate:/ # mkdir /var/lock/cvs root@socrate:/ # ls -l /var/lock grep cvs 55

56 Création d'un projet client basé sur neogia drwxr-xr-x 2 root root :24 cvs root@socrate:/ # chmod ugo+rw /var/lock/cvs root@socrate:/ # ls -l /var/lock grep cvs drwxrwxrwx 2 root root :24 cvs root@socrate:~ # Création du groupe d'utilisateurs correspondant aux développeurs ayant un accès en écriture au référentiel du projet root@socrate:~ # addgroup neogiacvs Adding group `neogiacvs' (1002)... Done. root@socrate:~ # Il faut ajouter les développeurs du projet au groupe. root@socrate:~ # adduser peter neogiacvs Adding user `peter' to group `neogiacvs'... Done. Création du référentiel du projet root@socrate:~ # mkdir /cvsroot/neogia root@socrate:~ # ls -l /cvsroot/ total 4 drwxr-xr-x 2 root root :05 neogia root@socrate:~ # chgrp neogiacvs /cvsroot/neogia root@socrate:~ # ls -l /cvsroot/ total 4 drwxr-xr-x 2 root neogiacvs :05 neogia root@socrate:~ # chmod g+ws /cvsroot/neogia root@socrate:~ # ls -l /cvsroot/ total 4 drwxrwsr-x 2 root neogiacvs :05 neogia Initialisation du référentiel root@socrate:~ # cvs -d /cvsroot/neogia init root@socrate:~ # ls -l /cvsroot/neogia total 4 drwxrwsr-x 3 root neogiacvs :40 CVSROOT root@socrate:~ # ls -l /cvsroot/neogia/cvsroot total 84 -r--r--r-- 1 root neogiacvs :40 checkoutlist -r--r--r-- 1 root neogiacvs :40 checkoutlist,v -r--r--r-- 1 root neogiacvs :40 commitinfo -r--r--r-- 1 root neogiacvs :40 commitinfo,v -r--r--r-- 1 root neogiacvs :40 config -r--r--r-- 1 root neogiacvs :40 config,v -r--r--r-- 1 root neogiacvs :40 cvswrappers -r--r--r-- 1 root neogiacvs :40 cvswrappers,v drwxrwsr-x 2 root neogiacvs :40 Emptydir -rw-rw-r-- 1 root neogiacvs :40 history -r--r--r-- 1 root neogiacvs :40 loginfo -r--r--r-- 1 root neogiacvs :40 loginfo,v -r--r--r-- 1 root neogiacvs :40 modules -r--r--r-- 1 root neogiacvs :40 modules,v 56

57 -r--r--r-- 1 root neogiacvs :40 notify -r--r--r-- 1 root neogiacvs :40 notify,v -r--r--r-- 1 root neogiacvs :40 rcsinfo -r--r--r-- 1 root neogiacvs :40 rcsinfo,v -r--r--r-- 1 root neogiacvs :40 taginfo -r--r--r-- 1 root neogiacvs :40 taginfo,v -rw-rw-r-- 1 root neogiacvs :40 val-tags -r--r--r-- 1 root neogiacvs :40 verifymsg -r--r--r-- 1 root neogiacvs :40 verifymsg,v 3. Configuration du référentiel À faire sous un utilisateur faisant parti du groupe neogiacvs. Définir les variables d'environnement permettant de localiser le référentiel peter@itux:~/projets/test$ export CVS_RSH=ssh peter@itux:~/projets/test$ export CVSROOT=:ext:peter@socrate:/cvsroot/neogia Récupérer les fichiers d'administration du référentiel peter@itux:~/projets/test$ cvs co CVSROOT cvs checkout: Updating CVSROOT U CVSROOT/checkoutlist U CVSROOT/commitinfo U CVSROOT/config U CVSROOT/cvswrappers U CVSROOT/loginfo U CVSROOT/modules U CVSROOT/notify U CVSROOT/rcsinfo U CVSROOT/taginfo U CVSROOT/verifymsg peter@itux:~/projets/test$ cd CVSROOT peter@itux:~/projets/test/cvsroot$ ls -l total 44 -rw-r--r-- 1 peter peter :58 checkoutlist -rw-r--r-- 1 peter peter :58 commitinfo -rw-r--r-- 1 peter peter :58 config drwxr-xr-x 2 peter peter :17 CVS -rw-r--r-- 1 peter peter :42 cvswrappers -rw-r--r-- 1 peter peter :58 loginfo -rw-r--r-- 1 peter peter :58 modules -rw-r--r-- 1 peter peter :58 notify -rw-r--r-- 1 peter peter :58 rcsinfo -rw-r--r-- 1 peter peter :58 taginfo -rw-r--r-- 1 peter peter :58 verifymsg 3.1. Activation des logs Pour garder une trace des modifications apportées à chaque module du référentiel, il faut activer l'enregistrement des commits réalisés dans un fichier de log (Il est aussi possible d'envoyer les commits réalisés sur une mailing-list). Éditer le fichier loginfo avec un éditeur de texte et décommenter la dernière ligne. 57

58 Création d'un projet client basé sur neogia # The "loginfo" file controls where "cvs commit" log information # is sent. The first entry on a line is a regular expression which must match # the directory that the change is being made to, relative to the # $CVSROOT. If a match is found, then the remainder of the line is a filter # program that should expect log information on its standard input. # # If the repository name does not match any of the regular expressions in this # file, the "DEFAULT" line is used, if it is specified. # # If the name ALL appears as a regular expression it is always used # in addition to the first matching regex or DEFAULT. # # If any format strings are present in the filter, they will be replaced as follows: # %p = path relative to repository # %r = repository (path portion of $CVSROOT) # %{svv} = attribute list = file name, old version number (pre-checkin), # new version number (post-checkin). When either old or new revision is # unknown, doesn't exist, or isn't applicable, the string "NONE" will be # placed on the command line instead. # # Note that %{svv} is a list operator and not all elements are necessary. Thus %{sv} is # a legal format string, but will only be replaced with file name and new revision. # it also generates multiple arguments for each file being operated upon. i.e. if two # files, file1 & file2, are being commited from 1.1 to version and from # to , respectively, %{svv} will generate the following six arguments in this # order: file1, 1.1, , file2, , # # For example: #DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog # or DEFAULT (echo ""; id; echo %{svv}; date; cat) >> $CVSROOT/CVSROOT/commitlog Ce fichier active l'enregistrement des commits réalisés dans le fichier commitlog situé dans le dossier CVSROOT du référentiel. Commiter les modifications du fichier à l'aide de la commande suivante : peter@itux:~/projets/test/cvsroot$ cvs commit -m "Activate log of commits" loginfo /cvsroot/neogia/cvsroot/loginfo,v <-- loginfo new revision: 1.2; previous revision: 1.1 cvs commit: Rebuilding administrative file database 3.2. Configuration des verrous CVS Pour autoriser un accès en lecture-seule au référentiel, il faut forcer CVS à placer ses verrous hors du référentiel qui à des droits d'accès limités au groupe neogiacvs. Éditer le fichier config avec un éditeur de texte et décommenter la ligne commençant par LockDir. # Set this to "no" if pserver shouldn't check system users/passwords #SystemAuth=no # Put CVS lock files in this directory rather than directly in the repository. LockDir=/var/lock/cvs # Set `TopLevelAdmin' to `yes' to create a CVS directory at the top # level of the new working directory when using the `cvs checkout' # command. 58

59 #TopLevelAdmin=no # Set `LogHistory' to `all' or `TOEFWUPCGMAR' to log all transactions to the # history file, or a subset as needed (ie `TMAR' logs all write operations) #LogHistory=TOEFWUPCGMAR # Set `RereadLogAfterVerify' to `always' (the default) to allow the verifymsg # script to change the log message. Set it to `stat' to force CVS to verify # that the file has changed before reading it (this can take up to an extra # second per directory being committed, so it is not recommended for large # repositories. Set it to `never' (the previous CVS behavior) to prevent # verifymsg scripts from changing the log message. #RereadLogAfterVerify=always # Set `UserAdminOptions' to the list of `cvs admin' commands (options) # that users not in the `cvsadmin' group are allowed to run. This # defaults to `k', or only allowing the changing of the default # keyword expansion mode for files for users not in the `cvsadmin' group. # This value is ignored if the `cvsadmin' group does not exist. # # The following string would enable all `cvs admin' commands for all # users: #UserAdminOptions=aAbceIklLmnNostuU # Set `UseNewInfoFmtStrings' to `no' if you must support a legacy system by # enabling the deprecated old style info file command line format strings. # Be warned that these strings could be disabled in any new version of CVS. UseNewInfoFmtStrings=yes Commiter les modifications du fichier à l'aide de la commande suivante : peter@itux:~/projets/test/cvsroot$ cvs commit -m "Setup lock dir location" config /cvsroot/neogia/cvsroot/config,v <-- config new revision: 1.2; previous revision: 1.1 cvs commit: Rebuilding administrative file database 3.3. Configuration des fichiers binaires Lorsque le projet Néogia sera importé dans la branche vendeur du référentiel, il ne sera pas possible de préciser le format des fichiers (CVS gère différemment les fichiers binaires et les fichiers textes). Il faut donc préciser au serveur CVS quels seront les fichiers à considérer comme binaires. Éditer le fichier cvswrapper avec un éditeur de texte pour qu'il contienne les lignes suivantes : # This file affects handling of files based on their names. # # The -m option specifies whether CVS attempts to merge files. # # The -k option specifies keyword expansion (e.g. -kb for binary). # # Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or.cvswrappers) # # wildcard [option value][option value]... # # where option is one of # -f from cvs filter value: path to filter # -t to cvs filter value: path to filter 59

60 Création d'un projet client basé sur neogia # -m update methodology value: MERGE or COPY # -k expansion mode value: b, o, kkv, &c # # and value is a single-quote delimited value. # For example: # java file *.class -k 'b' *.jar -k 'b' *.jks -k 'b' *.raj -k 'b' *.key -k 'b' # image document *.gif -k 'b' *.jpg -k 'b' *.jpeg -k 'b' *.png -k 'b' *.psd -k 'b' # PDF document *.pdf -k 'b' # openoffice document *.sdd -k 'b' *.sxi -k 'b' *.sxw -k 'b' # mozilla extension *.xpi -k 'b' # UML document *.zargo *.zuml Commiter les modifications du fichier à l'aide de la commande suivante : peter@itux:~/projets/test/cvsroot$ cvs commit -m "Add file extensions that are considered as binary under ofbizneogia" cvswrappers /cvsroot/neogia/cvsroot/cvswrappers,v <-- cvswrappers new revision: 1.2; previous revision: 1.1 cvs commit: Rebuilding administrative file database La configuration du référentiel CVS est terminée et le dossier CVSROOT local peut être supprimé. peter@itux:~/projet/test/cvsroot$ cd.. peter@itux:~/projet/test$ rm -rf CVSROOT 4. Import d'ofbiznéogia dans le référentiel CVS La première étape consiste à récupérer la dernière version stable d'ofbiznéogia depuis le cvs du projet Néogia. peter@itux:~/projet/test$ export CVS_RSH=ssh peter@itux:~/projet/test$ export 60

61 cvs export -r NEOGIA_0_8_0 ofbizneogia... cd ofbizneogia Puis il faut importer ofbizneogia dans la branche vendeur de notre référentiel à l'aide de la commande cvs import. Les fichiers sont importés sans appliquer de substitution pour simplifier les mises à jour vers des versions plus récentes d'ofbizneogia par la suite. export CVS_RSH=ssh export cvs import -ko -m "Import of ofbizneogia (STABLE,NEOGIA_0_8_0)" ofbizneogia neogia NEOGIA_0_8_0... Enfin, le dossier ofbizneogia ayant servit à réaliser l'import peut être supprimé. cd.. rm -rf ofbizneogia 5. Procédure de sauvegarde et de restauration du référentiel 5.1. Sauvegarde # cd /var # tar cjf ~/cvsroot.tar.bz2 cvsroot 5.2. Restauration # cd /var # mv cvsroot cvsroot.old # tar xzf ~/cvsroot.tar.bz2 # rm -rf cvsroot.old 61

62 Annexe C Procédure de mise à jour d'un projet client basé sur Néogia Cette procédure consiste à récupérer la dernière version STABLE d'ofbizneogia, à l'importer dans la branche neogia du référentiel client et à corriger les conflits qui pourraient se produire suite à la mise à jour de fichiers modifiés par/pour le client. 1. Déterminer quelle est la dernière version STABLE d'ofbiznéogia Les sorties de nouvelles versions STABLE d'ofbiznéogia sont annoncées sur la mailing-list neogia-announce [ À chaque version STABLE correspond un tag sur le référentiel cvs d'ofbizneogia qui se présente sous la forme suivante : NEOGIA_x_y_z où x.y représentent le numéro de la version et z le numéro de révision. z est incrémenté à chaque fois que des modifications sont apportées et qu'elles n'engendrent pas pour autant une nouvelle version, par exemple, des corrections de bugs, des traductions, etc. Par exemple lors de la rédaction de ce document, la dernière version STABLE d'ofbiznéogia était NEOGIA_0_8_9. 2. Récupérer la dernière version STABLE d'ofbiznéogia Dans un répertoire quelconque situé sur la machine de développement, il faut réaliser un export du référentiel néogia. Cette opération consiste à télécharger ofbizneogia depuis cvs sans pour autant conserver les informations CVS. njerome@admin:~/projets$ mkdir MAJ_Neogia njerome@admin:~/projets$ cd MAJ_Neogia njerome@admin:~/projets$ export CVSROOT= :pserver:anonymous@cvs.labs.libre-entreprise.org:/cvsroot/neogia njerome@admin:~/projets/maj_neogia$ cvs login njerome@admin:~/projets/maj_neogia$ cvs -z3 export -r NEOGIA_0_8_9 ofbizneogia Suite à l'exécution de cette commande, un dossier ofbizneogia est créé sans contenir aucune information CVS relative au référentiel néogia. 3. Importer de la nouvelle version d'ofbizneogia dans le référentiel client njerome@admin:~/projets/maj_neogia$ export CVS_RSH=ssh njerome@admin:~/projets/maj_neogia$ export CVSROOT= :ext:njerome@ :/cvsroot/saitek njerome@admin:~/projets/maj_neogia$ cd ofbizneogia njerome@admin:~/projets/maj_neogia/ofbizneogia $ cvs import -ko 62

63 Procédure de mise à jour d'un projet client basé sur Néogia -m "Import ofbizneogia (STABLE, NEOGIA_0_8_9)" ofbizneogia neogia NEOGIA_0_8_9 Suite à cette commande, le dossier ofbizneogia depuis lequel l'import a été réalisé, peut être supprimé sans risque pour la suite de cette procédure. 4. Résolution des conflits dans la branche de développement Lors d'un import, CVS passe automatiquement tous les fichiers ne présentant pas de conflits dans la branche de développement (HEAD). Ainsi dans certains cas, cette branche peut se trouver dans un état intermédiaire. Un développeur doit intervenir pour résoudre les conflits potentiels. Sous Eclipse : 1. Récupérer la branche de développement HEAD. 2. Réaliser une fusion avec la branche neogia en indiquant comme tag de départ la version précédente de Néogia (ex. NEOGIA_0_8_0). 3. Résoudre tous les conflits. 4. Recompiler et relancer ofbizneogia pour vérifier que la mise à jour n'a pas entraîné de problèmes sur le code spécifique du client. 5. Commiter les fichiers modifiés. 63