Gestion de l'historisation via Git

[bchartier]

Au cours de la dernière réunion du comité de pilotage de mviewer, la question de l'usage de Git pour gérer le versionnement des applications produites avec mviewerstudio a été débattue. @Gaetanbrl m'a demandé de formaliser mes craintes et celles de DataGrandEst concernant ce choix architectural. L'idée de cette discussion est de présenter ces craintes, de laisser chacun y réagir et peut-être d'en tirer des leçons pour d'autres évolutions à venir. L'idée n'est pas de remettre en cause ce choix puisqu'il n'est pas question de revenir en arrière pour ceux qui ont travaillé sur cette évolution.

1. La méthode

Cette évolution touche à l'architecture de la solution et a des impacts sur son déploiement.
Les impacts ont peut-être été étudiés avant que l'évolution soit réalisée mais quand il s'agit d'architecture il me semble préférable d'élargir le cercle de réflexion pour réduite encore plus les risques de découverte de problèmes après coup.
Je sais bien que la réflexion paralyse l'action et que plus on discute moins on fait.
Néanmoins, le fait d'être mis devant le fait accompli me gène en termes de méthode.

2. La simplicité

La marque de fabrique de mviewer et mviewerstudio c'est sa simplicité : déploiement on ne peut plus simple.
Ajouter de la complexité peut avoir des conséquences négatives pour les utilisateurs actuels :

• voir des utilisateurs s'éloigner de la solution si la marche technique est trop haute
• compliquer les tâches de déploiement (surtout pour des acteurs comme DataGrandEst et Géo2France qui doivent passer par des prestataires pour déployer des outils se basant sur des composants logiciels spécifiques comme Python et Git).

Deux remarques complémentaires :

• même si j'ai dit que le but de cette discussion n'est pas de remettre en cause le choix de Git, je suis quand-même curieux de comprendre ce qu'apporte Git, dans ce cas de figure, par rapport une simple historisation par sauvegarde des étapes précédentes sous la forme de fichiers ou répertoires avec des noms différents (incluant la date ou un numéro de version par exemple).
• j'ai bien conscience que le versionnement avec Git sera optionnel. C'est du coup moins embêtant.

[gryckelynck]

Merci Benjamin pour cette formalisation fidèle aux craintes que nous pouvons formuler du point de vue d'une plateforme régionale.
A noter sur la méthode que si les choix ne sont pas partagés et discutés assez en amont, on a tendance à encourager l'éparpillement de nos forces et c'est ce qui est le plus dommageable. Par ailleurs, si la marche technique que tu indiques est trop haute, certains acteurs risquent de se détourner en disant: "c'est trop complexe pour ce que je veux faire, je vais développer une visionneuse plus simple et adaptée à mon besoin...".

[pierrejego]

Bonjour à tous,
Merci pour vos retours, cette discussion porte sur l'issue #158 de mviewerstudio. Ouverte depuis un mois et que nous commençons a développer.

Il n'y a aucune complexité rajouté dans le viewer Mviewer, uniquement dans la partie MviewerStudio.

Nous parlons ici juste de rajouter dans le backend python déjà existant, une fonctionnalité permettant d'historiser les configurations ( fichier xml) mviewer dans des répertoires. Si je ne me trompe pas la partie PHP reste accessible mais sans cette évolution.

Dans le backend existant actuellement, une multitude de fichiers étaient générés, avec des noms généré automatique et non lisible.

• Pour l'utilisateur lambda, aucune complication technique, juste l'ajout de la possibilité de revenir sur une version précédente ou de voir une version précédente et la version actuelle en même temps.

Il y a aussi la publication discutée dans ces issues : #181 #161 je vous invite à y partager vos avis.

• Pour l'administration/installation, par rapport au backend python existant, il faut juste installer sur la machine un package git ( très souvent déjà présent sur l'os), on ne parle pas ici de choses compliqués, pas de github, gitlab ou de commandes git à passer sur les serveurs, juste l'installation d'un package. Et pour les installations docker c'est transparent une fois le container à jour.

