Rapport de stage - Libre

Transcription

Rapport de stage
Intégration technique et
fonctionnelle entre Ofbiz et Neogia
Peter Goron
Rapport de stage: Intégration
fonctionnelle entre Ofbiz et Neogia
Peter Goron
technique
et
Table des matières
Remerciements ...................................................................................................... viii
Introduction ............................................................................................................. ix
I. Présentation ......................................................................................................... 10
1. Présentation de Néréide .............................................................................. 11
1. Néréide ............................................................................................... 11
2. Le réseau Libre-Entreprise ................................................................... 12
3. Le réseau Libre Partage ....................................................................... 12
2. Présentation d'Ofbiz .................................................................................... 14
1. Une architecture .................................................................................. 15
2. Un framework ...................................................................................... 16
2.1. L'Entity Engine ......................................................................... 17
2.2. Le Service Engine ..................................................................... 17
2.3. Le Control Servlet ..................................................................... 17
3. Des applications .................................................................................. 19
3. Présentation de Néogia ................................................................................ 20
1. Les enjeux de la génération de code .................................................... 21
2. Les applications Néogia ....................................................................... 22
II. Développements réalisés ..................................................................................... 23
4. Mise en place de procédures de gestion de configuration ............................. 24
1. Présentation de la gestion de configuration .......................................... 25
1.1. Notion de listes des changements ............................................. 25
1.2. Notion de branches ................................................................... 25
2. Organisation initiale du projet Néogia ................................................... 27
2.1. Présentation ............................................................................. 27
2.2. Ses défauts .............................................................................. 28
3. Solution mise en oeuvre ...................................................................... 29
3.1. Choix du système de gestion de version .................................... 29
3.2. Réorganisation du projet Néogia ............................................... 29
3.3. Utilisation de branches de développement ................................ 30
3.4. Utilisation de tags ..................................................................... 31
4. Méthodologie de développement au sein du projet Néogia .................... 33
4.1. Définition des différents type de développement ....................... 33
4.2. Procédure d'intégration de corrections simples .......................... 33
4.3. Procédure d'intégration de correction de bugs Néogia ............... 34
4.4. Procédure d'intégration de correction de bugs Ofbiz .................. 35
4.5. Procédure d'intégration de nouveaux développements .............. 36
5. Amélioration du MRP ................................................................................... 37
1. Amélioration du processus de lancement du MRP ................................. 37
2. Intégration du MRP avec le module de gestion des stocks ..................... 41
2.1. Prise en compte des magasins de stockage ............................... 41
2.2. Prise en compte de la méthode de réapprovisionnement d'un article
........................................................................................................ 42
6. Mise en place de DocBook pour la documentation du projet Néogia .............. 43
1. Présentation ........................................................................................ 43
1.1. Organisation hiérarchique ......................................................... 43
1.2. Informations relatives au document .......................................... 44
2. Intérêt ................................................................................................. 44
3. Intégration dans OfbizNéogia ............................................................... 46
III. Bilan ................................................................................................................... 48
7. Conclusion .................................................................................................. 49
1. Bilan professionnel .............................................................................. 49
iv
Rapport de stage
2. Bilan personnel ................................................................................... 49
IV. Annexes ............................................................................................................. 50
A. Procédure de synchronization d'OfbizNéogia avec Ofbiz ............................... 51
1. Objet ................................................................................................... 51
2. Pré-requis ............................................................................................ 51
3. Procédure ........................................................................................... 51
B. Création d'un projet client basé sur neogia ................................................... 55
1. Pré-requis ............................................................................................ 55
2. Préparation du serveur ........................................................................ 55
3. Configuration du référentiel ................................................................. 57
3.1. Activation des logs ................................................................... 57
3.2. Configuration des verrous CVS .................................................. 58
3.3. Configuration des fichiers binaires ............................................. 59
4. Import d'ofbizNéogia dans le référentiel CVS ........................................ 60
5. Procédure de sauvegarde et de restauration du référentiel ................... 61
5.1. Sauvegarde .............................................................................. 61
5.2. Restauration ............................................................................. 61
C. Procédure de mise à jour d'un projet client basé sur Néogia ......................... 62
1. Déterminer quelle est la dernière version STABLE d'ofbizNéogia ........... 62
2. Récupérer la dernière version STABLE d'ofbizNéogia ............................ 62
3. Importer de la nouvelle version d'ofbizNeogia dans le référentiel client . 62
4. Résolution des conflits dans la branche de développement ................... 63
D. Diagramme UML du MRP ............................................................................. 64
Bibliographie ........................................................................................................... 65
v
Liste des illustrations
2.1.
2.2.
2.3.
3.1.
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
5.1.
5.2.
5.3.
5.4.
6.1.
6.2.
6.3.
Architecture n-tiers d'Ofbiz ............................................................................... 15
Architecture J2EE d'Ofbiz .................................................................................. 15
Boucle d'évènements d'une application Ofbiz .................................................... 18
Schéma MDA utilisé par Néogia. ........................................................................ 21
Illustration du Branch by version ....................................................................... 26
Illustration du Branch by purpose ...................................................................... 26
Illustration de l'utilisation d'une branche stable ................................................. 26
Utilisation de la branche STABLE d'OfbizNéogia ................................................. 30
Utilisation de la branche EXPERIMENTAL d'OfbizNéogia ...................................... 30
Utilisation des branches dans un projet Client .................................................... 31
Exemple de fusion de branches ......................................................................... 32
Interfaces graphiques initiales du MRP .............................................................. 37
Nouvelle interface de lancement du MRP ........................................................... 38
Visualisation des résultats du MRP .................................................................... 39
Organisation des magasins de stockage dans OfbizNéogia ................................. 41
Processus de génération d'un document au format DocBook .............................. 45
Processus de génération mis en oeuvre ............................................................. 46
Feuille de style utilisée pour générer la documentation du projet ....................... 47
vi
Liste des exemples
6.1. Exemple minimaliste d'un document DocBook ................................................... 43
6.2. Exemple d'article DocBook ................................................................................ 44
6.3. Exemple d'informations relatives au document .................................................. 44
vii
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
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
Présentation
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
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
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
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 2001. 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
• 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
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
ControlServlet.
2.1. 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;
1
• suppporte un mécanisme de trigger appelé « EECA
n'implémente pas cette fonctionnalité.
» même si le SGBD sous-jacent
2.2. 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
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
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
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
1
un fichier XMI 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
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
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
Développements réalisés
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
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.
1.1. 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.
1.2. 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
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
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.
2.1. 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
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
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.
3.1. 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.
3.2. 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
3.
Intégration des composants Néogia dans ofbizNeogia.
3.3. 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
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
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
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
1
n'intègre pas la notion de listes de changement présentée précédemment . Pour retrouver
un niveau de fonctionnalités équivalent, nous allons utiliser un outil de gestion de projet
2
fournit par le site du réseau libre-entreprise hébergeant le référentiel CVS du projet Néogia .
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.
4.1. 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.
4.2. 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
Site du projet Néogia sur le Labs libre-entreprise [http://labs.libre-entreprise.org/projects/neogia]
2
33
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
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 :

. modification
. modification
. modification

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
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
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
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
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
Figure 5.3. Visualisation des résultats du MRP
40
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é.
2.1. 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
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.
2.2. 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
Chapitre
6
Mise
en
place
de
DocBook
documentation du projet Néogia
pour
la
1
Initialement, la documentation du projet Néogia se présentait sous la forme de fichiers rst .
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"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"›
‹book lang="fr"›
‹chapter›
‹title>Mon premier chapitre‹/title›
‹para›
Hello World !
‹/para›
‹/chapter›
‹/book›
1
ReStructuredText markup syntax [http://docutils.sourceforge.net/rst.html]
43
Mise en place de DocBook pour la
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
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
2
exemple, ce rapport a été rédigé en DocBook, puis transformé en xsl-fo à l'aide de la feuille
3
de style docbook-fo, avant d'être converti en pdf par Fop . 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
[http://www.w3.org/TR/xsl/])
3
Formatting Objects Processor [http://xmlgraphics.apache.org/fop/]
45
Mise en place de DocBook pour la
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
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">


<xsl:import href="file://@docbook.html.xsl@"/>
<xsl:param name="chunker.output.encoding">UTF-8</xsl:param>
<xsl:param name="section.autolabel">1</xsl:param>

<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
Bilan
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
Annexes
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 http://svn.ofbiz.org/svn/ofbiz/trunk
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 5740.
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
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.
peter@socrate:~/projets/import$ cd ofbiz
peter@socrate:~/projets/import/ofbiz$ export CVS_RSH=ssh
peter@socrate:~/projets/import/ofbiz$ export
CVSROOT=:ext:[email protected]:/cvsroot/neogia
peter@socrate:~/projets/import/ofbiz$ 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
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
Procédure de synchronization
d'OfbizNéogia avec Ofbiz
54
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 ... 99936 files and directories currently installed.)
Unpacking cvs (from .../cvs_1%3a1.12.9-9ubuntu0.1_i386.deb) ...
Setting up cvs (1.12.9-9ubuntu0.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 4096 2005-07-18 11:21 cvsroot
root@socrate:~ # ln -s /var/cvsroot /cvsroot
root@socrate:/ # ls -l / | grep cvsroot
lrwxrwxrwx
1 root root
12 2005-07-19 09: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
Création d'un projet client basé sur
neogia
drwxr-xr-x 2 root root 4096 2005-07-19 09:24 cvs
root@socrate:/ # chmod ugo+rw /var/lock/cvs
root@socrate:/ # ls -l /var/lock | grep cvs
drwxrwxrwx 2 root root 4096 2005-07-19 09: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 4096 2005-07-14 10:05 neogia
root@socrate:~ # chgrp neogiacvs /cvsroot/neogia
total 4
drwxr-xr-x 2 root neogiacvs 4096 2005-07-14 10:05 neogia
root@socrate:~ # chmod g+ws /cvsroot/neogia
total 4
drwxrwsr-x 2 root neogiacvs 4096 2005-07-14 10: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 4096 2005-07-18 11:40
root@socrate:~ # ls -l /cvsroot/neogia/CVSROOT
total 84
-r--r--r-- 1 root neogiacvs 495 2005-07-18 11:40
drwxrwsr-x 2 root neogiacvs 4096 2005-07-18 11:40
-rw-rw-r-- 1 root neogiacvs
0 2005-07-18 11:40
56
CVSROOT
checkoutlist
checkoutlist,v
commitinfo
commitinfo,v
config
config,v
cvswrappers
cvswrappers,v
Emptydir
history
loginfo
loginfo,v
modules
modules,v
-r--r--r--r--r--r--r--r--r--r--r--r--r--r--r--r--r--r--rw-rw-r--r--r--r--r--r--r--
1
1
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
neogiacvs
neogiacvs
neogiacvs
neogiacvs
neogiacvs
neogiacvs
neogiacvs
neogiacvs
neogiacvs
752
953
649
850
2096
2297
0
1357
1558
2005-07-18
2005-07-18
2005-07-18
2005-07-18
2005-07-18
2005-07-18
2005-07-18
2005-07-18
2005-07-18
11:40
11:40
11:40
11:40
11:40
11:40
11:40
11:40
11:40
notify
notify,v
rcsinfo
rcsinfo,v
taginfo
taginfo,v
val-tags
verifymsg
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 495 2005-07-10
-rw-r--r-- 1 peter peter 1108 2005-07-10
-rw-r--r-- 1 peter peter 1702 2005-07-10
drwxr-xr-x 2 peter peter 4096 2005-07-18
-rw-r--r-- 1 peter peter 909 2005-07-10
-rw-r--r-- 1 peter peter 1741 2005-07-10
-rw-r--r-- 1 peter peter 1151 2005-07-10
-rw-r--r-- 1 peter peter 752 2005-07-10
-rw-r--r-- 1 peter peter 649 2005-07-10
-rw-r--r-- 1 peter peter 2096 2005-07-10
-rw-r--r-- 1 peter peter 1357 2005-07-10
10:58
10:58
10:58
12:17
11:42
10:58
10:58
10:58
10:58
10:58
10:58
checkoutlist
commitinfo
config
CVS
cvswrappers
loginfo
modules
notify
rcsinfo
taginfo
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
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 1.1.2.1 and from 1.1.2.2
# to 1.1.2.3, respectively, %{sVv} will generate the following six arguments in this
# order: file1, 1.1, 1.1.2.1, file2, 1.1.2.2, 1.1.2.3.
#
# 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
#TopLevelAdmin=no
# Set `LogHistory' to àll' 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 àlways' (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 ÙserAdminOptions' 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 ÙseNewInfoFmtStrings' 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
peter@itux:~/projets/test/CVSROOT$ cvs commit -m "Setup lock dir location" config
/cvsroot/neogia/CVSROOT/config,v <-- config
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
-t
to cvs filter
value: path to filter
value: path to filter
59
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
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
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
CVSROOT=:ext:[email protected]:/cvsroot/neogia
peter@itux:~/projet/test$ cvs export -r NEOGIA_0_8_0 ofbizNeogia
...
peter@itux:~/projet/test$ 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.
peter@itux:~/projet/test/ofbizNeogia$ export CVS_RSH=ssh
peter@itux:~/projet/test/ofbizNeogia$ export CVSROOT=:ext:peter@socrate:/cvsroot/neogia
peter@itux:~/projet/test/ofbizNeogia$ 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é.
peter@itux:~/projet/test/ofbizNeogia$ cd ..
peter@itux:~/projet/test$ rm -rf ofbizNeogia
5. Procédure de sauvegarde et de restauration du
référentiel
5.1. Sauvegarde
root@socrate:~ # cd /var
root@socrate:/var # tar cjf ~/cvsroot.tar.bz2 cvsroot
5.2. Restauration
root@socrate:~ # cd
root@socrate:/var #
root@socrate:/var #
root@socrate:/var #
/var
mv cvsroot cvsroot.old
tar xzf ~/cvsroot.tar.bz2
rm -rf cvsroot.old
61
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 [http://lists.labs.libre-entreprise.org/pipermail/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
d'ofbizNéogia
la
dernière
version
STABLE
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:[email protected]:/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:[email protected]:/cvsroot/saitek
njerome@admin:~/Projets/MAJ_Neogia$ cd ofbizNeogia
njerome@admin:~/Projets/MAJ_Neogia/ofbizNeogia $ cvs import -ko
62
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
développement
conflits
dans
la
branche
de
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
Annexe
D
Diagramme UML du MRP
64
Bibliographie
[KF03] Open Source Development with CVS. Karl Fogel et Moshe Bar. July 2003.
1-932111-81-6.
[VV02]
CVS
Best
Practices.
http://www.tldp.org/REF/CVS-BestPractices/html/.
Vivek
[AG02]
Advanced
CVS
for
.LRN
Development.
http://openacs.org/projects/dotlrn/dotlrn-doc/dotlrn-cvs.
Venugopalan.
Andrew
Grumet.
[NW99] DocBook. The Definitive Guide. Norman Walsh. October 1999. 156592-580-7.
[BS05]
DocBook XSL. The Complete Guide. Bob
http://www.sagehill.net/docbookxsl/index.html.
Stayton.
February
[DP01]
Docbook
XSL
Stylesheets.
Styling
Questions.
http://www.dpawson.co.uk/docbook/styling/styling.html.
28,
Dave
2005.
Pawson.
[PG04] Rapport de Stage. Développement sur l'ERP libre Ofbiz. Peter Goron. Septembre 2004.
[PG05] Rapport de projet de fin d'étude. Développement d'un MRP à capacité finie pour l'ERP
libre OfbizNéogia. Peter Goron. Juin 2005.
[OZ01] The Open For Business Project. David E. Jones et Andy Zeneski. http://www.ofbiz.org/.
[NA04] The Neogia Project. Olivier Heintz et Yannick Thebault. http://www.neogia.org/.
65

Rapport de stage - Libre

Transcription

Documents pareils

Etape Infos n°45 Février 2013

Télécharger le sommaire du n°13 de Transfuge

Caisse primaire d`assurance maladie des landes, siège de

du Conseil de la Vie Sociale du 12 mars 2015

LR248 Boulevard Bir Anzarane, Casablanca, Maroc 8 000 Dhs par

Le Quotidien de l`AHA

Présentation de CVS - Guillaume Lehmann

LR123 Meublé - Piscine AIN DIAB, Casablanca 20052, Maroc 9 000

Cedega – jeux Windows sous Linux

document