Bereitstellen von SQL Server-Datenbanken vom Test zum Live-Betrieb

08-06-2019
|

Frage

Ich frage mich, wie ihr die Bereitstellung einer Datenbank zwischen zwei SQL Servern, insbesondere SQL Server 2005, verwaltet.Nun gibt es eine Entwicklung und eine lebendige.Da dies Teil eines Buildskripts sein sollte (Standard-Windows-Batch, selbst bei der aktuellen Komplexität dieser Skripte würde ich möglicherweise später auf PowerShell oder ähnliches umsteigen), zählen Enterprise Manager/Management Studio Express nicht.

Würden Sie einfach die .mdf-Datei kopieren und anhängen?Ich bin bei der Arbeit mit Binärdaten immer etwas vorsichtig, da dies ein Kompatibilitätsproblem zu sein scheint (auch wenn in der Entwicklung und in der Live-Version stets dieselbe Version des Servers ausgeführt werden sollte).

Oder führen Sie – angesichts des Fehlens von „EXPLAIN CREATE TABLE“ in T-SQL – etwas aus, das eine vorhandene Datenbank in SQL-Skripte exportiert, die Sie auf dem Zielserver ausführen können?Wenn ja, gibt es ein Tool, das eine bestimmte Datenbank automatisch in SQL-Abfragen speichern kann und über die Befehlszeile ausgeführt wird?(Auch hier zählen Enterprise Manager/Management Studio Express nicht).

Und schließlich: Angesichts der Tatsache, dass die Live-Datenbank bereits Daten enthält, umfasst die Bereitstellung möglicherweise nicht die Erstellung aller Tabellen, sondern vielmehr die Überprüfung der Unterschiede in der Struktur und ALTER TABLE stattdessen die Live-Tabellen, was möglicherweise auch eine Datenüberprüfung/-konvertierung erfordert, wenn sich vorhandene Felder ändern.

Jetzt höre ich viel Tolles darüber Rotes Tor Produkte, aber für Hobbyprojekte ist der Preis etwas hoch.

Was verwenden Sie also, um SQL Server-Datenbanken automatisch von Test zu Live bereitzustellen?

Lösung

Ich bin dazu übergegangen, alle meine DDL-Anweisungen (Erstellen/Ändern/Löschen) von Hand zu codieren, sie als Textdateien zu meiner .sln-Datei hinzuzufügen und die normale Versionierung zu verwenden (unter Verwendung von Subversion, aber jede Revisionskontrolle sollte funktionieren).Auf diese Weise profitiere ich nicht nur von der Versionierung, sondern die Live-Aktualisierung von Dev/Stage ist für Code und Datenbank der gleiche Prozess – Tags, Branches usw. funktionieren alle gleich.

Ansonsten stimme ich zu, dass Redgate teuer ist, wenn es kein Unternehmen für Sie kauft.Wenn Sie jedoch ein Unternehmen dazu bringen können, es für Sie zu kaufen, lohnt es sich wirklich!

Andere Tipps

Für meine Projekte wechsle ich zwischen SQL Compare von REd Gate und dem Database Publishing Wizard von Microsoft, den Sie kostenlos herunterladen könnenHier.

Der Assistent ist nicht so ausgefeilt wie SQL Compare oder SQL Data Compare, erfüllt aber seinen Zweck.Ein Problem besteht darin, dass die generierten Skripte möglicherweise neu angeordnet und/oder bearbeitet werden müssen, damit sie in einem Durchgang ablaufen.

Auf der anderen Seite kann es Ihr Schema und Ihre Daten verschieben, was für ein kostenloses Tool nicht schlecht ist.

Vergessen Sie nicht die Lösung von Microsoft für das Problem: Visual Studio 2008 Datenbank-Edition.Enthält Tools zum Bereitstellen von Änderungen an Datenbanken, zum Erstellen eines Unterschieds zwischen Datenbanken für Schema- und/oder Datenänderungen, Komponententests und Testdatengenerierung.

Es ist ziemlich teuer, aber ich habe die Testversion eine Zeit lang genutzt und fand sie brillant.Dadurch ist die Arbeit mit der Datenbank genauso einfach wie mit jedem anderen Code.

Wie Rob Allen verwende ich SQL Compare / Data Compare von Redgate.Ich verwende auch den Datenbankveröffentlichungsassistenten von Microsoft.Ich habe auch eine Konsolen-App, die ich in C# geschrieben habe und die ein SQL-Skript auf einem Server ausführt.Auf diese Weise können Sie große Skripte mit „GO“-Befehlen über eine Befehlszeile oder in einem Batch-Skript ausführen.

Ich verwende die Bibliotheken Microsoft.SqlServer.BatchParser.dll und Microsoft.SqlServer.ConnectionInfo.dll in der Konsolenanwendung.

