Wie version control SQL Server-Datenbank, die mit Visual Studio Git Source Control Provider
Habe ich Git Source Control Provider setup und läuft gut.
Für Visual Studio-Projekte, das ist.
Das problem ist, dass jedes derartige Projekt ist fest gebunden zu einer SQL Server-Datenbank.
Ich weiß wie die Versionskontrolle einer Datenbank in seiner eigenen .git - repository, aber das ist weder bequem noch wirklich robust, denn idealerweise würde ich wollen, dass die gleichen ADD, COMMIT, TAG-und BRANCH-Befehle operieren auf beiden Verzeichnis-Bäume gleichzeitig, in einer synchronisierten Weise.
Gibt es eine Möglichkeit, Git SQL Server-Datenbank, die mit Visual Studio Git Source Control Provider in der Art und Weise, die ich beschrieben?
- Vielen Dank für die Korrektur der Tippfehler.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Können Sie installieren Sie die
SQL Server Data Toolswenn Sie wollen, aber Sie müssen nicht: Sie können Verwenden Sie die Database-Publishing-Assistenten Skript Ihre Tabelle Daten direkt aus Visual Studio in der Projektmappe Ordner, dann Git es genau wie du mit den anderen Projekt-Dateien in diesem Ordner.Können Sie speichern Sie Ihre Datenbank-schema, die als Visual studio-Projekt mithilfe SQL Server Data Tools und dann Versionskontrolle das Projekt mit Git.
Script Database as>DROP And CREATE Tozu exportieren, die ganze Sache als ein text-basiertes Skript, um die Visual Studio-Projektmappen-Verzeichnis, aber eine integrierte Lösung, wie Sie beschreiben, klingt vielversprechend. Welches tool von derSQL Server Data Toolseigentlich exportiert? Benötige ich den gesamten Satz von Werkzeugen? +1In der Datenbank Versionskontrolle Platz für 5 Jahren (als director of product management bei DBmaestro) und arbeitete als DBA seit über zwei Jahrzehnten, ich kann sagen, Sie ist die einfache Tatsache, dass Sie nicht behandeln, die Datenbank-Objekte, wie Sie behandeln Ihre Java -, C# - oder andere Dateien, und speichern Sie die änderungen in einfache DDL-Skripts.
Es gibt viele Gründe und ich werde ein paar Namen zu nennen:
macht nicht auf andere Entwickler. Ebenfalls wird der Entwickler nicht
betroffen von änderungen, die von Ihrer Kollegin. In der Datenbank wird dies
(in der Regel) nicht der Fall und der Entwickler teilen sich die gleiche Datenbank
Umgebung, so dass jede änderung, die begangen wurden, um die Datenbank beeinflussen
andere.
etc. (abhängig von der source-control-tool, das Sie verwenden). An diesem Punkt,
der code aus dem lokalen Verzeichnis des Entwicklers eingefügt
die source-control-repository. Entwickler wer will, um die neuesten
code benötigen, um die Anforderung an die source-control-tool. In der Datenbank
ändern bereits vorhanden ist und Auswirkungen auf andere Daten, auch wenn Sie nicht
Check-in in das repository.
überprüfen, um zu sehen, wenn die Datei geändert wurde eingecheckt und von einem anderen
Entwickler während der Zeit, die Sie änderungen an Ihrer lokalen Kopie. Wieder da
ist keine überprüfung für diese in der Datenbank. Wenn Sie ändern Sie eine Prozedur aus
Ihrem lokalen PC und in der gleichen Zeit, die ich ändern die gleiche Prozedur mit
code-form meinem lokalen PC, dann überschreiben wir die änderungen gegenseitig.
version des code in ein leeres Verzeichnis, und führen Sie dann ein build –
kompilieren Sie. Die Ausgabe sind Binärdateien, in dem wir kopieren & ersetzen
bestehende. Wir kümmern uns nicht, was vorher war. In der Datenbank können wir keine
erstellen Sie die Datenbank, wie wir Sie halten müssen, um die Daten! Auch die
Bereitstellung führt SQL-Skripte, die generiert wurden, die bauen
Prozess.
Inhalt) - Befehle) Sie übernehmen der aktuellen Struktur des
Umgebung der Struktur entspricht, die, wenn Sie die Skripts erstellen. Wenn nicht,
dann Ihre Skripte können scheitern, wie Sie versuchen, neue Spalte hinzufügen, die
bereits existiert.
syntax-Fehler, Datenbank-Abhängigkeiten Fehler, Skripte, die nicht
wiederverwendbare erschweren die Aufgabe der Entwicklung, Pflege,
das testen dieser Skripte. Darüber hinaus, diese Skripte kann auf eine
die Umwelt ist von dem unterscheidet, das Sie, obwohl es laufen würde
auf.
die Struktur des Objekts, die getestet wurde und dann Fehler
geschehen in der Produktion!
Gibt es viele mehr, aber ich denke, du hast das Bild.
Was ich gefunden habe, die funktioniert, ist die folgende:
check-out/check-in Operationen auf der Datenbank-Objekte. Dies wird
stellen Sie sicher, dass die version control repository entspricht dem code, der war
eingecheckt, wie es liest die Metadaten des Objekts in der check-in
Vorgang und nicht als ein getrennter Schritt manuell durchgeführt werden. Dies ermöglichen auch
mehrere Entwickler arbeiten parallel auf der gleichen Datenbank während
verhindern, dass Sie versehentlich zu überschreiben sich gegenseitig-code.
Vergleich, Konflikte zu identifizieren und zu identifizieren, wenn eine Differenz (wenn
vergleicht man die Struktur des Objekts zwischen der source-control
repository und die Datenbank) ist eine echte änderung, die Herkunft aus
Entwicklung oder der Unterschied war die Herkunft aus einem anderen Pfad
und dann sollte es übersprungen werden, wie die verschiedenen Zweigniederlassung oder einer
emergency Update.
schemas auf einmal, über die Benutzeroberfläche oder über eine API, um schließlich
automatisieren Sie den build - & deploy-Prozess.
Einem Artikel schrieb ich über dieses veröffentlicht wurde hier, Sie sind willkommen, es zu Lesen.