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

Sie finden meine Frage vielleicht Wie erstellen Sie Ihre Datenbank aus der Versionskontrolle? nützlich.

Grundsätzlich ist eine effektive Verwaltung gemeinsam genutzter Ressourcen (wie einer Datenbank) schwierig. Das ist schwierig, denn es gilt, die Bedürfnisse mehrerer Personen unter einen Hut zu bringen, darunter andere Entwickler, Tester, Projektmanager usw.

Oft ist es effektiver, einzelnen Entwicklern eine eigene Sandbox-Umgebung zur Verfügung zu stellen, in der sie Entwicklung und Unit-Tests durchführen können, ohne andere Entwickler oder Tester zu beeinträchtigen. Dies ist jedoch kein Allheilmittel, da Sie nun einen Mechanismus bereitstellen müssen, um diese mehreren separaten Umgebungen im Laufe der Zeit miteinander zu synchronisieren. Sie müssen sicherstellen, dass die Entwickler eine vernünftige Möglichkeit haben, die Änderungen der anderen zu übernehmen (sowohl Daten, Schema als auch Code). Das ist nicht unbedingt einfacher. Eine gute SCM-Praxis kann helfen, aber es erfordert immer noch ein beträchtliches Maß an Zusammenarbeit und Koordination, um dies zu bewerkstelligen. Hinzu kommt, dass die Bereitstellung einer eigenen Kopie der gesamten Umgebung für jeden Entwickler Kosten für die Speicherung und zusätzliche DBA-Ressourcen für die Verwaltung und Überwachung dieser Umgebungen verursachen kann.

Hier sind einige Ideen, die Sie berücksichtigen sollten:

1. Erstellen Sie ein gemeinsames, öffentliches "Umgebungs-Whiteboard" (es könnte elektronisch sein), auf dem Entwickler leicht sehen können, welche Umgebungen verfügbar sind und wer sie verwendet.
2. Bestimmen Sie eine Person oder Gruppe als Eigentümer der Datenbankressourcen. Sie sind dafür verantwortlich, den Überblick über die Umgebungen zu behalten und helfen, die widersprüchlichen Anforderungen verschiedener Gruppen (Entwickler, Tester usw.) zu lösen.
3. Wenn Zeit und Budget es zulassen, sollten Sie Sandbox-Umgebungen für alle Ihre Entwickler einrichten.
4. Wenn Sie dies nicht bereits tun, sollten Sie die "Spielbereiche" der Entwickler von den Integrations-, Test- und Akzeptanztestumgebungen trennen.
5. Stellen Sie sicher, dass Sie kritische Datenbankobjekte versionieren - insbesondere solche, die sich häufig ändern, wie Trigger, gespeicherte Prozeduren und Ansichten. Sie wollen nicht, dass Ihre Arbeit verloren geht, wenn jemand die Änderungen eines anderen überschreibt.

Answer 2

Wir verwenden lokale Entwicklerdatenbanken und eine einzige Master-Datenbank für Integrationstests. Wir speichern Erstellungsskripte im SCM. Ein Entwickler ist für die Aktualisierung der SQL-Skripte auf der Grundlage des "Golden Master"-Schemas verantwortlich. Ein Entwickler kann bei Bedarf Änderungen an seiner lokalen Datenbank vornehmen, indem er die Daten in der Integrations-DB mit Hilfe eines Importprozesses auffüllt oder mit einem Tool (in unserem Fall Red Gate Data Generator) generiert. Falls erforderlich, löschen die Entwickler ihre lokale Kopie und können die Daten aus dem Erstellungsskript und den Integrationsdaten nach Bedarf aktualisieren. Normalerweise werden Datenbanken nur für Integrationstests verwendet, und wir spiegeln sie für Unit-Tests vor, so dass der Arbeitsaufwand für die Synchronisierung der Daten minimal ist.

Answer 3

Ich empfehle Ihnen, einen Blick auf Scott Allens Ansichten zu diesem Thema zu werfen. Er hat eine Reihe von Blogs geschrieben, die meiner Meinung nach hervorragend sind. Drei Regeln für die Datenbankarbeit , Die Grundlinie , Skripte ändern , Ansichten, gespeicherte Prozeduren usw. , Verzweigung und Zusammenführung .

Ich verwende diese Leitlinien mehr oder weniger, mit persönlichen Änderungen, und sie funktionieren.

Answer 4

In der Vergangenheit habe ich das auf verschiedene Weise gehandhabt.

Das eine ist das SQL-Script-Repository, das die Datenbank erstellt und auffüllt. Das ist gar keine schlechte Option und kann alles synchron halten (auch wenn Sie diese Methode nicht verwenden, sollten Sie diese Skripte pflegen, damit Ihre DB in der Versionskontrolle ist).

Die andere Variante (die ich bevorzuge) bestand darin, eine einzige Instanz einer "sauberen" Entwicklungsdatenbank auf dem Server zu haben, mit der niemand verbunden war. Wenn Entwickler ihre Entwicklungsdatenbanken aktualisieren mussten, führten sie ein SSIS-Paket aus, das die "saubere" Datenbank auf ihre Entwicklungskopie kopierte. Wir konnten dann unsere Entwicklungsdatenbanken nach Bedarf ändern, ohne anderen Entwicklern auf die Füße zu treten.

Answer 5

Wir haben ein Datenbank-Wartungstool, mit dem wir unsere Tabellen und unsere Prozeduren erstellen/aktualisieren.

Wir behalten lokale Datenbanken, mit denen wir nach Belieben spielen können, aber wenn wir zur "Baseline" zurückkehren müssen, holen wir uns ein Backup des "Masters" vom Server und stellen es lokal wieder her.

wenn wir Spalten/Tabellen/Procs hinzufügen, aktualisieren wir das dbMaintenance-Tool, das in der Versionskontrolle gehalten wird.

Manchmal ist es mühsam, aber es funktioniert ganz gut.