Wie verwalten Sie Datenbanken in Entwicklung, test und Produktion?

https://stackoverflow.com/questions/6371

mysql
svn

08-06-2019
|

Frage

Ich habe eine harte Zeit versucht zu finden, gute Beispiele, wie die Verwaltung von Datenbank-schemas und Daten zwischen Entwicklungs -, test-und Produktions-Server.

Hier ist unser setup.Jeder Entwickler hat eine virtuelle Maschine mit unserer app und der MySQL-Datenbank.Es ist Ihre persönliche sandbox zu tun, was Sie wollen.Derzeit werden Entwickler eine änderung an der SQL-schema und machen Sie einen dump der Datenbank in eine text-Datei, die Sie commit in SVN.

Wir wollen für die Bereitstellung einer continuous integration development server, der wird immer mit der neuesten verpflichtet code.Wenn wir das jetzt tun, es wird laden Sie die Datenbank von SVN für jeden build.

Wir haben einen test (virtuellen) server, das ausgeführt wird "release candidates." Die Bereitstellung der test-server ist derzeit ein sehr manueller Prozess, und in der Regel auch mich laden Sie das neueste SQL von SVN und optimieren es.Auch die Daten auf dem test server ist nicht konsistent.Sie am Ende mit dem, was test-Daten der letzten Entwickler zu Begehen, hatte in seinem sandbox-server.

Wo alles zusammenbricht, ist die Bereitstellung bis zur Produktion.Da wir nicht überschreiben kann die live-Daten mit test-Daten dies betrifft manuell neu zu erstellen, die alle das schema ändert.Wenn es eine große Anzahl von schema-änderungen oder Konvertierung Skripte, Daten zu Bearbeiten, dies kann man wirklich haarig.

Wenn das problem war nur, das schema, wäre Es ein einfacheres problem, aber es ist "base" - Daten in der Datenbank aktualisiert wird, während der Entwicklung als auch, wie meta-Daten-Sicherheit und-Berechtigungen Tabellen.

Dies ist die größte Hürde sehe ich in Richtung continuous integration und one-step-baut.Wie Sie es lösen?

Eine follow-up-Frage:wie tun Sie erfassen, Datenbank-Versionen, damit Sie wissen, welche Skripts ausgeführt werden, um ein upgrade einer Datenbank-Instanz?Ist eine version der Tabelle wie Lance erwähnt unter dem standard-Verfahren?

Vielen Dank für den Verweis auf Tarantino.Ich bin nicht in Sie ein .NET-Umgebung, aber ich fand Ihre DataBaseChangeMangement wiki-Seite sehr hilfreich.Vor allem diese Powerpoint-Präsentation (.ppt)

Ich werde schreiben Sie ein Python-Skript, das überprüft den Namen *.sql Skripte in einem bestimmten Verzeichnis auf eine Tabelle in der Datenbank und führt diejenigen, die es nicht gibt, um basierend auf eine ganze Zahl, die den ersten Teil des Dateinamens.Wenn es ist eine ziemlich einfache Lösung, wie ich vermute, es wird werden, dann werde ich es hier posten.

Ich habe ein funktionierendes Skript für dieses.Es behandelt die Initialisierung der DB, wenn es nicht vorhanden ist, und ausführen des upgrade-Skripts als notwendig.Es gibt auch Schalter zum löschen einer vorhandenen Datenbank und importieren von test-Daten aus einer Datei.Es ist etwa 200 Zeilen, also werde ich nicht veröffentlichen (allerdings könnte ich es auf pastebin, wenn es Interesse).

Lösung

Es gibt ein paar gute Möglichkeiten.Ich würde nicht verwenden Sie die "restore backup" - Strategie.

