Solution d'un éditeur professionnel propriétaire

Je présente la méthode mise en place dans ma boîte, un éditeur de logiciel de gestion de centrale d'achat et gestion de stock. La base est assez énorme avec quelques 900 tables dans la version actuelle.

Chaque développeur travaille avec son propre jeu de sources mais la base de données est commune à tous les développeurs. Ceci semblerait presque indispensable étant donné le nombre de tables. Cette méthode n'est possible que parce que tous les développeurs sont dans les mêmes locaux. Il est donc impossible de faire du développement le WE à la maison.

On comprend que cette méthode est une solution simple, à la limite du contournement... Bref, c'était histoire de dire que le problème était contournable. Dans le cas d'un logiciel libre développé par des personnes travaillant à distance, cela est hors de propos.

Solution actuelle de PhpWebGallery

PhpWebGallery est confronté au problème et la solution actuelle est moisie. En effet, si un développeur rajoute une colonne, il met à jour le script de création de la base mais il n'y a pas de script de mise à jour d'une base existante dans le gestionnaire de configuration. Les quelques fois où le cas est rencontré, le problème se règle sur le forum des développeurs :-/

Bref, c'est ce qu'il ne faut pas faire. Cela marchait très bien quand je développais seul, mais il faut mettre en place une solution prochainement.

Solution d'export/import

Première solution vraiment élégante, mais pas applicable pour tous les logiciels.

Citons par exemple Subversion, le logiciel de gestion de version utilisé pour PhpWebGallery (depuis peu). Le principe est qu'avant de passer à une nouvelle version, on exporte le référentiel sous forme de dump, on met à jour les binaires Subversion puis on importe le dump avec la nouvelle version de Subversion.

C'est donc élégant, mais difficile à faire sur une base de données relationnelle classique, comme la base de PhpWebGallery. En relisant ce billet avant publication, je me demande si cette solution est vraiment utilisée en dehors des releases... je pense que les développeurs de Subversion doivent utiliser une autre technique.

Solution de Mantis

Mantis est un outil de suivi de bogues. Il se trouve que c'est celui utilisé pour le projet PhpWebGallery (décidément...). C'est une application PHP/MySQL tout ce qu'il y a de plus classique.

Le principe simplifié est le suivant :

  • le fichier upgrade.php contient la liste des requêtes SQL à appliquer. uprade.php est placé en gestion de version.
  • du côté de la base, la liste des requêtes déjà appliquée est stockée.
  • à chaque mise à jour via le gestionnaire de version, un petit tour du côté upgrade.php liste les requêtes existantes et non appliquées, Mantis s'occupe évidemment tout seul d'appliquer uniquement les nouvelle requêtes.

Magique, le principe permet le travail distant à plusieurs.

Conclusion

Etant donné l'absence de solution pour PhpWebGallery, et l'existence d'une solution élégante comme celle de Mantis, je pense bientôt mettre en place une solution analogue. En améliorant si j'y arrive.