Par contre oui, par rapport à ce backend python ( dont nous n'avions pas connaissance au lancement des développements ) https://github.com/neogeo-technologies/idgo-mviewerstudio-proxy/commits/master/mviewerstudio_cas il risque d'y avoir des adaptations à faire.

[Gaetanbrl]

A noter que le package est GitPython, c'est juste un package python géré par le code Python du backend et qui ne nécessite pas de compte utilisateur (attention : ne pas confondre Git et GitHub).

• 1 carte = 1 répertoire.
• 1 répertoire = un repo git local.
• 1 repo = bénéfice de git pour lister les modifications, changer d'un endroit à un autre dans les modifications, revenir (reset) à un état sans rien ajouter de plus.

Git nous a semblé être un choix intelligent car c'est un outil de versionnement et qu'il permet de répondre au besoin pour un coût minimal sans réinventer un mécanisme (+ problématique) de gestion de BDD.

Donc simplement, si vous avez déjà Python, ca ne sera pas une marche technique en plus, vous aurez même une gestion plus propre des fichiers avec un seul fichier par carte.

Si vous avez PHP, vous pouvez conserver PHP, le studio fonctionnera alors pour l'utilisateur de la même façon que la version 3.2.

Nous n'avons en effet pas prévu de développer 2 backend en parallèle, ce choix me semblant assez évident pour des problématiques de coût et simplification de la maintenance.

[spelhate]

Bonjour à tous et merci @bchartier pour l'ouverture de cette discussion.
En réponse à @gryckelynck , l'évolution git + python concerne uniquement mviewerstudio et pas mviewer.
Concernant le backend, il faut savoir qu'aujourd'hui il y en a deux différents et qui font la même chose :

• Le Php historique
• le python initié par C2C dans le cadre d'une prestation pour la Haute Loire

Il ne me semble pas raisonnable ni tenable de maintenir 2 backend en parallèle dans mviewerstudio; ce qui pose par ailleurs la question du choix du backend.

Concernant l'usage de git et pour rester cohérent avec l'esprit mviewer, je préconise de rendre cette option paramétrable via la config.
On pourrait ainsi imaginer dans la configuration de studio un paramètre mode_sauvegarde="filesystem" ou mode_sauvegarde="git"

[Gaetanbrl]

Oui c'est un système qui pourra être mis en place par la suite.

Dans nos travaux du moment il est prévu :

1. Améliorer le backend Python
2. Garder PHP fonctionnel comme en v3.2 (fonctionnalités iso)

Donc ceux qui ne souhaitent pas installer Python peuvent rester avec PHP. Seule la configuration sera à renseigner (effort minimal) mais ils ne disposeront pas des nouveautés fonctionnelles.

Ceux qui ont déjà Python, ils pourront disposer des nouveautés en récupérant simplement les sources de la futur version, puis réinstaller les dépendances et compléter la configuration.

Ceux qui utilisent Docker pourront disposer de l'image qui sera disponible dans l'action GitHub mviewerstudio (à prévoir à terme) et configurer les volumes (ou config).

Donc en l'état, le gap technique est mineur et si les environnement sont restés ISO avec mviewerstudio il n'y aura pas de problème.

Les seuls soucis se posera cependant pour ceux qui peuvent avoir un front ou backend personnalisé qui n'est pas celui du dépôt principal mviewerstudio. Ce problème se pose pour mviewer et toutes les solutions open source existantes et a été largement déconseillé (non pas interdit) dans la documentation mviewer par exemple.
Dans ce cas, il faudra prévoir des évolutions pour intégrer les potentiels environnements techniques qui ont pu diverger du code source principal.

[bchartier]

Concernant l'usage de git et pour rester cohérent avec l'esprit mviewer, je préconise de rendre cette option paramétrable via la config.
On pourrait ainsi imaginer dans la configuration de studio un paramètre mode_sauvegarde="filesystem" ou mode_sauvegarde="git"

+1
(si ce n'est que mode_sauvegarde devrait peut-être être anglicisé)

[Gaetanbrl]

Néanmoins, le fait d'être mis devant le fait accompli me gène en termes de méthode.

@bchartier une Pull Request sera réalisée dans les règles. Ce sera à la communauté de l'accepter ou non selon le process habituel. Des évolutions par la communauté pourront ensuite être proposées si 100% du besoin de 100% des plateforme n'est pas satisfait.

Notre méthode respecte 100% des process de la communauté mviewer / mviewerstudio. Vu le timing, il n'était pas possible de proposer une réflexion plus tôt sur ces issues.

Les travaux sont suivi de près par Megalis (@spelhate) et GéoBretagne (@lecault @spelhate). Je reste donc certain que ce qui sortira de ce groupe de travail est complètement cohérent avec la philosophie des outils et de la communauté.

Nous gardons aussi bien en tête les méthodes de maintenance des prestataires dans nos choix car nous avons bien connaissance de ce que représente la maintenance d'une infrastructure complexe. Mais les environnements / plateformes doivent également tenir compte dans leurs choix que l'outil peut évoluer dans le temps et que des évolutions se présenterons naturellement.

Face à la demande croissante des besoins et des demandes de fonctionnalités, il me semble alors assez cohérent d'avoir un minimum de complexification dans la structure du code (la liste des briques techniques restants toujours simple -> le package python GitPython seulement en plus).

[Gaetanbrl]

@vfabry @gryckelynck

Est-ce que ce serait possible d'avoir des informations sur votre infra :

• Version mviewerstudio
• Version mviewer
• Type de déploiement / installation
• méthode de mise à jour de mviewerstudio
• code custom ?

Ca me permettra de voir plus clair et identifier de potentiels problèmes.

Je sais que pour IDEO BFC - @bchartier @jerbou vous me corrigez si je me trompe :) :

• mviewer 3.4 (de mémoire)
• studio < 3.x
• backend mviewerstudio custom (geofit) avec Infos d'authent CAS + basic authent + stockage BDD Redis => Non présent dans dépôt principal mviewerstudio
• mviewer avec une partie custom pour la sécurisation des données => Non présent dans dépôt principal mviewer

Pour IDEO il faudrait donc dans une évol futur :

• Prévoir de rajouter dans le backend la récupération des infos CAS en reprenant / s'inspirant le travail de geofit
• Prévoir un regroupement par organisation en s'inspirant du travail de geofit

Par contre ce sera plus complexe (déconseillé et non standard) de garder du code spécifique comme je le vois pour le CRIGE :

https://github.com/neogeo-technologies/idgo-mviewerstudio-proxy/blob/1cd92e6dc81854fb1698cf246cb5331686805a9b/mviewerstudio_cas/mviewerstudio_cas.py#L75-L78

Mais tel que je le vois, sauf incompatibilité type Python2 / Python3, je ne vois pas de problèmes de gap technique. Les principaux éléments problématiques sont le code spécifique avec des cas d'usages propres.

[Gaetanbrl]

Tant que c'est du optionnel

Ca ne sera plus vraiment optionnel pour la partie Python. C'est optionnel dans le sens où on choisit Python ou PHP ou bien on reste en version inférieure.

Les travaux sont testables ici (attention c'est la pf de démo + tests !!):

https://gis.jdev.fr/mviewerstudio/index.html#

[Gaetanbrl]

Pour la question :

Je ne me rend pas compte de l'effet "carré" des possibilités avec l'historisation

A quel effet "carré" tu fais référence ?

[bchartier]

Les travaux sont testables ici (attention c'est la pf de démo + tests !!):
https://gis.jdev.fr/mviewerstudio/index.html#

Merci pour le lien de partage !

[bchartier]

Tant que c'est du optionnel

Ca ne sera plus vraiment optionnel pour la partie Python. C'est optionnel dans le sens où on choisit Python ou PHP ou bien on reste en version inférieure.

Juste pour être sûr, j'essaie de reformuler :

• avec backend Python : on a forcément la gestion de l'historique avec Git
• avec backend PHP : on n'a pas la gestion de l'historique (et on n'aura pas forcément d'autres fonctions qui pourraient apparaître à l'avenir)

?

[Gaetanbrl]

@bchartier
#183 (reply in thread)

[spelhate]

Nous parlons ici juste de rajouter dans le backend python déjà existant, une fonctionnalité permettant d'historiser les configurations ( fichier xml) mviewer dans des répertoires. Si je ne me trompe pas la partie PHP reste accessible mais sans cette évolution.

Ce qu'il faut également comprendre, c'est qu'il ne s'agit pas seulement d'historiser / versionner les fichiers de configuration xml, mais également toutes les ressources mobilisées par une application mviewer (exemple template mustache pour les fiches d'information...)
Globalement, il s'agit ici d'historiser un répertoire avec des fichiers et des sous-dossiers. A ce titre, le recours à Git ne me semble pas être une hérésie.
D'ailleurs côté Région Bretagne, bien avant cette demande d'évolution, les applications mviewer étaient versionnées dans github : https://github.com/region-bretagne/mviewer-apps

[Gaetanbrl]

Ce qu'il faut également comprendre, c'est qu'il ne s'agit pas seulement d'historiser / versionner les fichiers de configuration xml, mais également toutes les ressources mobilisées par une application mviewer

Nos retours ne faisaient en effet pas référence aux besoins d'historisation des autres ressources qui sont pourtant concernées.
Une BDD ou un simple suivi avec des dates pour chaque fichier serait rapidement bien plus complexe à maintenir par typologie de fichier qu'une simple indexation générale des modifications via Git créé pour cet usage (+ simple pour indexer / revenir à un état d'un répertoire).

D'ailleurs côté Région Bretagne, bien avant cette demande d'évolution, les applications mviewer étaient versionnées dans github

C'est en effet une pratique ce que nous encourageons via GitHub / Git auprès nos clients. Cela facilite les migrations, ca évite de perdre le travail et puis ca facilite tout simplement le suivi des modifications et l'intervention d'un aidant (e.g un prestataire appelé à l'aide ponctuellement quand on fait une modif que plus rien ne fonctionne, mais que ca fonctionnait avant).

[bchartier]

Globalement, il s'agit ici d'historiser un répertoire avec des fichiers et des sous-dossiers. A ce titre, le recours à Git ne me semble pas être une hérésie.

Merci d'avoir préciser cela car ce n'était pas limpide.