Checkliste für Datenbankschema-Upgrades

Question

Das Aktualisieren eines Datenbankschemas macht die Installation einer neuen Softwareversion viel schwieriger.Was sind die besten Vorgehensweisen hierfür?

Ich suche eine Checkliste oder einen Zeitplan mit Aktionspunkten, z

• 8:30 Uhr Apps herunterfahren
• 8:45 Schema ändern
• 9:15 Neue Apps installieren
• 9:30 Datenbank neu starten

usw. und zeigen, wie sich Risiken und Ausfallzeiten minimieren lassen.Themen wie

• Zurückziehen des Upgrades, wenn etwas schief geht
• Minimierung der Auswirkungen auf bestehende Apps
• „Hot“-Updates, während die Datenbank läuft
• Förderung von Entwicklungs- über Test- bis hin zu Produktionsservern

sind besonders von Interesse.

Answer 1

Ich habe viel Erfahrung damit.Meine Anwendung ist stark iterativ und Schemaänderungen kommen häufig vor.Ich mache ungefähr alle 2 bis 3 Wochen eine Produktionsfreigabe, wobei für jede 50–100 Elemente aus meiner FogBugz-Liste gelöscht werden.Bei jeder Veröffentlichung, die wir in den letzten Jahren herausgebracht haben, waren Schemaänderungen erforderlich, um neue Funktionen zu unterstützen.

Der Schlüssel dazu besteht darin, die Änderungen mehrmals in einer Testumgebung zu üben, bevor sie tatsächlich auf den Live-Servern vorgenommen werden.

Ich führe eine Bereitstellungs-Checklistendatei, die aus einer Vorlage kopiert und dann für jede Version stark bearbeitet wird, mit allem, was ungewöhnlich ist.

Ich habe zwei Skripte, die ich in der Datenbank ausführe, eines für Schemaänderungen und eines für die Programmierbarkeit (Prozeduren, Ansichten usw.).Das Änderungsskript wird von Hand codiert und das mit den Prozessen wird über Powershell geschrieben.Das Änderungsskript wird ausgeführt, wenn alles ausgeschaltet ist (Sie müssen hierfür einen Zeitpunkt auswählen, der die wenigsten Benutzer stört), und es wird Befehl für Befehl manuell ausgeführt, nur für den Fall, dass etwas schief geht.Das häufigste Problem, auf das ich gestoßen bin, ist das Hinzufügen einer eindeutigen Einschränkung, die aufgrund doppelter Zeilen fehlschlägt.

Wenn ich mich auf einen Integrationstestzyklus vorbereite, gehe ich meine Checkliste auf einem Testserver durch, als wäre dieser Server ein Produktionsserver.Dann besorge ich mir zusätzlich eine tatsächliche Kopie der Produktionsdatenbank (dies ist ein guter Zeitpunkt, um Ihre Offsite-Backups auszutauschen) und führe die Skripte auf einer wiederhergestellten lokalen Version aus (was auch gut ist, weil es meine Qualität beweist). (das letzte Backup ist einwandfrei).Ich schlage hier viele Fliegen mit einer Klappe.

Das sind also insgesamt 4 Datenbanken:

1. Entwickler:Alle Änderungen müssen im Änderungsskript vorgenommen werden, niemals mit Studio.
2. Prüfen:Hier finden Integrationstests statt
3. Kopie der Produktion:Last-Minute-Bereitstellungspraxis
4. Produktion

Man muss es wirklich, wirklich richtig machen, wenn man es in der Produktion macht.Das Zurücksetzen von Schemaänderungen ist schwierig.

Was Hotfixes betrifft, werde ich immer nur Hotfix-Prozeduren durchführen, niemals Schemata, es sei denn, es handelt sich um eine sehr isolierte Änderung, die für das Unternehmen von entscheidender Bedeutung ist.

Answer 2

Ich nehme an, Sie haben sich die Lektüre von Scott Ambler angesehen?http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

Das ist ein Thema, über das ich gerade bei der Arbeit gesprochen habe.Das Problem besteht hauptsächlich darin, dass die Datenbankmigrationen Ihnen überlassen bleiben, es sei denn, Ihr Framework, z. B. Rails und deren Migrationsskripte, erledigt dies reibungslos für Sie.

Die derzeitige Art und Weise, wie wir es tun, weist offensichtliche Mängel auf, und ich bin offen für andere Vorschläge.

1. Halten Sie einen Schema-Dump mit statischen Daten bereit, die aktuell und in Versionskontrolle gehalten werden müssen.
2. Jedes Mal, wenn Sie eine Schemaänderungsaktion ausführen, ALTER, CREATE usw.Speichern Sie es in einer Datei und werfen Sie es in die Versionskontrolle.
3. Stellen Sie sicher, dass Sie den ursprünglichen SQL-Datenbank-Dump aktualisieren.
4. Wenn Sie Push-to-Live durchführen, stellen Sie sicher, dass Sie oder Ihr Skript die SQL-Dateien auf die Datenbank anwenden.
5. Bereinigen Sie alte SQL-Dateien, die sich in der Versionskontrolle befinden, wenn sie alt werden.

Dies ist keineswegs optimal und eigentlich nicht als „Backup“-Datenbank gedacht.Es geht einfach darum, das Leben leichter zu machen und die Entwickler auf dem gleichen Stand zu halten.Es gibt wahrscheinlich etwas Cooles, das Sie mit Capistrano einrichten könnten, um die Anwendung der SQL-Dateien auf die Datenbank zu automatisieren.

Eine DB-spezifische Versionskontrolle wäre ziemlich großartig.Es gibt wahrscheinlich etwas, das das tut, und wenn nicht, sollte es wahrscheinlich eines geben.

Answer 4

Und wenn der Artikel von Scott Ambler Ihren Appetit anregt, kann ich sein Buch mit Pramod J Sadolage mit dem Titel „Refactoring Databases“ empfehlen – http://www.ambysoft.com/books/refactoringDatabases.html

Viele nützliche Ratschläge und Informationen gibt es auch in der Agile Database-Gruppe bei Yahoo – http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

Zwei kurze Anmerkungen:

1. Es versteht sich von selbst...Also sage ich es zweimal.
   Stellen Sie sicher, dass Sie über ein gültiges Backup verfügen.
   Stellen Sie sicher, dass Sie über ein gültiges Backup verfügen.

2. @mk.Kasse Jeffs Blogbeitrag zur Datenbankversionskontrolle (falls Sie dies noch nicht getan haben)