Skript alle deine änderungen am schema, und Ihr CI-server ausführen dieser Skripte für die Datenbank.Eine version der Tabelle zu halten track der aktuellen Datenbank-version, und nur die Scripte auszuführen, wenn Sie eine neuere version.
Verwenden Sie eine migration Lösung.Diese Lösungen variieren von Sprache zu Sprache, aber für .Ich NET verwenden Migrator.NET.Dies ermöglicht Ihnen, die version Ihrer Datenbank und nach oben und unten bewegt zwischen den Versionen.Ihr schema ist angegeben in C# code.

Andere Tipps

Die Entwickler schreiben müssen Skripts ändern (schema und Daten) für jede bug/feature " Sie arbeiten, nicht einfach nur dump die gesamte Datenbank in die Quellcodeverwaltung.Diese Skripte aktualisieren Sie die aktuellen Produktions-Datenbank auf die neue version in der Entwicklung.

Ihr build-Prozess wiederherstellen können eine Kopie der Produktions-Datenbank in eine geeignete Umgebung und führen Sie alle Skripts aus, die Quellcodeverwaltung, das update der Datenbank auf die aktuelle version.Wir tun dies auf einer täglichen basis, um sicherzustellen, dass alle Skripts ordnungsgemäß ausgeführt.

Schauen, wie Ruby on Rails macht.

Zunächst gibt es sogenannte migration von Dateien, dass im Grunde genommen verwandeln-Datenbank-schema und-Daten von version N auf version N+1 (oder bei einem Downgrade von version N+1-N).Datenbank-Tabelle, die erzählt aktuellen version.

Test-Datenbanken sind immer abgewischt werden können, bevor Sie unit-tests und gefüllt mit festen Daten aus Dateien.

Das Buch Refactoring-Datenbanken:Evolutionäre Datenbank-Design vielleicht geben Ihnen einige Ideen, wie Sie um die Datenbank zu verwalten.Eine kurze version ist gut lesbar auch bei http://martinfowler.com/articles/evodb.html

In einem PHP+MySQL-Projekt hatte, habe ich die Datenbank überarbeitet Nummer in der Datenbank gespeichert, und wenn das Programm die Verbindung zur Datenbank herstellt, wird es zuerst in revision.Wenn das Programm erfordert eine andere revision, öffnet sich eine Seite, auf der die Aktualisierung der Datenbank.Jedes upgrade ist angegeben in PHP-code, um das Datenbankschema und die Migration aller vorhandenen Daten.

