Gestion des modifications du schéma de la base de données lors de l'envoi de nouvelles versions

Pendant les périodes de développement intense, le schéma de la base de données change à la fois rapidement et en continu, et au moment où notre poussée hebdomadaire vers la version bêta arrive, le schéma a tellement changé que la seule option raisonnable est de neutraliser toutes les tables que je peux et copiez les nouvelles versions de ma base de données de développement. De toute évidence, cela ne fonctionnera pas une fois que nous aurons lancé, car les données de production sont une recette pour un désastre, alors je me demandais quelles stratégies existaient pour gérer les changements de schéma de base de données d'une version / révision à une autre?

J'en ai trouvé ou expérimenté:

1. Nuke-and-dump direct d'une base de données à une autre (ce que je fais maintenant)
2. Gérer un fichier UPDATE.sql avec des instructions SQL exécutées via un script ou à la main.
3. Gestion d'un fichier update.php avec une valeur "db-schema-version" correspondante dans la base de données active

La troisième option semble être la plus judicieuse, mais il existe toujours la possibilité qu'une requête SQL mal construite échoue en cours de script, laissant la base de données dans un état semi-mis à jour, nécessitant une restauration d'une sauvegarde.

Cela ne semble pas être un problème, mais cela se produit, car en tant qu'équipe, nous utilisons phpMyAdmin, et je n'arrive même pas à me fier à moi-même, souvenez-vous d'avoir copié l'instruction SQL exécutée pour la coller dans le fichier update.php. Une fois que vous accédez à une autre page, je dois réécrire l'instruction SQL à la main, ou inverser ma modification et recommencer.

Je suppose que ce que j'espère, c'est une solution qui n'affecte pas notre flux de travail de développement établi?

Automatiser. Automatiser. Automatiser.

Vous êtes sur la bonne voie avec un numéro de version DB explicite, mais j'irais plus loin et rendrais le code explicitement conscient du schéma contre lequel il s'attend à fonctionner (par exemple, en validant le script DDL réel et en le faisant analyser par le programme de mise à jour) ); puis au moment de la mise à jour, il vous suffit de découvrir le schéma existant via les métadonnées de la base de données et INSERT / DROP / ALTER si nécessaire, peu importe de quelle version à quelle version vous mettez à jour. (Vous pouvez également conserver un numéro de version explicite dans la base de données elle-même et fournir l'intégralité de l'historique du schéma avec le programme d'installation afin que vous n'ayez même pas besoin de la découverte de schéma.)

Les erreurs de syntaxe potentielles dans le script de mise à jour SQL sont un problème, mais vous pouvez le résoudre en vérifiant que le programme de mise à jour ne peut produire que des instructions DDL correctes. (Les preuves formelles ne valent presque jamais la peine dans le développement de logiciels d'entreprise - trop d'efforts pour trop peu d'assurance - mais je pense que l'intégrité de la base de données est l'une des rares exceptions: le SQL de base n'est pas un langage particulièrement difficile à capturer formellement, et l'avantage de la protection des données de production est si importante que presque n'importe quel montant d'effort initial unique est justifié, en particulier s'il doit fonctionner pour des installations sans assistance,)

Le contrôle de version du schéma de base de données est la voie à suivre - chaque version n'a qu'une seule modification de la base de données, ou au moins des modifications qui peuvent être annulées dans leur ensemble. DBDeploy est un excellent outil pour automatiser cela.

Certaines choses que j'ai apprises utiles sont:

1. Testez toujours votre changement localement, et testez votre code avec lui, juste le ALTERpassage ne suffit pas
2. Vous devez synchroniser ceux qui doivent effectuer leur changement en premier - une simple page wiki où vous pouvez "prendre un certain nombre" a très bien fonctionné pour mon équipe.
3. N'essayez pas de réparer un changement cassé, ajoutez un nouveau contre-changement pour le nier, c'est beaucoup indolore
4. Votre code dépend de ces modifications - assurez-vous de lier les problèmes de votre système de suivi des bogues aux modifications de la base de données. Cela est très utile au moment du déploiement.
5. Inclure les modifications de base de données dans votre CI - appliquez vos modifications à une base de données CI lors de la validation. De plus, si vous avez des tests qui utilisent une base de données, exécutez-les lors de la validation.

Puisque vous utilisez phpMyAdmin, je suppose que vous utilisez également MySQL.

Jetez un œil aux diagrammes du modèle EER dans MySQL Workbench. Ils m'ont été d'une grande aide dans la maintenance et la mise à jour des schémas.

Tout d'abord, vous pouvez synchroniser le modèle avec une source de base de données. Pour que les modifications du diagramme soient poussées en tant que commandes ALTER TABLE. Cela vous permet d'effectuer vos modifications de schéma sur le diagramme, de le maintenir toujours à jour tout en poussant les mises à jour de votre base de données de développement en cas de besoin.

Deuxièmement, vous pouvez inverser l'ingénierie d'un diagramme EER à partir d'une source de base de données. Ce qui peut être pratique en prenant des modifications sur une base de données de développement et en mettant à jour une base de données de production car elle calculera les différences.

Troisièmement, il peut être utilisé pour aider à créer le SQL qui doit aller dans votre fichier "update.sql".

LES INCONVÉNIENTS:

Les déclencheurs et contraintes de base de données sont un problème avec le programme de mise à jour de synchronisation. Il ne semble pas connaître le bon ordre des choses. Les contraintes de clé étrangère génèrent souvent des erreurs, mais cela peut être résolu en modifiant le SQL qu'il génère.

Ce n'est pas un outil de migration de données. Toutes les modifications qui dépassent le schéma pur auront toujours besoin d'un SQL personnalisé.

Jetez un œil à http://south.aeracode.org - c'est une bibliothèque de migrations DB pour Django (un framework Python) mais:

1. vous pouvez en tirer de bonnes idées (et peut-être même trouver un clone PHP)
2. vous pouvez réellement l'utiliser indépendamment du reste de Django pour gérer les tables de votre application PHP / MySQL.

Il peut également générer des scripts de mise à jour de schéma; il gère également la plupart du temps les inversions de changement automatiquement.