Best Practices für die Verwaltung von Migrationen, die mehrere Datenbanken aktualisieren?

Question

Mein Team evaluiert Tools und Prozesse für die Verwaltung von Datenbankmigrationen/Datenbank-Refactoring, wie von Martin Fowler, Pramod Sadalage et. al. Wir sind an automatisierten, wiederholbaren, testbaren Prozessen interessiert, daher sind wir nicht daran interessiert, SQL Compare bei jeder Bereitstellung manuell auszuführen. Zurzeit verwenden wir CruiseControl.NET für die kontinuierliche Integration.

Unsere Produktionsumgebung verfügt über mehrere SQL Server 2000-Datenbankserver mit Replikation zwischen ihnen. Unsere Migrationen werden daher Änderungen am Schema sowohl auf dem Quell- als auch auf dem Zieldatenbankserver vornehmen.

Um eine solche Migration mit einem Tool wie dbdeploy durchzuführen, müssen wir anscheinend die Migration auf einen der Server durchführen und die anderen Server als verbundene Server hinzufügen. Ein einzelnes Skript, das auf dem Hauptserver ausgeführt wird, könnte daher DDL für einen der verbundenen Server ausführen.

Meine Frage ist: Würde dieser Ansatz als Best Practice angesehen, oder gibt es eine bessere Technik für die Anwendung von Migrationen, die mehrere Datenbankserver betreffen?

Answer 1

Ich sehe nichts inhärent falsch mit diesem Ansatz, aber bei der Einrichtung sollten Sie unbedingt testen, was passiert, wenn einer der verbundenen Server ausfällt. Sie möchten nicht alle anderen Server zurücksetzen, wenn einer ausgefallen ist und Sie wissen möchten, dass die Änderungen nicht auf diesen Server angewendet wurden.

Natürlich ist die erste, wichtigste Best Practice für jede Migration, sicherzustellen, dass Sie einen soliden Sicherungsprozess haben, bevor Sie mit der Migration von Änderungen beginnen.

Answer 2

Visual Studio 2008 (Team Edition, speziell GDR) kann die automatisierte Bereitstellung von Schemas gegen definierte Schema-/Metadatendateien verarbeiten, die Sie auf Servern bereitstellen können. Dies könnte in Ihrem Build/Deploy-Prozess enthalten sein. Ich denke jedoch, dass es immer noch ein Problem bei Replikations- und Schemaänderungen gibt - es gibt kein Paket, das Ihre Replikationskonfiguration versteht/kennt.

Zum Beispiel verwenden wir benutzerdefinierte Replikationsprozeduren für den Abonnenten und obwohl Schemaänderungen vom Publisher propagiert werden, müssen wir manchmal manuell Skriptänderungen vornehmen, abhängig von einer benutzerdefinierten Replikation, die wir implementiert haben. Wenn Sie keine benutzerdefinierten Replikationsprozesse verwenden, würde ich sagen, dass dies der richtige Weg ist.

Answer 3

Sie können eine Kombination aus Chinchillin und Wizardby ausprobieren: Installieren Sie Chinchillin-Agenten auf DB-Servern und führen Sie Wizardby-Migrationsskripte während des Bereitstellungsprozesses aus.

Diese Integration ist in Arbeit, aber :)

Answer 4

Hier bei Red Gate wir haben jetzt eine wiederholbare Migrationen Lösung erhielt, die SQL Compare und SQL Source Control verwendet. Die SQL Compare-Befehlszeile kann daher zur Unterstützung eines kontinuierlichen Integrationsprozesses verwendet werden.

http://www.red-gate.com/MessageBoard/viewtopic.php?t=14107

Es ist derzeit ein früher Zugang zu bauen, so dass wir daran interessiert, so viel Feedback wie möglich zu erhalten.