Wie verwalten Sie Datenbanken während der Entwicklung?

Question

Mein vierköpfiges Entwicklungsteam ist schon seit einiger Zeit mit diesem Problem konfrontiert:

Manchmal müssen wir mit demselben Datensatz arbeiten. Während wir also auf unseren lokalen Computern entwickeln, wird die Entwicklungsdatenbank aus der Ferne verbunden.

Manchmal müssen wir jedoch Operationen auf der Datenbank ausführen, die auf die Daten anderer Entwickler einwirken, d.h. wir brechen Assoziationen. Hierfür wäre eine lokale Datenbank schön.

Gibt es eine bewährte Methode, um dieses Dilemma zu umgehen? Gibt es so etwas wie ein "SCM-Tool für Daten"?

Auf eine seltsame Art und Weise wäre es nützlich, eine Textdatei mit SQL-Abfragen zum Einfügen/Löschen/Aktualisieren im Git-Repository zu führen, aber ich denke, das könnte sehr schnell sehr langsam werden.

Wie geht ihr damit um?

Answer 1

Wenn Sie ein ORM wie nHibernate verwenden, erstellen Sie ein Skript, das sowohl das Schema als auch die Daten in der LOKALEN Entwicklungsdatenbank Ihrer Entwickler generiert.

Verbessern Sie dieses Skript während der Entwicklung, um typische Daten einzubeziehen.

Testen Sie vor der Bereitstellung in einer Staging-Datenbank.

Wir replizieren die Produktionsdatenbank in die UAT-Datenbank für die Endbenutzer. Diese Datenbank ist für Entwickler nicht zugänglich.

Es dauert weniger als ein paar Sekunden, um alle Tabellen zu löschen, sie neu zu erstellen und Testdaten einzuspeisen.

Wenn Sie ein ORM verwenden, das das Schema generiert, müssen Sie das Erstellungsskript nicht pflegen.

Answer 2

Zuvor habe ich an einem Produkt gearbeitet, das sich auf Data Warehouses bezog und auf Wunsch beim Kunden installiert werden konnte. Folglich wusste die Software, wie man die "Installation" durchführt (hauptsächlich die Erstellung des erforderlichen Datenbankschemas und die Eingabe statischer Daten wie Währungs-/Ländercodes usw.).

Da wir diese Informationen im Code selbst hatten und weil wir über steckbare SQL-Adapter verfügten, war es trivial, diesen Code mit einer In-Memory-Datenbank (wir verwendeten HSQL) zu verwenden. Folglich führten wir die meisten unserer eigentlichen Entwicklungsarbeiten und Leistungstests mit "echten" lokalen Servern (Oracle oder SQL Server) durch, aber alle Unit-Tests und anderen automatisierten Aufgaben mit prozessspezifischen In-Memory-DBs.

Wir hatten in dieser Hinsicht das Glück, dass wir bei einer Änderung der zentralisierten statischen Daten diese in den Upgrade-Teil der Installationsanweisungen aufnehmen mussten, so dass sie standardmäßig im SCM-Repository gespeichert, von den Entwicklern ausgecheckt und als Teil ihres normalen Arbeitsablaufs installiert wurde. Wenn ich darüber nachdenke, ist dies sehr ähnlich zu der von Ihnen vorgeschlagenen Idee eines DB-Changelogs, nur etwas formalisierter und mit einer domänenspezifischen Abstraktionsschicht drum herum.

Dieses System hat sehr gut funktioniert, denn jeder in wenigen Minuten eine voll funktionsfähige DB mit aktuellen statischen Daten aufbauen konnte, ohne jemandem auf die Füße zu treten. Ich kann nicht sagen, ob es sich lohnt, wenn Sie die Installations-/Aktualisierungsfunktionalität nicht benötigen, aber ich würde es auf jeden Fall in Betracht ziehen, weil es die Datenbankabhängigkeit völlig schmerzlos macht.

Answer 3

Wie wäre es mit diesem Ansatz?

Führen Sie ein separates Repo für eine "saubere Datenbank". Das Repo wird eine Sql-Datei mit Tabellenerstellungen/Einfügungen usw. sein.

Verwenden Sie Rails (ich bin sicher, dass es für jedes Git-Repo angepasst werden kann) und pflegen Sie die "saubere Datenbank" als Submodul innerhalb der Anwendung. Schreiben Sie ein Skript (Rake-Task, vielleicht), die eine lokale Dev-DB mit den SQL-Anweisungen abfragt.

So bereinigen Sie Ihre lokale Datenbank (und ersetzen sie durch neue Daten):

git submodule init
git submodule update

dann

rake dev_db:update ......... (or something like that!)

Answer 4

Ich habe eines von zwei Dingen getan. In beiden Fällen führen die Entwickler, die an Code arbeiten, der mit anderen in Konflikt geraten könnte, ihre eigene Datenbank lokal aus oder erhalten eine separate Instanz auf dem Entwicklungsdatenbankserver.

• Ähnlich wie von @tvanfosson empfohlen, behalten Sie eine Reihe von SQL-Skripten, die die Datenbank von Grund auf neu aufbauen können, o

• In regelmäßigen Abständen werden alle Entwicklerdatenbanken mit einer Kopie der Produktionsdaten oder mit einer verkleinerten/deidentifizierten Kopie der Produktionsdaten überschrieben, je nachdem, welche Art von Daten wir verwenden.

Answer 5

Ich würde allem zustimmen, was LBushkin in seiner Antwort gesagt hat. Wenn Sie SQL Server verwenden, haben wir hier bei Red Gate eine Lösung, die es Ihnen ermöglichen sollte, Änderungen problemlos zwischen mehreren Entwicklungsumgebungen auszutauschen.

http://www.red-gate.com/products/sql_source_control/index.htm

Wenn es für Ihren DBA aufgrund von Speicherproblemen schwierig ist, mehrere Entwicklungsumgebungen zuzulassen, hat Red Gate eine Lösung für dieses Problem. Mit der HyperBac-Technologie von Red Gate können Sie virtuelle Datenbanken für jeden Entwickler erstellen. Diese sehen genauso aus wie eine gewöhnliche Datenbank, aber im Hintergrund werden die gemeinsamen Daten von den verschiedenen Datenbanken gemeinsam genutzt. Auf diese Weise können Entwickler ihre eigenen Datenbanken haben, ohne eine unpraktische Menge an Speicherplatz auf Ihrem SQL-Server zu belegen.