Bonsoir tout le monde,
@séverin :
en fait c'est en partie ce que je fais.
Sur mon poste de travail j'ai un clone du dépôt moodle officiel dans lequel je fais les intégrations souhaitées sur des branches indépendantes. Ces intégrations se limitent généralement à une simple mise à jour.
Je pousse ensuite ces modifications dans la branche master des dépôts en production paramétrés spécialement pour accepter les requêtes dans ce sens.
La structure que j'ai décrite précédemment est intéressante dans la mesure où il est possible de mutualiser un maximum de ressources pour plusieurs sites moodle hébergés sur le même serveur.
J'ai par exemple 3 sites tournant sur le même tronc moodle 2.3.1.
La mise à jour se fait par un simple git push vers ce dépôt.
J'ai en projet de finir l'upgrade en ligne de commande de manière automatisée pour ne pas avoir à cliquer sur "notifications" dans la partie admin de chaque site.
M'enfin tout n'est pas parfait pour le moment...
@valery :
Pour la partie développement et sa problématique de synchronicité entre les états d'un commit GIT particulier, la base de données et les fichiers de données, je n'ai pour le moment pas trouvé de piste pour ces derniers, compte tenu des volumes à appréhender.
Concernant la partie synchronisation entre GIT et la base de données, je m'intéresse, malheureusement que trop rarement, à liquibase http://www.liquibase.org/ qui semble bien gérer les retours en arrière.
Car finalement le noeud du problème est là : comment revenir à un état antérieur stable et cohérent ?
@+
Eric