Staging-Datenbank missliche

Question

Nehmen wir an, dass es 3 Datenbanken für

• Produktion
• Staging
• Dev

Soweit ich weiß, Datenbank-Staging müssen synchron mit Produktionsdatenbank sein Aber,

Wenn wir entwickeln, können wir tun, was wir wollen mit Dev Datenbank und ändern Schema. Jetzt kommt das Huhn & Ei Problem.

in Staging Um zu testen, Staging Datenbankschema muß nach Änderungen in Dev-Datenbank vorgenommen werden geändert. Aber die Staging-Datenbank muß mit Produktion synchron sein.

Wie kann man Jungs, um dieses Problem?

Answer 1

Staging muss synchron mit der Produktion sein, nur bis zu dem Punkt, wo Sie neue Änderungen bereitstellen.

Das oder eine vierte Umgebung als Test bezeichnet machen, wo neuer Upgrades validiert werden. Wir nennen uns UAT / Test, und es ist in der Regel eine zweite Datenbank auf dem Staging-Server.

Genaue Methodik wird davon abhängen, wie Sie die Dinge synchron halten. Sind Sie tatsächlich die Replikation? Oder nur ein Backup / Restore von Prod auf der Bühne?

Answer 2

Sie müssen alle von Ihnen schreiben, ändert sich an die Entwickler-Datenbank als SQL-Migration-Skripte, die in einer bestimmten Reihenfolge ausführen lassen. Sie nicht die Datenbankstruktur ändern, es sei denn es ist in einem Skript. Nicht aktualisieren, einfügen oder alle Zeilen löschen, wenn es in einem Skript ist.

Im Idealfall eine Möglichkeit haben, zu verfolgen, welche Skripte haben gegen jede Version der Datenbank ausgeführt wurde Sie.

Dann können Sie Stufe wie folgt aktualisieren.

• Dump Produktionsdatenbank
• Bestücken Stufe Datenbank mit Produktions Dump
• Ausführen Migrationen in Stufe
• Überprüfen Sie die Migration gearbeitet (Unit-Tests, manuelle Kontrollen)

Wenn alles funktioniert ...

• Dump prod Datenbank mit mysqldump Befehl (wie es geändert hat) halte Sicherung auf dem Server
• Ausführen Migrationen auf prod
• Test Migration auf prod gearbeitet
• Getränk Bier (während Sie Fehlerprotokolle)

Answer 3

„Staging-Datenbank mit Produktion synchron sein muß“ Das stimmt nicht.

Produktionsschema ( "Design") ist synchron mit Staging-Schema. Staging kommt zuerst, Produktion folgt.

Manchmal bewegen Menschen Produktionsdaten bis auf Staging-Test zu helfen, aber das kann gefährlich sein, auf Ihrer Branche abhängig.

Staging ist "Pure".

Die Produktion wird, indem sie reale Daten in das reine Staging-Schema aus Staging gebaut.

Was einige Leute tun ist, zwei Datenbanken haben.

Heute # 1 ist die Produktion, # 2 ist die Inszenierung.

Morgen werden wir planen, eine Änderung des Schemas zu tun. Wir aktualisieren # 2 auf das neue Design. Dann gehen wir Daten von # 1 bis # 2.

Dann, wenn wir Daten fertig zu bewegen, schalten wir die Anwendungssoftware # 2 als Produktion zu verwenden.

Wir betreiben mit # 2, wie Produktion, bis es Zeit für die nächste Änderung ist.

Answer 4

Wir nutzen unsere Staging-Datenbank nur unseren Entfaltungsmechanismus zu testen. Es entspricht der Produktion.

Wir schaffen unsere Veränderungen in der Entwicklung und in regelmäßigen Abständen sie zu QA bereitstellen. Sobald wir bereit sind, die Produktion zu gehen, aggregieren wir alle Änderungen in einem Release-Paket. Das Release-Paket wird zunächst auf Staging getestet, und dann, wenn es keine Bereitstellungsprobleme sie der Produktion geschoben wird.

Answer 5

Wenn Sie sich leisten können, eine Prüfung env hinzufügen möchten, können Sie das betrachten.

Ansonsten müssen Sie im Grunde Ihre Prüfung in Ihrem dev env zu tun. bis zu einem Punkt, wo Sie sich sicher genug mit der Veröffentlichung sind, dass Sie die Schemaänderungen in der Staging env machen. Erstellen Sie regelmäßig Backups und hat ein gutes Roll-back-Verfahren so, dass, wenn etwas schief geht, wenn Sie die Schemaänderungen zu inszenieren drücken Sie immer Rollback können.

Auch ein gutes Werkzeug für Datenbankschema zu vergleichen ist SqlCompare . Sie sollten immer so etwas wie dieses verwenden, bevor Sie die Schemaänderungen drücken.