182 votes

Comment gérez-vous les bases de données de développement, test et production ?

J'ai eu un moment difficile essayer de trouver de bons exemples de la façon de gérer la base de données des schémas et des données entre le développement, les tests et les serveurs de production.

Voici notre programme d'installation. Chaque développeur dispose d'une machine virtuelle à l'exécution de notre application et de la base de données MySQL. Il leur bac à sable pour faire ce qu'ils veulent. Actuellement, les développeurs vont faire un changement dans le schéma SQL et faire un dump de la base de données vers un fichier texte qu'ils s'engagent dans le SVN.

Nous sommes désireux de déployer une intégration continue serveur de développement qui sera toujours la dernière commis code. Si nous le faisons maintenant, il va recharger la base de données à partir de SVN pour chaque construction.

Nous avons un test de serveur (virtuel) qui s'occupe de "la libération des candidats". Déploiement sur le serveur de test est actuellement un processus très manuel, et implique généralement me le chargement de la dernière version de SQL à partir de SVN et le tordre. En outre, les données sur le serveur de test est incohérent. Vous vous retrouvez avec ce que des données de test de la dernière développeur de commettre avait sur son bac à sable serveur.

Où tout se casse est le déploiement à la production. Puisque nous ne pouvons pas remplacer le live de données avec des données de test, cela implique manuellement re-création de toutes les modifications de schéma. Si il y avait un grand nombre de modifications de schéma ou de la conversion des scripts pour manipuler les données, cela peut faire très poilue.

Si le problème était juste le schéma, Il serait plus facile de problème, mais il est "base de données" dans la base de données est mise à jour au cours du développement, tels que les méta-données des autorisations de sécurité et les tables.

C'est le plus grand obstacle que je vois dans la voie de l'intégration continue et en une seule étape-construit. Comment pensez - vous résoudre?


Une question: comment vous faites le suivi des versions de base de données de sorte que vous savez quels scripts à exécuter pour mettre à niveau une instance de base de données? Est une version de table comme la Lance mentionne ci-dessous la procédure standard?


Merci pour la référence à Tarantino. Je ne suis pas dans une .NET de l'environnement, mais j'ai trouvé leurs DataBaseChangeMangement page wiki pour être très utile. Surtout, cette Présentation Powerpoint (.ppt)

Je vais écrire un script Python qui vérifie les noms de *.sql scripts dans un répertoire donné contre une table dans la base de données et exécute ceux qui ne sont pas dans l'ordre selon un entier qui forme la première partie du nom de fichier. Si c'est une jolie solution simple, comme je pense qu'elle sera, alors, je vais le poster ici.


J'ai un travail de script pour cette. Il gère l'initialisation de la DB si il n'existe pas et l'exécution de scripts de mise à niveau si nécessaire. Il y a aussi des commutateurs pour nettoyer une base de données existante et de l'importation des données de test à partir d'un fichier. Il est environ 200 lignes, de sorte que je ne poste pas (bien que je pourrais le mettre sur pastebin si il y a un intérêt).

56voto

Lance Fisher Points 13547

Il ya quelques bonnes options. Je ne voudrais pas utiliser le "restaurer une sauvegarde" de la stratégie.

  1. Script toutes vos modifications de schéma, et vous avez votre serveur CI d'exécuter ces scripts sur la base de données. Disposer d'une version de la table de garder une trace de l'actuelle version de base de données, et seulement exécuter les scripts si elles sont pour une version plus récente.

  2. Utiliser une solution de migration. Ces solutions varient selon la langue, mais pour .NET-je utiliser Migrator.NET. Cela permet à la version de votre base de données et déplacer vers le haut et vers le bas entre les versions. Votre schéma est spécifié dans le code C#.

29voto

tbreffni Points 3031

Vos développeurs besoin d'écrire des scripts de modification de schéma (et de modification des données) pour chaque bug/feature dans le travail, non pas simplement dump l'ensemble de la base de données dans la source de contrôle. Ces scripts de mise à niveau de l'actuelle base de données de production de la nouvelle version en cours de développement.

Votre processus de génération de restaurer une copie de la base de données de production dans un environnement approprié et l'exécution de tous les scripts à partir de la source de contrôle, qui permettra de mettre à jour la base de données à la version actuelle. Nous le faisons sur une base quotidienne pour s'assurer que tous les scripts s'exécutent correctement.

14voto

Juha Syrjälä Points 11475

Jetez un oeil à comment Ruby on Rails cela.

Tout d’abord il sont donc appelés fichiers de migration, qui transforment fondamentalement le schéma de base de données et les données de la version N à la version N +1 (ou en cas de rétrogradation de la version N +1 à N). Base de données a table qui indique la version actuelle.

Bases de données de test sont toujours essuyés propres avant les tests unitaires et remplis avec les données fixes des fichiers.

11voto

Esko Luontola Points 53877

Le livre de Refactorisation des Bases de données: Évolution de la Base de données de Conception peut vous donner quelques idées sur la façon de gérer la base de données. Une version courte est lisible aussi à http://martinfowler.com/articles/evodb.html

Dans un PHP+MySQL projet, j'ai eu de la base de données numéro de révision stockée dans la base de données, et lorsque le programme se connecte à la base de données, il va d'abord vérifier la révision. Si le programme nécessite une révision différentes, il va ouvrir une page pour la mise à niveau de la base de données. Chaque mise à niveau est spécifié dans le code PHP, qui va modifier le schéma de base de données et de migrer toutes les données existantes.

5voto

Rad Points 6308

Vous pouvez également regarder en utilisant un outil tel que SQL Compare à la différence entre les différentes versions d’une base de données, ce qui vous permet de migrer rapidement entre les versions de script

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X