jacinthe - indico.math.cnrs.fr€¦ · note initiale, extraits (13/12/2010) • pour assurer la...

Jacinthe

Histoire d’un projet logiciel à épisodes pour la SMF

Michel Demazure

Mathrice, 9 avril 2013

Les épisodes

• 2010 : le point de départ

• 2011 : Jacinthe

• 2012 : J2R

• 2013 : JacMan

• 2014 : la suite

• Moralité : les douze facteurs


Le cadre

• La

– association (1872) reconnue d’utilité publique – trois fonctions

• société savante (2000 membres, individuels et institutions) • éditeur et distributeur (n° 1 mathématique en France,

revues papier et électroniques, monographies) • centre de colloques (CIRM, Marseille-Luminy)

– une petite entreprise à clientèle mondiale • hors CIRM (qui a une gestion spécifique) • six salariés, deux localisations (Paris, Marseille) • CA annuel : 500 K€


Environnement en 2010

• Matériel – postes de travail individuels Macintosh

• Applications – une base de données 4D sur un poste (S.G.) – des logiciels de gestion SAGE

• venant de OS9 • comptabilité, amortissements, paye • gestion commerciale (GESCOM) sur deux postes (Paris et

Marseille), communiquant par transmission de fichiers

• Web – serveurs sous drupal (public, membres, ventes) – Mathrice


Environnement en 2010


Situation en 2010

• Difficultés majeures – pour assurer la cohérence des informations

– pour faire face aux réclamations de plus en plus nombreuses des clients

• Points noirs : – base 4D patchée à l’extrême, défaillante

– SAGE pas en réseau entre les deux sites

– applications « privées » non communicantes

– nomenclatures concurrentes

– « synchronisation » (sic) par courriel


Une complexité objective

• Exemple : une institution 1. chinoise, membre de la société, 2. qui achète via un distributeur hollandais, 3. qui paye par une banque à Singapour, 4. demande l’envoi des factures à une adresse et l’envoi des

ouvrages à une autre adresse, 5. … et si ça se trouve, on l’a en double dans 4D !

• Analyse : la dualité tiers / clients – plusieurs « tiers » (nom, adresse, …) : membre, payeur,

correspondant… – plusieurs « clients » : plusieurs clients du système comptable, de

la gestion commerciale, plusieurs régimes douaniers…


Note initiale, extraits (13/12/2010)

• Pour assurer la réussite de l’opération, il faut donc – ne pas charger la barque avec des fonctionnalités qui pourront être

ajoutées dans une deuxième phase ; – ne pas modifier l’ergonomie et les pratiques actuelles au-delà de ce qui

est nécessaire, et en particulier, conserver l’environnement Macintosh (au prix d’une complexité supplémentaire de développement des interfaces avec le composant SAGE) ;

– créer un mécanisme de pilotage efficace.

• Dans l’esprit de ce qui précède, les trois objectifs techniques essentiels sont – unifier les opérations comptables et financières sous SAGE (version

Mac) ; – créer sous MySql la base des tiers (qui remplacera la base actuelle sous

4D) ; – créer (OpenOffice) ou adapter (Drupal) les interfaces nécessaires pour

les utilisateurs.


Décisions (début 2011)

• Refonte totale – démarche projet, comité de pilotage, chef de projet (« Kenji ») – objectif de basculement au 1/1/2012

• Principes – tout en réseau, tout accessible à tous (y compris Sage Gescom) – conserver l’environnement Macintosh – conserver Sage (donc Sage sur Mac : pas SQL, pas automatisable) – outils Open source (sauf Sage)

• Structure générale retenue – une base de données unique articulant « tiers » et « clients » – alimentant Sage en « clients » et alimentée par Sage en événements

commerciaux – accédée via des formulaires OpenOffice


Les épisodes


• 2011 : Jacinthe

• 2012 : J2R

• 2013 : JacMan

• 2014 : la suite



Vers Jacinthe

• Pourquoi ce nom ? – face à GesCom (SAGE « gestion commerciale ») – d’abord GesInt (« gestion interne »), puis Jacinthe

• 2 + 2 composantes sur un serveur interne OSX : – JacintheD : base de données MySQL – JacintheO : formulaires OpenOffice pour « parler à JacintheD » – Sage (GesCom) en réseau, communiquant avec Jacinthe par échanges

de fichiers – des scripts de management et de communication (SQL, bash,…)

• communication avec serveurs externes – ‘smf-2’ (proxy) – ‘smf’ (public, membres) – ‘smf-4’ (publications) – …


Base de données (principe)


Base de données (détails)


Jacinthe 2012


Le basculement (1er janv. 2012)

• Énorme chantier (6/2011 – 3/2012): – normalisation de la nomenclature des produits, unification des

nomenclatures, unification des fichiers Sage entre Paris et Marseille, basculement comptable au 1/1/2012

– extinction de 4D au 1/1/2012, basculement de 6000 fiches

• Fin du développement (1/2012 – 3/2012) – articulation des diverses composantes, mise au point des

nouvelles procédures – « améliorations » rendues possibles par le nouveau système

