Comment gérer les modifications de schéma de base de données dans les versions de projet open source

Je gère une application web open source PHP / MySQL utilisée par quelques écoles K-12 et certains collèges. Je suis également le seul développeur du projet. Alors que ce n'était plus qu'un téléchargement source d'une application hébergée par mon employeur, j'ai travaillé au cours de la dernière année pour en faire un "vrai" projet open source, avec de la documentation, des versions numérotées, des journaux des modifications publics, etc.

Je cherche à améliorer le processus de mise à niveau, et l'un des domaines potentiellement douloureux (en particulier pour les écoles affamées d'expertise informatique) concerne les modifications du schéma de base de données entre les versions. Ils n'ont pas tendance à se produire souvent ou à être des changements radicaux, mais j'apprécierais des suggestions sur le processus.

Actuellement, je gère un script d'installation SQL de base pour configurer la base de données dans une nouvelle installation. Cela inclut le schéma complet de la version actuelle; aucune autre action n'est requise pour une nouvelle installation. Les modifications qui surviennent entre les versions sont stockées dans des upgrade-$releasever.sqlscripts, et il est nécessaire d'exécuter tous les scripts de mise à niveau de manière incrémentielle pour toutes les versions qui ont été ignorées.

Les scripts shell ne conviennent pas, car beaucoup de nos utilisateurs fonctionnent sur des hôtes sans accès shell. En raison d'autres priorités, il est peu probable qu'un script d'installation / mise à niveau complexe basé sur un navigateur PHP se matérialise. J'aimerais cependant faire quelque chose avec un script PHP basé sur un navigateur pour simplifier les mises à niveau. Des suggestions sur la façon de l'aborder?

Mon projet a un fichier update.php que l'utilisateur exécute via son navigateur après avoir installé une nouvelle version du logiciel. Ce script de mise à jour vérifie un numéro de version de base de données qui est conservé dans une table dans la base de données active et effectue toutes les opérations de modification de base de données qui obtiendront ce schéma de base de données au dernier, ce qui inclut la mise à jour de ce numéro de version de base de données.

Drupal CMS a une solution intéressante à votre problème. Je suggère de jeter un œil à Drupal en général, si vous développez des solutions Web utilisant PHP. C'est mon CMS PHP préféré et je serai assez partisan pour dire que c'est le meilleur du marché. ;)

Drupal propose un wrapper d'interaction de base de données assez sophistiqué. Il permet d'abstraire le type de base de données réel du développeur du module, donc vous ne vous souciez pas vraiment de savoir si le serveur exécute PostgreSQL, MySQL, etc. Vous pouvez également créer votre propre interface. Chaque module doit fournir le fichier module.install qui contient hook_schemaet hook_install. hook_schemaest utilisé pour déclarer le schéma de table du module, tandis qu'il hook_installexécute la procédure d'installation. L'architecture prend également en charge la notion de mises à jour, donc si l'utilisateur a déjà installé le module, les bons hooks de mise à jour sont invoqués et permettent de mettre à jour le schéma de table facilement.

Jetez un œil: http://drupal.org/node/146862 Même si Drupal n'est pas pour vous, je suis sûr que vous pouvez apprendre quelque chose de leurs décisions architecturales.

Nous l'avons fait en créant des dossiers de version. Nous avons placé tous les scripts de base de données dans ce dossier. Lorsque le moment est venu de le déployer auprès d'un nouveau client, il a obtenu la dernière version.

Nous avons également conservé tous les scripts de mise à niveau dans ce dossier. De cette façon, nous pourrions migrer un client de la version x vers la version y.

Ce n'est pas la meilleure méthode ... mais cela a fonctionné pour nous.