Wie füge ich Schemaänderungen, die an einer Produktionsdatenbank vorgenommen wurden, in meinen von der Migration verwalteten Prozess ein?

Question

Mein Team evaluiert dbdeploy für die Verwaltung von Datenbankmigrationen. Nach meinem Verständnis erfordert die Verwendung von Migrationen ein gewisses Maß an Prozessdisziplin, nämlich dass für jede Änderung eine Migration geschrieben wird und dass die Migration von der lokalen zur Entwicklungsphase erfolgen muss, um die Produktion zu testen.

Gelegentlich führt unser DBA-Produktionsteam Schemaänderungen direkt in der Produktionsumgebung durch. Wenn wir eine neue Migration schreiben, um die Änderung gegenüber unserer aktuellen Entwicklungsversion der Datenbank vorzunehmen, wird diese Migration niemals gegen ein Schema getestet, das die Änderung bereits enthält, bis die Migration für die Produktion bereitgestellt wird. Das geht mich an.

Die andere Möglichkeit besteht darin, die Änderung direkt in das Baseline-Schema zu übernehmen und dann die Datenbank in allen Umgebungen (lokal, Entwicklung, Test, Phase) neu aufzubauen. Dieser Ansatz betrifft mich, da das neue Schema dazu führen kann, dass eine oder mehrere Migrationen unterbrochen werden.

Wie gehen die Leute derzeit mit diesem Szenario um?

Answer 1

Es ist verständlich, dass DB-Änderungen am Produktionsschema von Zeit zu Zeit passieren müssen. Es ist jedoch sehr wichtig, dass diese so schnell wie möglich dokumentiert und dem Entwicklungsteam mitgeteilt werden müssen. Klartext mit der sql zusammen mit Kommentaren zu betroffenen Use Cases/Funktionalitäten und mögliche Bug-Tracking-Probleme würde

Holen der Live-DB zurück zur Entwicklung hin und wieder und vergleichen es (es ist Schema) mit dem, was die Entwickler haben ist auch eine gute Idee.

Answer 2

Ich nehme an, dass das einzige, was DBA in der Produktions-DB ändern kann, ist, hier und da einen Index hinzuzufügen und ein paar Sprocs zu optimieren - alles aus Gründen der Leistung. Alle anderen Änderungen an der DB können das DB-Schema im Allgemeinen dazu bringen, dass es mit der Anwendung inkompatibel ist.

In diesem Sinne sollten sprocs nur versioniert werden, und es liegt in der Verantwortung eines DBA, sie in die Quellcodeverwaltung zu überführen. Indizes sind viel flüchtiger und möglicherweise nicht in Migrationsskripten enthalten.

Answer 3

Wir stellen über Nacht eine Kopie unserer Produktionsdatenbank auf einem Testserver wieder her.

Dieses dient dann:

• Als Referenzkopie (Code und Daten)
• Wir alle Änderungen zurücksetzen können wir gemacht haben
• Wir gegen echten Daten testen können
• können wir Seite Nebenseite neuer/alter Code preformance
• Wir können 100% sichere Change/Rollback Skripte (Red Gate)

erzeugen

Wir bauen keine Dev/Test-Datenbanken usw. auf, aber einige unserer anderen Projekte tun es. Ich bin mir jedoch nicht sicher, ob eine Datenbank nicht Schema und Code ist, sondern auch Daten. Es ist anders als eine entsprechende .net App.

In meinem Geschäft würde ein Produktions-DBA, der Änderungen an einer Produktdatenbank (irgendeine Änderung überhaupt) ohne Genehmigung vornimmt, gefeuert. Und es ist passiert.