Ich arbeite genauso wie Karl, indem ich alle meine SQL-Skripte zum Erstellen und Ändern von Tabellen in einer Textdatei behalte, die ich in der Quellcodeverwaltung behalte.Um das Problem zu vermeiden, dass ein Skript die Live-Datenbank untersuchen muss, um zu bestimmen, welche ALTERs ausgeführt werden sollen, gehe ich normalerweise so vor:

Bei der ersten Version platziere ich beim Testen alles in einem SQL-Skript und behandle alle Tabellen als CREATE.Das bedeutet, dass ich während des Testens oft Tabellen lösche und lese, aber das ist zu Beginn des Projekts keine große Sache (da ich normalerweise sowieso die Daten hacke, die ich zu diesem Zeitpunkt verwende).
Bei allen nachfolgenden Versionen mache ich zwei Dinge:Ich erstelle eine neue Textdatei für die Upgrade-SQL-Skripts, die nur die ALTERs für diese Version enthalten.Und ich nehme die Änderungen am Original vor und erstelle außerdem ein neues Datenbankskript.Auf diese Weise führt ein Upgrade lediglich das Upgrade-Skript aus, aber wenn wir die Datenbank neu erstellen müssen, müssen wir nicht 100 Skripte ausführen, um dorthin zu gelangen.
Abhängig davon, wie ich die DB-Änderungen bereitstelle, füge ich normalerweise auch eine Versionstabelle in die DB ein, die die Version der DB enthält.Anstatt dann menschliche Entscheidungen darüber zu treffen, welche Skripte ausgeführt werden sollen, verwendet der Code, den ich zum Ausführen der Erstellungs-/Upgrade-Skripts verwende, die Version, um zu bestimmen, was ausgeführt werden soll.

Das Einzige, was das nicht bringt, ist, dass es Ihnen nicht hilft, wenn ein Teil dessen, was Sie vom Test in die Produktion verlagern, Daten sind, aber wenn Sie die Struktur verwalten und nicht für ein schönes, aber teures DB-Verwaltungspaket bezahlen möchten, ist das wirklich nicht sehr schwierig.Ich habe auch festgestellt, dass es eine ziemlich gute Möglichkeit ist, den Überblick über die Datenbank zu behalten.

Wenn Sie es von einem Unternehmen kaufen lassen, verfügt Toad von Quest Software über eine integrierte Verwaltungsfunktionalität dieser Art.Im Grunde ist es ein Zwei-Klick-Vorgang, um zwei Schemata zu vergleichen und ein Synchronisierungsskript von einem zum anderen zu generieren.

Sie haben Editionen für die meisten gängigen Datenbanken, darunter natürlich auch SQL Server.

Ich stimme zu, dass die Erstellung von Skripten der beste Weg ist und das ist, was ich bei der Arbeit befürworte.Sie sollten alles skripten, von der Datenbank- und Objekterstellung bis hin zum Auffüllen Ihrer Nachschlagetabellen.

