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

J’ai eu du mal à trouver de bons exemples de gestion des schémas de firebase database et des données entre les serveurs de développement, de test et de production.

Voici notre configuration. Chaque développeur dispose d’une machine virtuelle exécutant notre application et la firebase database MySQL. C’est leur bac à sable personnel pour faire ce qu’ils veulent. Actuellement, les développeurs apportent une modification au schéma SQL et effectuent un vidage de la firebase database dans un fichier texte qu’ils valident dans SVN.

Nous souhaitons déployer un serveur de développement à continuous integration qui exécutera toujours le dernier code engagé. Si nous faisons cela maintenant, il rechargera la firebase database à partir de SVN pour chaque construction.

Nous avons un serveur de test (virtuel) qui exécute des “candidats à la libération”. Le déploiement sur le serveur de test est actuellement un processus très manuel, qui implique généralement de charger le dernier SQL depuis SVN et de le modifier. En outre, les données sur le serveur de test sont incohérentes. Vous vous retrouvez avec toutes les données de test que le dernier développeur à avoir eu sur son serveur sandbox.

Là où tout se brise, c’est le déploiement en production. Comme nous ne pouvons pas écraser les données en direct avec des données de test, cela implique de recréer manuellement toutes les modifications du schéma. S’il y avait un grand nombre de modifications de schéma ou de scripts de conversion pour manipuler les données, cela peut devenir vraiment difficile.

Si le problème ne concernait que le schéma, le problème serait plus facile, mais la firebase database contient également des données “de base” mises à jour pendant le développement, telles que les métadonnées dans les tables de sécurité et d’permissions.

C’est le plus grand obstacle que je vois en ce qui concerne l’continuous integration et la création en une étape. Comment le résous- tu ?


Une question de suivi: comment suivez-vous les versions des bases de données pour savoir quels scripts exécuter pour mettre à niveau une instance de firebase database donnée? Un tableau de version comme Lance mentionne-t-il en dessous de la procédure standard?


Merci pour la référence à Tarantino. Je ne suis pas dans un environnement .NET, mais j’ai trouvé leur page wiki DataBaseChangeMangement très utile. Surtout cette présentation PowerPoint (.ppt)

Je vais écrire un script Python qui vérifie les noms des scripts *.sql dans un répertoire donné par rapport à une table de la firebase database et exécute ceux qui ne sont pas présents dans la base d’un entier formant la première partie de la firebase database. nom de fichier. Si c’est une solution assez simple, comme je le soupçonne, alors je la posterai ici.


J’ai un script de travail pour cela. Il gère l’initialisation de la firebase database si elle n’existe pas et exécute les scripts de mise à niveau si nécessaire. Il existe également des commutateurs permettant d’effacer une firebase database existante et d’importer des données de test à partir d’un fichier. C’est environ 200 lignes, donc je ne le posterai pas (bien que je puisse le mettre sur pastebin s’il y a de l’intérêt).

Il y a plusieurs bonnes options. Je n’utiliserais pas la stratégie “restaurer une sauvegarde”.

  1. Script tous vos changements de schéma et demandez à votre serveur CI d’exécuter ces scripts sur la firebase database. Avoir une table de version pour garder une trace de la version actuelle de la firebase database et exécuter uniquement les scripts s’ils sont destinés à une version plus récente.

  2. Utilisez une solution de migration. Ces solutions varient selon la langue, mais pour .NET, j’utilise Migrator.NET. Cela vous permet de mettre à jour votre firebase database et de vous déplacer entre les versions. Votre schéma est spécifié dans le code C #.

Vos développeurs doivent écrire des scripts de modification (schéma et modification des données) pour chaque bogue / fonctionnalité sur lequel ils travaillent, et pas simplement copier la firebase database entière dans le contrôle des sources. Ces scripts vont mettre à niveau la firebase database de production actuelle vers la nouvelle version en développement.

Votre processus de génération peut restaurer une copie de la firebase database de production dans un environnement approprié et exécuter tous les scripts du contrôle de code, ce qui mettra à jour la firebase database vers la version actuelle. Nous le faisons quotidiennement pour nous assurer que tous les scripts fonctionnent correctement.

Regardez comment Ruby on Rails fait cela.

D’abord, il y a les fichiers de migration qui transforment le schéma de firebase database et les données de la version N à la version N + 1 (ou en cas de rétrogradation de la version N + 1 à N). La firebase database a une table qui indique la version actuelle.

Les bases de données de test sont toujours nettoyées avant les tests unitaires et remplies avec les données fixes des fichiers.

Le livre Refactoring Databases: Evolutionary Database Design pourrait vous donner quelques idées sur la façon de gérer la firebase database. Une version courte est également lisible sur http://martinfowler.com/articles/evodb.html

Dans un projet PHP + MySQL, le numéro de révision de la firebase database a été stocké dans la firebase database et lorsque le programme se connecte à la firebase database, il vérifie d’abord la révision. Si le programme nécessite une révision différente, il ouvrira une page pour mettre à niveau la firebase database. Chaque mise à niveau est spécifiée dans le code PHP, ce qui modifie le schéma de la firebase database et fait migrer toutes les données existantes.

  • Nommez vos bases de données comme suit – db_dev, db_test, db_qa, db_prod
  • Ainsi, vous pourriez déployer même les différents types de bases de données sur le même serveur physique (je ne vous le recommande pas, mais vous devrez peut-être … si les ressources sont limitées)
  • Assurez-vous de pouvoir déplacer les données automatiquement entre celles-ci
  • Séparer les scripts de création de firebase database de la population = Il devrait toujours être possible de recréer la firebase database à partir de zéro et de la remplir (à partir de l’ancienne version de la firebase database ou d’une source de données externe)
  • n’utilisez pas de chaînes de connexion de code dur dans le code (même pas dans les fichiers de configuration) – utilisez dans les fichiers de configuration des modèles de chaîne de connexion, que vous remplissez dynamicment, chaque reconfiguration du fichier application_layer qui nécessite une recompilation
  • utilisez le contrôle de version des bases de données et le contrôle de version des objects db – si vous pouvez vous le permettre, utilisez des produits prêts à l’emploi, sinon développez quelque chose par vous-même
  • suivre chaque changement de DDL et l’enregistrer dans une table d’historique ( exemple ici )
  • Sauvegardes QUOTIDIENNES! Testez la vitesse à laquelle vous seriez capable de restaurer quelque chose perdu à partir d’une sauvegarde (utilisez les scripts de restauration automathic
  • même votre firebase database DEV et le PROD ont exactement le même script de création; vous aurez donc des problèmes avec les données, alors permettez aux développeurs de créer la copie exacte de prod et jouez avec (je sais que je recevrai des moins pour l’état d’esprit et le processus métier vous coûteront beaucoup moins cher lorsque la merde atteindra le fan – obligez donc les codeurs à classer légalement tout ce qu’ils font, mais assurez-vous que celui-ci

C’est quelque chose dont je ne suis jamais satisfait – notre solution à ce problème. Pendant plusieurs années, nous avons maintenu un script de modification distinct pour chaque version. Ce script contiendrait les deltas de la dernière version de production. À chaque version de l’application, le numéro de version s’incrémenterait, donnant les résultats suivants:

  • dbChanges_1.sql
  • dbChanges_2.sql
  • dbChanges_n.sql

Cela a bien fonctionné jusqu’à ce que nous commencions à maintenir deux lignes de développement: Trunk / Mainline pour les nouveaux développements et une twig de maintenance pour les corrections de bogues, améliorations à court terme, etc. Inévitablement, nous avons dû modifier le schéma de la twig. À ce stade, nous avions déjà dbChanges_n + 1.sql dans le trunk, nous avons donc fini avec un schéma comme celui-ci:

  • dbChanges_n.1.sql
  • dbChanges_n.2.sql
  • dbChanges_n.3.sql

Encore une fois, cela a assez bien fonctionné, jusqu’à ce que nous ayons un jour levé les yeux et vu 42 scripts delta dans la ligne principale et 10 dans la twig. ARGH!

De nos jours, nous maintenons simplement un script delta et nous le laissons à la version SVN – c’est-à-dire que nous écrasons le script à chaque version. Et nous évitons de faire des changements de schéma dans les twigs.

Donc, je ne suis pas satisfait non plus. J’aime beaucoup le concept de migration depuis Rails. Je suis devenu fasciné par LiquiBase . Il prend en charge le concept de refactorisation de bases de données incrémentielles. Cela vaut le coup d’oeil et je vais le regarder en détail bientôt. Quelqu’un a l’expérience avec ça? Je serais très curieux d’entendre parler de vos résultats.

Vous pouvez également utiliser un outil tel que SQL Compare pour écrire la différence entre les différentes versions d’une firebase database, ce qui vous permet de migrer rapidement entre les versions.

Nous avons une configuration très similaire à l’OP.

Les développeurs se développent dans les VM avec des bases de données privées.

[Les développeurs vont bientôt s’engager dans des twigs privées]

Les tests sont exécutés sur des machines différentes (en fait dans des machines virtuelles hébergées sur un serveur) [sera bientôt exécuté par le serveur Hudson CI]

Testez en chargeant le dump de référence dans la firebase database. Appliquer les correctifs du schéma de développement puis appliquer les correctifs de données des développeurs

Exécutez ensuite les tests unitaires et système.

La production est déployée auprès des clients en tant qu’installateurs.

Ce que nous faisons:

Nous prenons une copie de schéma de notre firebase database sandbox. Ensuite, un vidage de données SQL. Nous différons cela à la ligne de base précédente. cette paire de deltas consiste à mettre à jour n-1 à n.

nous configurons les dumps et les deltas.

Donc, pour installer la version N CLEAN, nous exécutons le dump dans une firebase database vide. Pour patcher, appliquez les patches intermédiaires.

(Juha a mentionné l’idée de Rail d’avoir une table enregistrant la version actuelle de la firebase database est une bonne idée et devrait rendre l’installation des mises à jour moins lourde.)

Les deltas et les dumps doivent être revus avant le test bêta. Je ne vois aucun moyen de contourner cela car j’ai vu des développeurs insérer des comptes de test dans la firebase database pour eux-mêmes.

Découvrez le dbdeploy , des outils Java et .net sont déjà disponibles, vous pouvez suivre leurs normes pour la disposition des fichiers SQL et la table de version du schéma et écrire votre version de python.

J’ai peur d’être d’accord avec d’autres affiches. Les développeurs doivent créer des scripts pour leurs modifications.

Dans de nombreux cas, une simple ALTER TABLE ne fonctionnera pas, vous devez également modifier les données existantes – les développeurs ont besoin de savoir quelles migrations sont requirejses et s’assurer qu’ils sont correctement scriptés (bien sûr, vous devrez tester cela avec précaution le cycle de libération).

De plus, si vous avez un sens, vous obligerez vos développeurs à annuler les scripts pour leurs modifications afin de pouvoir les annuler si besoin est. Cela devrait également être testé pour s’assurer que leur annulation s’exécute non seulement sans erreur, mais laisse le DB dans le même état que précédemment (ce n’est pas toujours possible ou souhaitable, mais c’est une bonne règle la plupart du temps) .

Comment vous connectez cela à un serveur CI, je ne sais pas. Votre serveur CI doit peut-être avoir un instantané de construction connu, qu’il rétablit chaque nuit et applique ensuite toutes les modifications. C’est probablement mieux, sinon un script de migration cassé ne sera pas seulement détruit, mais tous les suivants.

Si vous êtes dans l’environnement .NET, la solution est Tarantino . Il gère tout cela (y compris les scripts SQL à installer) dans une version NANT.

J’ai écrit un outil qui (en accrochant dans Open DBDiff ) compare les schémas de firebase database et vous proposera des scripts de migration. Si vous apportez une modification qui supprime ou modifie des données, elle génère une erreur, mais propose une suggestion pour le script (par exemple, lorsqu’une colonne manquante dans le nouveau schéma vérifie si la colonne a été renommée et crée xx – généré. script.sql.suggestion contenant une instruction rename).

http://code.google.com/p/migrationscriptgenerator/ SQL Server seulement je crains 🙁 Il est également assez alpha, mais il est TRÈS faible frottement (en particulier si vous le combinez avec Tarantino ou http://code.google .com / p / simplescriptrunner / )

La façon dont je l’utilise est d’avoir un projet de scripts SQL dans votre .sln. Vous avez également une firebase database db_next vers laquelle vous apportez vos modifications (à l’aide de Management Studio ou NHibernate Schema Export ou LinqToSql CreateDatabase ou quelque chose du genre ). Ensuite, vous exécutez migrationscriptgenerator avec les DB _dev et _next, ce qui crée. les scripts de mise à jour SQL pour la migration.

Nous utilisons la ligne de commande mysql-diff : il affiche une différence entre deux schémas de firebase database (à partir de la firebase database ou du script) en tant que script ALTER. mysql-diff est exécuté au démarrage de l’application et si le schéma a changé, il est envoyé au développeur. Pour que les développeurs n’aient pas besoin d’écrire manuellement les ALTER, les mises à jour des schémas se font de manière semi-automatique.

Pour la firebase database Oracle, nous utilisons les outils oracle-ddl2svn .

Cet outil automatise le prochain processus

  1. pour chaque schéma db get schéma ddls
  2. mettez le sous version contol

changements entre instances résolus manuellement