• Apparition de manques – commodités disparues avec 4D, – SQL nécessaire pour les recherches complexes – pas d’outils de reporting au-delà des formulaires OO


Les épisodes


• 2011 : Jacinthe

• 2012 : J2R

• 2013 : JacMan

• 2014 : la suite



Une troisième composante

• Pour répondre aux manques – suite à une boutade en comité de pilotage (12/1/12) – premier commit (git@bitbucket) le 16/1/12, mise en

service v1 le 31/3/12 – en exploitation journalière depuis (v2 le 1/9/12)

• développée sous Windows en ruby + sequel + Qt – ruby : 26 modules, 56 classes, 553 méthodes – sequel : « reverse engineering » de la base – Qt : portabilité OSX / Windows / X (Gnome, etc.)

• JacintheReports (J2R) – deux GUI : rapporteur, auditeur – rapporteur batch, tableau de bord


« Reverse engineering »

• GUI (ou web service) – modèle (ORM) base de données avec sa structure – interface avec l’utilisateur (GUI ou vue/contrôleur) – jeu entre interface /modèle / contenu de la BD

• Initialisation, cas normal (cf. Rails, Sinatra, Groovy, …) – initialisation : config modèle – migration/update : nouvelle config

• Initialisation « inverse », cas de J2R – structure de la base JacintheD préexistante – extraction : structure de la base (SQL) config – config « compilée » et stockée (tables YAML) – migration/update : nouvelle structure nouvelle compilation


Le cas « normal »


Le cas « inverse »


Tables YAML


Le rapporteur


L’auditeur


Rapport d’audit (fragment)


Les épisodes


• 2011 : Jacinthe

• 2012 : J2R

• 2013 : JacMan

• 2014 : la suite



Jacinthe 2012


Une quatrième composante

• Pourquoi, comment ? – Juin 2013 : « Kenji », qui a développé Jacinthe, n’est plus

disponible, je reste seul face à un paquet de scripts – pour comprendre, je réécris tous les scripts en ruby – j’ajoute ceux qui restaient à créer – je bâtis un GUI pour rassembler les commandes – j’en profite pour ajouter au GUI la surveillance des

opérations lancées chaque nuit et des alertes pour diverses anomalies

– je me rends alors compte qu’une grande partie du dialogue entre Sage et Jacinthe peut être automatisée

– on arrive alors à JacintheManager, alias JacMan


JacMan

• développement (6/2013 – 10/2013) – sql + ruby + Qt

• premier commit le 28/6/13, v1 mise en service le 22/9/13, v2 avec automatisation mise en service le 14/10/13

– deux systèmes, trois encodages • Windows : iso-8859-2 + fins de lignes en CR/LF • Mac(OS9) : macroman + fins de ligne en CR • OSX, *ix : unicode + fins de ligne en LF

– trois exécutables batch : batman, jacdev, cronman – deux GUI : manageur, manageur du catalogue.

– portant l’automatisation (plusieurs raisons, dont une mauvaise)


batman

$ batman

Liste des commandes disponibles :

<vide> ou <erreur> : cette réponse

help : cette réponse

help <commande> : aide sur <commande>

gi : Importer dans Jacinthe les nouvelles ventes à partir d'un fichier reçu d'Aspaway

ge : Extraire de JacintheD la liste des nouveaux clients et l'envoyer

gr : Envoyer à nouveau les fichiers clients construits précédemment et non reçus

di : Importer dans Jacinthe les données contenues dans le serveur smf

de : Transférer les données depuis JacintheD vers le serveur smf

ca : Importer dans Jacinthe la liste des articles fournie par Gescom

cn : Importer dans Jacinthe la nomenclature fournie par Gescom

cs : Importer dans Jacinthe l'état des stocks fourni par Gescom

ce : Récupérer dans un fichier les éléments du catalogue extraits de Jacinthe

ep : Envoyer au serveur smf4 les plages IP valides

ea : Envoyer au serveur smf4 les abonnements électroniques

en : Notifier par courriel aux tiers concernés leurs abonnements électroniques

ei : Ouvrir dans un éditeur la liste des plages invalides

tb : Construire le tableau de bord du jour et l'envoyer aux destinataires fixés

info : Opérations pendantes

conf : Configuration du manageur


Le manageur (GUI)


Nouvel épisode (10-11/2013)

• Sage est externalisé – les logiciels Sage tournaient sur le serveur OSX – Sage annonce l’abandon prochain des versions Macintosh et le

basculement obligatoire vers Windows • on avait choisi initialement de conserver les versions Mac, bien qu’on

aie prévu cette issue

– on décide d’en profiter pour externaliser sur une infrastructure distante (Aspaway), en conservant nos licences

– le basculement est programmé (et effectué) le 2/12/13

• JacMan a donc affaire à un serveur externe de plus – on communique toujours par transmission de fichiers – pas de nouveau problème de conversion ! – problèmes de réseau, de sécurité et de synchronisation (!)


Jacinthe 10/2013


Jacinthe 12/2013


Les épisodes


• 2011 : Jacinthe

• 2012 : J2R

• 2013 : JacMan

• 2014 : la suite



Le pas suivant

• Il reste dans tout cela une fragilité majeure – tout est maintenant si bien intégré que la vie de la SMF est

suspendue au fonctionnement d’une machine unique, le serveur OSX, sur lequel tourne Jacinthe(D + O + R + M).

• d’où le défi actuel – se mettre en mesure de porter sans préavis Jacinthe sur

une machine arbitraire, soit en cas de panne, soit pour continuer la démarche d’externalisation.

• ce qui veut dire : – virtualiser l’ensemble (système d’exploitation, serveur SQL,

OpenOffice, ruby, gems, Jacinthe, J2R, JacMan…) – pour fixer un objectif concret : créer une machine Vagrant

entièrement configurée, mobilisable à tout moment


Du pain sur la planche

• Test de faisabilité positif – construction pilotée par Packer

– une machine Vagrant de base • Centos 6.5, MySQL 5.5, OpenOffice 4.0.1, Ruby 2.1

– sur laquelle tout fonctionne (après installation)

• mais mettant à jour l’hétérogénéité de l’architecture

• Vers un design « moderne » – services autonomes (JacintheD, JacintheO, J2R, JacMan,

Sage, serveurs publics), déployés indépendamment

– sécurité par certificats

– interfaces par « webUI »


Les épisodes


• 2011 : Jacinthe

• 2012 : J2R

• 2013 : JacMan

• 2014 : la suite



Le debriefing

• Les contraintes sous lesquelles j’ai travaillé… – développer chez moi sous Windows des GUI devant tourner

identiquement sous OSX (et portables sur Linux/Gnome) – dialoguant avec une base SQL indépendante – en ayant affaire simultanément à trois formats de fichiers – et en n’intervenant sur le serveur d’exploitation que par

push/pull (sous git, qui en plus fait des conversions de fins de ligne !)

• … m’ont conduit spontanément à appliquer quelques-uns des principes de « 12factor », dont les deux premiers : – One codebase tracked in revision control, many deploys – Explicitly declare and isolate dependencies

• … ce qui a rendu aisées l’externalisation et le portage


« The Twelve-Factor App »

– Nouveau paradigme

• issu de la pratique « nuage » (notamment en PaaS)

• explicité sur http://12factor.net/

– douze principes

– auteur : Adam Wiggins (CTO de Heroku)

– contributions : James Lindenbaum, Mark McGranaghan, Chris Stolt, Ryan Daigle, Mark Imbriaco, Keith Rarick, Will Leinweber, Jesper Jørgensen, James Ward, Adam Seligman, Phil Hagelberg, Jon Mountjoy, Matthew Turland, Daniel Jomphe, Mattt Thompson, Anand Narasimhan, Lucas Fais, Pete Hodgson


http://12factor.net/

« 12 factor app » (1-4)

• √ Codebase – One codebase tracked in revision control, many

deploys

• √ Dependencies – Explicitly declare and isolate dependencies

• ± Config – Store config in the environment

• ± Backing Services – Treat backing services as attached resources

• “The code for a twelve-factor app makes no distinction between local and third party services”


« 12 factor app » (5-8)

• √ Build, release, run – Strictly separate build and run stages

• ± Processes – Execute the app as one or more stateless

processes

• ! Port binding – Export services via port binding

• ? Concurrency – Scale out via the process model


« 12 factor app » (9-12)

• ? Disposability – Maximize robustness with fast startup and graceful

shutdown

• √ Dev/prod parity – Keep development, staging, and production as similar

as possible

• !!! Logs – Treat logs as event streams

• ? Admin processes – Run admin/management tasks as one-off processes


Ressources

• Virtualisation – Packer (Mitchell Hachimoto) : http://www.packer.io/ – Vagrant (Mitchell Hachimoto) :http://www.vagrantup.com/ – modèles Packer (Opscode) : https://github.com/opscode/bento

• Adam Wiggins et al – Twelve Factor : http://12factor.net/

• Chad Fowler (Keynote talk at Garden City Ruby 2014) : http://www.confreaks.com/videos/2908-gardencityruby-keynote – « jeter les clés » – bind by contract – « homéostasie » :

• « chaos monkey » : https://github.com/Netflix/SimianArmy • Amazon Elastic Compute Cloud : « spot bidding » :

http://aws.amazon.com/fr/ec2/purchasing-options/spot-instances/


http://www.packer.io/

http://www.vagrantup.com/

https://github.com/opscode/bento

http://12factor.net/

http://www.confreaks.com/videos/2908-gardencityruby-keynote





https://github.com/Netflix/SimianArmy






En guise de conclusion

En une phrase :

dorénavant, on développe

dans un environnement

mais pas pour un environnement


En guise de conclusion

En une phrase :

dorénavant, on développe

dans un environnement

mais pas pour un environnement

Et, comme dit la SNCF lorsque le train est en retard :

– « Je vous remercie de votre compréhension »


jacinthe - indico.math.cnrs.fr€¦ · note initiale, extraits (13/12/2010) • pour assurer la...

Documents