Alles, was Sie nur in der Benutzeroberfläche tun, wird nicht übersetzt (insbesondere bei Änderungen ...(nicht so sehr für Erstbereitstellungen) und wird am Ende ein Tool benötigen, wie es Redgate anbietet.

Mit SMO/DMO ist es nicht allzu schwierig, ein Skript Ihres Schemas zu generieren.Daten machen etwas mehr Spaß, sind aber immer noch machbar.

Im Allgemeinen verfolge ich den „Script It“-Ansatz, aber vielleicht möchten Sie etwas in dieser Richtung in Betracht ziehen:

Unterscheiden Sie zwischen Entwicklung und Staging, sodass Sie mit einer Teilmenge von Daten entwickeln können ...Dazu würde ich ein Tool erstellen, um einfach einige Produktionsdaten abzurufen oder gefälschte Daten zu generieren, wenn es um die Sicherheit geht.
Für die Teamentwicklung muss jede Änderung an der Datenbank zwischen Ihren Teammitgliedern koordiniert werden.Schema- und Datenänderungen können miteinander vermischt werden, aber ein einzelnes Skript sollte eine bestimmte Funktion ermöglichen.Sobald alle Ihre Funktionen bereit sind, bündeln Sie diese in einer einzigen SQL-Datei und führen diese für eine Wiederherstellung der Produktion aus.
Sobald Ihr Staging die Freigabe erhalten hat, führen Sie die einzelne SQL-Datei erneut auf dem Produktionscomputer aus.

Ich habe die Red Gate-Tools verwendet und sie sind es Großartig Werkzeuge, aber wenn Sie es sich nicht leisten können, ist es nicht allzu weit vom Ideal entfernt, die Werkzeuge zu bauen und auf diese Weise zu arbeiten.

Ich verwende den Migrationsmechanismus von Subsonic, also habe ich nur eine DLL mit Klassen in sequenzieller Reihenfolge, die zwei Methoden haben, nach oben und nach unten.Es gibt einen kontinuierlichen Integrations-/Build-Skript-Hook in Nant, sodass ich die Aktualisierung meiner Datenbank automatisieren kann.

Es ist nicht das beste DDL der Welt, aber es übertrifft das Schreiben von DDL.

RedGate SqlCompare ist meiner Meinung nach ein guter Weg.Wir führen regelmäßig DB-Bereitstellungen durch, und seit ich dieses Tool verwende, habe ich nie mehr zurückgeschaut.Sehr intuitive Benutzeroberfläche und spart am Ende viel Zeit.

Die Pro-Version übernimmt auch die Skripterstellung für die Integration der Quellcodeverwaltung.

Außerdem pflege ich Skripte für alle meine Objekte und Daten.Für die Bereitstellung habe ich dieses kostenlose Dienstprogramm geschrieben: http://www.sqldart.com.Damit können Sie Ihre Skriptdateien neu anordnen und alles innerhalb einer Transaktion ausführen.

Ich bin damit einverstanden, alles in der Quellcodeverwaltung zu belassen und alle Änderungen manuell zu skripten.Änderungen am Schema für eine einzelne Version werden in eine Skriptdatei übernommen, die speziell für diese Version erstellt wurde.Alle gespeicherten Prozesse, Ansichten usw. sollten in einzelnen Dateien gespeichert und hinsichtlich der Quellcodeverwaltung genauso wie .cs oder .aspx behandelt werden.Ich verwende ein Powershell-Skript, um eine große SQL-Datei zum Aktualisieren der Programmierbarkeit zu generieren.

Ich mag es nicht, die Anwendung von Schemaänderungen wie neuen Tabellen, neuen Spalten usw. zu automatisieren.Wenn ich eine Produktionsversion erstelle, gehe ich das Änderungsskript gerne Befehl für Befehl durch, um sicherzustellen, dass jedes einzelne wie erwartet funktioniert.Es gibt nichts Schlimmeres, als ein großes Änderungsskript für die Produktion auszuführen und Fehler zu bekommen, weil man ein kleines Detail vergessen hat, das in der Entwicklung nicht aufgefallen ist.

Ich habe auch gelernt, dass Indizes genau wie Codedateien behandelt und in die Quellcodeverwaltung übernommen werden müssen.

Und Sie sollten auf jeden Fall mehr als zwei Datenbanken haben – Dev und Live.Sie sollten über eine Entwicklungsdatenbank verfügen, die jeder für tägliche Entwicklungsaufgaben nutzt.Dann eine Staging-Datenbank, die die Produktion nachahmt und für die Durchführung Ihrer Integrationstests verwendet wird.Dann vielleicht eine vollständige aktuelle Kopie der Produktion (aus einem Voll-Backup wiederhergestellt), wenn das machbar ist, damit Ihre letzte Runde der Installationstests etwas angeht, das der Realität so nahe wie möglich kommt.

Ich erstelle meine gesamte Datenbank als DDL und binde diese DDL dann in eine Schemawartungsklasse ein.Ich kann zunächst verschiedene Dinge tun, um die DDL zu erstellen, aber grundsätzlich übernehme ich die gesamte Schemapflege im Code.Dies bedeutet auch, dass Sie prozedurale Logik schreiben und diese zwischen DDL/DML-Klumpen ausführen können, wenn Sie Nicht-DDL-Dinge ausführen müssen, die sich nicht gut mit SQL abbilden lassen.

Meine Datenbanken verfügen dann über eine Tabelle, die die aktuelle Version definiert, sodass man eine relativ einfache Reihe von Tests programmieren kann:

Existiert die DB?Wenn nicht, erstellen Sie es.
Ist die DB die aktuelle Version?Wenn nicht, führen Sie nacheinander die Methoden aus, die das Schema auf den neuesten Stand bringen (möglicherweise möchten Sie den Benutzer an dieser Stelle zur Bestätigung auffordern und – idealerweise – Sicherungen durchführen).

Bei einer Einzelbenutzer-App führe ich dies einfach vor Ort aus. Bei einer Web-App sperren wir derzeit den Benutzer aus, wenn die Versionen nicht übereinstimmen, und führen eine eigenständige Schema-Wartungs-App aus.Bei Mehrbenutzern hängt es von der jeweiligen Umgebung ab.

Der Vorteil?Nun, ich habe ein sehr hohes Maß an Vertrauen, dass das Schema für die Apps, die diese Methodik verwenden, in allen Instanzen dieser Anwendungen konsistent ist.Es ist nicht perfekt, es gibt Probleme, aber es funktioniert ...

Es gibt einige Probleme bei der Entwicklung in einer Teamumgebung, aber das ist sowieso mehr oder weniger eine Selbstverständlichkeit!

Murph

Ich arbeite derzeit mit Ihnen an der gleichen Sache.Sie stellen nicht nur SQL Server-Datenbanken vom Test bis zur Live-Phase bereit, sondern umfassen auch den gesamten Prozess von Lokal -> Integration -> Test -> Produktion.Was mir also jeden Tag leicht fallen kann, ist, dass ich es tue NAnt-Aufgabe mit Red-Gate SQL Compare.Ich arbeite nicht für RedGate, aber ich muss sagen, dass es eine gute Wahl ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow