La démarche est logique et en effet peut bien outiller une gestion de multiples instances. Reste en effet ce problème important des plugins hors tronc.
Les choses qui me gêneraient dans ma pratique avec ce dispositif :
Tisser beaucoup de liens entre de nombreux repositories suppose en suite avoir une parfaite gestion de tous les cas d'intégration. Lorsque des modifications impliquent des changements d'usage importants, il n'est pas toujours possible de mettre à jour de manière uniforme le parc des instances de production (ce cas m'est arrivé souvent), soit parce que l'évolution fonctionnelle n'est pas demandée, soit parce qu'elle ne peut être faite qu'avec un temps important de reprise de contenus existants, soit pour plein d'autre raisons.
Il y aura toujours une différence importante de point de vue des outils entre des intégrateurs "internes" d'une institution, et une position de prestataires : Les deuxièmes ont malheureusement une contrainte assez drastique de budget, doivent être compétitifs et doivent parfois négocier des enveloppes qui limitent les possibilités de construction d'outillage "sur mesure". C'est un autre débat, mais il influe aussi sur le choix de la strcuture des outils et techniques utilisées pour gérer les Moodle.
Aujourdhui, la difficulté MAJEURE que je trouve dans la gestion sous GIT de la chaine aval (chaine aval : des instances de référence vers les copies de production, chaine amont : des versions de développement ou d'intégration vers la version de référence), c'est la difficulté de gérer des modifications tranversales. Soit le cas suivant :
Deux plugins évoluent "normalement" dans leur cycle de vie, en accumulant les améliorations. Une amélioration des pratiques d'architecture faite par ailleurs nécesite la reprise de ces deux plugins pour y intercaler ces améliorations de structure. Les deux opérations s'entrecroisent. à moins de commiter modif par modif, et de tenir une "comptabilité" permanente et ultra pointilleuse de ce qui a été commité ça et là, il est impossible ou très difficile sous Git, de "faire son marché" dans la partie qui va être passée en production (par exemple, passer les évolutions fonctionnelles, mais sans basculer les améliorations transversales.
En gros, et à moins que je me trompe lourdement, Git fait évoluer TOUT le repository d'un commit stable à un autre commit stable, en rejouant toutes les modifs successives faites dans les fichiers du repo. Retrouver là dedans une mise à jour partielle d'un sous-ensemble particuliers de fichiers est quasiment impossible.
C'est là que je m'interroge sur la pertinence de Git pour gérer la chaine aval. Car ce qui compte pragmatiquement, c'est bien l'état immédiat de la base de code qui est présentée en face des utilisateurs. Toute l'histoire qui y a mené et qui intéresse fortement les développeurs, l'exploitant, lui s'en fiche comme de l'an quarante, puisque ce qui importe surtout, c'est de présenter la "meilleure" version du code aux utilisateurs finaux.
Autant je découvre un intérêt effectif de Git dans la chaine amont, avec une très grande souplesse et rapidité de gestion des variantes de développement, autant je n'arrive pas à comprendre sa popularité dans cet usage.
Dans la construction proposée, j'ai l'impression que l'on rejoue le "déplacement du tas de sable", en référence à une époque révolue de la présence militaire française à Berlin, où une activité majeure des conscrits berlinois (souvent envoyés là-bas pour raisons disciplinaires) déplaçaient un tas de sable d'un coin de la caserne à l'autre, puis encore à l'autre, et recommençaient quand ils avaient fait le tour.
Il en va des techniques logicielles, des encodages, des normes et technologies comme du tas de sable : l'innovation prétend toujours trouver la solution miracle alors qu'elle ne fait que déplacer la complexité ailleurs. Elle déplace le tas de sable. en changeant de paradigme par rapport à des techniques antérieures comme CVS ou SVN, Git apporte des nouveaux outils, des nouvelles pratiques, et en élimine ou interdit des anciennes qui étaient tout aussi opérables et efficientes. Il déplace le tas de sable.
La question essentielle n'est plus l'outil, mais bien la pratique de gestion qui supprime la vue et l'attention sur l"objet final (puisque tout se commande à partir des points de départ, et plus de l'arrivée). J'avais concocté un outillage redoutable de multicopie scriptée de plugins à travers toutes les copies de code, avec une configuration ultra-souple des sources et des destinations. Je ne l'utilise preque plus du tout : Je passais mon temps à gérer les exceptions, ou les erreurs de manoeuvre que les configurations "implicites" et sorties de ma mémoire me faisaient faire. Bref, je déplaçais le tas de sable.
....