Name Datenbanken wie folgt - db_dev , db_test , db_qa , db_prod (Natürlich würden Sie niemals hardcode db-Namen
Damit würden Sie bereitstellen können auch die verschiedenen Typen von db ' s auf dem gleichen physischen server ( ich nicht empfehlen , aber Sie müssen möglicherweise ...wenn die Ressourcen knapp bemessen sind )
Sicherzustellen, dass Sie in der Lage sein würde, zu verschieben, Daten zwischen diesen automatisch
Trennen Sie die db-Erstellung von Skripts von der Bevölkerung = Es sollte immer möglich, neu zu erstellen die db von Grund auf neu und füllen Sie es ( von der alten db-version oder externen Datenquelle
verwenden Sie nicht fest Verbindungszeichenfolgen in der code ( noch nicht in die config-Dateien) in den config-Dateien Verbindungszeichenfolge Vorlagen , die Sie bevölkern, dynamisch , jeder Neukonfiguration des application_layer die müssen neu kompilieren ist SCHLECHT
verwenden Sie Datenbank-Versionierung und db-Objekte-Versionierung - wenn Sie es sich leisten können verwenden Sie fertige Produkte , wenn nicht, entwickeln Sie etwas auf Ihre eigenen
track jede DDL-ändern und speichern Sie es in eine Geschichte Tabelle ( Beispiel hier )
TÄGLICHE backups !Testen Sie, wie schnell Sie wäre in der Lage, wiederherstellen von etwas verloren aus einer Sicherung (verwenden automathic restore-Skripts
auch Ihre DEV-Datenbank und die PRODUKTE haben genau die gleiche Erstellungsskript Sie haben Probleme mit den Daten, so dass es den Entwicklern ermöglichen, erstellen die eine exakte Kopie von prod und spielen mit Ihr ( ich weiß, ich werde erhalten Minuspunkte für diese ein , aber Veränderung in der Einstellung und der business-Prozess kostet Sie viel weniger, wenn die Scheiße trifft den fan - also zwingen den Programmierer zu Tiefgestellt legal, was auch immer es macht , sondern sicherzustellen, dass diese einen

Dies ist etwas, was ich bin ständig unzufrieden mit unsere Lösung für das problem.Für mehrere Jahre, wir erhalten eine separate änderung Skript für jede Veröffentlichung.Dieses Skript enthält die deltas aus der letzten Produktion freigeben.Mit jeder Version der Anwendung, die version Anzahl erhöhen, geben Sie etwas wie das folgende:

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

Dies funktioniert gut genug, bis wir anfingen, die Aufrechterhaltung der zwei Linien der Entwicklung:Trunk/Magistrale für neue Entwicklung und Wartung Zweig für bug-fixes, Kurzfristige Verbesserungen, etc.Zwangsläufig entstand die Notwendigkeit, änderungen an dem schema in der Filiale.Zu diesem Zeitpunkt hatten wir bereits dbChanges_n+1.sql in den Kofferraum, so dass wir gehen am Ende mit einem Schema wie dem folgenden:

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

Wieder, dies funktionierte gut genug, bis wir eines Tages schauten wir auf und sahen, 42 delta-Skripts in die Hauptstrecke und 10 in der Branche.ARGH!

Diese Tage wir pflegen eine delta-Skript und lassen SVN-version - d.h.wir überschreiben das Skript mit jedem release.Und wir scheuen davor zurück, Schemaänderungen in den Filialen.

Also, ich bin nicht zufrieden mit diesem, entweder.Ich mag das Konzept der Migration von Rails.Inzwischen bin ich ziemlich fasziniert mit LiquiBase.Es unterstützt das Konzept der inkrementellen Datenbank refactorings.Es ist einen Blick Wert und ich werde es bei der Suche im detail bald.Jemand Erfahrung damit?Ich wäre sehr neugierig zu hören, über Ihre Ergebnisse.

Sie könnte auch mit einem tool wie SQL Vergleichen Skript für die Unterschied zwischen verschiedenen Versionen einer Datenbank, so dass Sie schnell migrieren zwischen den Versionen

Wir haben ein sehr ähnliches setup, um die OP.

Die Entwickler entwickeln in der VM mit eigenem DB.

[Entwickler bald Begehen in privaten branches]

Tests auf unterschiedlichen Rechnern laufen ( eigentlich in in den VM ' s auf einem server gehostet) [Wird bald ausgeführt werden, von Hudson CI-server]

Test durch das laden der Referenz-dump in die Datenbank.Wenden Sie die Entwickler-schema-patches dann bewerben die Entwickler von Daten-patches

Dann führen Sie unit-und system tests.

Die Produktion bereitgestellt wird, um Kunden wie Installateure.

Was wir tun:

Nehmen wir ein schema dump von unserer sandbox DB.Dann eine sql-Daten-dump.Wir diff, die auf der vorherigen baseline.paar deltas zu aktualisieren, n-1 bis n.

wir konfigurieren die Deponien und deltas.

So installieren version N SAUBER führen wir den dump in eine leere db.Patch, gelten die dazwischen liegenden Flecken.

( Juha erwähnt Rail Idee mit einer Tabelle der Aufzeichnung des aktuellen DB-version ist gut und sollte die Installation von updates weniger angespannt.)

Deltas und Deponien sind zu überprüft werden vor der beta-test.Ich sehe keinen Weg, um dieses, wie ich habe Entwickler gesehen, die insert-test-accounts in der DB selbst.

Überprüfen Sie heraus die dbdeploy, gibt es Java-und .net-tools bereits vorhanden sind, könnte Folgen, Ihre standards für die SQL-Datei, layouts und schema-version der Tabelle und schreiben Sie Ihre python-version.

Ich fürchte, ich bin im Einvernehmen mit den anderen Plakaten.Entwickler müssen in der Skript, deren änderungen.

In vielen Fällen kann ein einfacher ALTER-TABELLE nicht funktioniert, Sie ändern müssen die vorhandenen Daten zu - Entwicklern müssen, was über das, was Migrationen erforderlich sind, und stellen Sie sicher, Sie sind scripted richtig (natürlich müssen Sie test dieses gezielt an einem gewissen Punkt in den release-Zyklus).

Außerdem, wenn Sie irgendeinen Sinn haben, erhalten Sie Ihre Entwickler-Skript-rollbacks für Ihren änderungen als gut, so dass Sie rückgängig gemacht werden können, wenn es sein muss.Dies sollte auch getestet werden, um sicherzustellen, dass Ihre rollback nicht nur ausgeführt, ohne Fehler, aber lässt die DB in der gleichen Zustand, wie es war, in der früher (dies ist nicht immer möglich oder wünschenswert, aber ist eine gute Regel, die meisten der Zeit).

Wie Sie Haken, die in einen CI-server, ich weiß nicht.Vielleicht ist Ihr CI-server muss einen bekannten build-snapshot auf, die es wieder, jede Nacht, und wendet dann alle änderungen seitdem.Das ist wahrscheinlich das beste, da sonst eine kaputte Migrations-script wird nicht brechen, nur in dieser Nacht zu bauen, aber alle nachfolgenden.

Wenn Sie in der .NET-Umgebung, dann ist die Lösung Tarantino.Es kümmert sich um all dies (einschließlich der sql-Skripts zu installieren) in einem NANT-build.

Ich habe ein tool geschrieben, welches (durch einbinden in Öffnen DBDiff) vergleicht Datenbank-Schemata, und schlägt vor, Migrations-Skripts zu Sie.Wenn Sie eine änderung vornehmen, löscht oder ändert die Daten, es wirft einen Fehler, aber einen Vorschlag für das script (z.B.wenn eine Spalte in fehlt in dem neuen schema, es wird überprüft, ob die Spalte umbenannt wurde und erstellen xx - Skript.sql.Vorschlag mit einem rename-Anweisung).

http://code.google.com/p/migrationscriptgenerator/ SQL Server nur fürchte ich :( Es ist auch ziemlich alpha, aber es ist SEHR low-Reibung (besonders, wenn Sie es kombinieren mit Tarantino oder http://code.google.com/p/simplescriptrunner/)

Die Art, wie ich es haben eine SQL-Skripts Projekt in Ihrer .sln.Sie haben auch eine db_next Datenbank lokal, das Sie machen Ihre änderungen (mithilfe von Management Studio oder NHibernate-Schema Exportieren oder LinqToSql CreateDatabase oder etwas).Dann werden Sie ausführen migrationscriptgenerator mit der _dev und _next DBs erzeugt.die SQL-update-Skripte für die Migration über.

Wir sind mit Befehl-Linie mysql-diff:gibt es einen Unterschied zwischen zwei Datenbank-Schemata (von der live-DB-oder Skript) als ALTER-Skript.mysql-diff ausgeführt wird beim starten der Anwendung, und wenn schema verändert, berichten Entwickler.So, die Entwickler brauchen nicht zu schreiben, Ändert manuell, schema-updates passieren, semi-automatisch.

Für die oracle-Datenbank, die wir verwenden oracle-ddl2svn Werkzeuge.

Dieses tool automatisiert nächsten Prozess

für jedes db-Schema bekommen Schema ddls
legen Sie es unter version Control

die änderungen zwischen den Instanzen manuell gelöst

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow