DB-Migration und Azure-Bereitstellungssteckplätze

Ich plane, eine neue Webanwendung auf einen Azure Web App-Dienst (ehemalige Azure-Website) zu übertragen. Ich möchte die Bereitstellungssteckplätze nutzen, um meine Bereitstellung zu testen, bevor sie in die Produktion übertragen wird. Das ist alles in Ordnung, solange keine Änderung des DB-Schemas erforderlich ist. Bei einer Schemaänderung können jedoch nicht zwei Softwareversionen auf derselben Datenbankversion ausgeführt werden. Da ich EF Migrations verwende, würde der Push auf den Staging-Slot sofort zu einem DB-Update auf die neueste Version führen.

Meine Frage ist also, ob Bereitstellungs-Slots verwendet werden, wenn eine DB-Migration erforderlich ist.

Wie geht das bei großen SaaS-Anbietern? Führen sie mit der neuen Version sofort eine DB-Migration durch? Das würde sicherlich zu Ausfallzeiten führen.

Ich kann mir nur ziemlich komplexe Lösungen für dieses Problem vorstellen. Gibt es etwas Einfaches?

— Sam7
quelle

Sie haben also keine Entwicklerdatenbank?

— JeffO

Ja, wir haben ein Entwicklungs- und Qualitätssicherungssystem. Das oben beschriebene System dient zu Produktionszwecken.

— Sam7

@ Sam7 hast du es geschafft, eine lösung für dieses problem zu finden? Prost

— WestDiscGolf

Ich fürchte nein. Wir testen derzeit Migrationsänderungen in einer separaten Umgebung.

— Sam7

@ Sam7: ich denke du kannst das durch eine separate .config-datei mit einer eigenen verbindungszeichenfolge zu deiner db verwalten. Aber Sie haben Recht, wenn Sie von der Phase bis zur Produktion bereitstellen, funktioniert der Vorteil eines Rollbacks nicht mehr. Die Datenbankänderungen werden sofort wirksam. Ich bin gespannt auf eine Lösung in naher Zukunft ...

— Roger S.

Antworten:

Ausfallsichere Releases mit Azure App Service-Slots und einer von Staging und Production gemeinsam genutzten Datenbank sind möglich. Sie müssen jedoch sicherstellen, dass alle Datenbankänderungen abwärtskompatibel sind, damit die aktuelle und die neue Version der Webanwendung gleichzeitig ausgeführt werden können die Staging- und Production-Slots.

Einige Regeln, die sicherstellen, dass dies funktioniert:

Alle neuen Datenbankspalten sollten nullfähig sein oder Standardwerte haben
Das Umbenennen von Spalten ist nicht zulässig
Das Löschen von Spalten ist nicht zulässig

Wenn Sie destruktive Änderungen vornehmen müssen, z. B. das Umbenennen oder Löschen von Spalten, benötigen Sie zwei Releases, um dies zu tun:

Die neue Version der Web-App sollte veröffentlicht werden, wodurch die Abhängigkeit von den umbenannten / gelöschten Spalten aufgehoben wird
Es wird eine zusätzliche Freigabe vorgenommen, die die destruktiven Änderungen vornimmt

Das klingt zwar etwas kompliziert, aber in der Praxis werden Sie wahrscheinlich nicht sehr oft destruktive Änderungen vornehmen.

— Cocowalla
quelle

Haben Sie sich die slotspezifischen Konfigurationselemente angesehen? Unter WebApp / Einstellungen / Anwendungseinstellungen können Sie Einstellungen für die Web-App vornehmen, aber auch festlegen, ob diese nur für diesen Slot gilt.

Sie können daher eine slotspezifische Verbindungszeichenfolge für Ihren Staging-Slot verwenden und die Migration auch auf das Austauschen von Slots anwenden.

— Owain Thomas
quelle

Das widerspricht meiner Vorstellung, dass die Staging-Site genau den gleichen Datensatz (-> Datenbank) wie die Produktion verwendet.

— Sam7