Wie können Bereitstellungen in Azure so eingerichtet werden, dass sie je nach Umgebung unterschiedliche Datenbanken verwenden?

Question

Sie können zwei Bereitstellungen im Azure-Verwaltungsportal ganz einfach zwischen Staging- und Produktionsumgebung austauschen, indem Sie deren VIPs austauschen. Wenn wir an einer Staging-Version der Dienste arbeiten, wollen wir auch eine Staging-Datenbank verwenden, um nicht zu riskieren, dass die aktuellen Kundendaten beschädigt werden. Nach dem Tausch von Staging- und Produktionsdiensten sollte die nun produktive (und ehemals Staging-) Bereitstellung natürlich mit der Produktionsdatenbank funktionieren.

Die zu verwendende Datenbank würde also im Wesentlichen davon abhängen, ob die Instanz in der Aufführung o Produktion Umwelt. Gibt es eine gute Möglichkeit, dies zu erreichen? Sich auf das VIP zu verlassen und die Umschaltung der Datenbank darauf basierend zu kodieren, ist wahrscheinlich nicht die beste Idee, denke ich.

Answer 1

Meine Empfehlung wäre, den "Staging Slot" eines Dienstes nicht mehr für die Funktion zu verwenden, für die Sie eine traditionelle "Staging-Umgebung" genutzt haben. Wenn ich mit Leuten über Windows Azure spreche, empfehle ich ihnen dringend, die Staging-Slots nur zu verwenden, um eine neue Bereitstellung zu testen, bevor sie live geht. Wenn sie langwierigere Tests durchführen wollen, wie sie viele von uns aus dem lokalen Umfeld gewohnt sind, sollten sie einen separaten Dienst und möglicherweise sogar ein separates Abonnement nutzen (letzteres ist ideal, wenn Sie Kostentransparenz wünschen).

Die einzige Möglichkeit ist, eine zweite, produktionsspezifische Dienstkonfiguration zu haben, die Sie aktualisieren, bevor Sie den VIP-Swap ausführen, oder Sie schreiben einen Code, der es dem Dienst ermöglicht, zu erkennen, in welchem Slot er sich befindet, und die entsprechende der beiden Konfigurationseinstellungen zu wählen.

Wie ich jedoch im ersten Absatz dargelegt habe, denke ich, dass es einen besseren Weg gibt, die Dinge zu tun :)

Answer 2

In einer neuen Version von Azure-Websites hat sich die Situation geändert. Sie können nun angeben, dass jede App-Einstellung oder jeder Verbindungsstring eine "Slot-Einstellung" ist, die an den jeweiligen Slot gebunden ist. Um Ihr Problem zu lösen, legen Sie einfach die Verbindungszeichenfolge(n) in jedem Slot fest und achten Sie darauf, "Slot-Einstellung" zu aktivieren.

Ich bin mir nicht mehr so sicher, ob dies ein ratsamer Ansatz ist. Datenbankschema Migration und Rollback sind nicht in gebacken, und ich bin unsicher, wie man das richtig zu behandeln. Außerdem funktionieren nur Anwendungseinstellungen und Verbindungszeichenfolgen auf diese Weise, so dass z. B. system.net.mail-Einstellungen nicht an einen Slot angeheftet werden können. Dafür müssten Sie den Code ändern, um Mailserverinformationen usw. aus den Anwendungseinstellungen zu erhalten, oder einen anderen Ansatz verwenden.

Answer 3

Re: "Wenn wir an einer Staging-Version der Dienste arbeiten, wollen wir auch eine Staging-Datenbank verwenden, um nicht zu riskieren, dass wir die tatsächlichen Kundendaten verderben." Es gibt keine eingebaute Möglichkeit, dies zu tun.

Wenn Sie ohne Risiko für die Produktionsdaten testen möchten, sollten Sie diese Tests in einem anderen Azure-Konto durchführen, das nicht einmal Zugriff auf die Produktionsdatenbank hat. Wenn Sie dann der Meinung sind, dass das System getestet und bereit ist, live zu gehen, bringen Sie es erst dann für einen abschließenden Smoke-Test in den Staging-Slot neben Ihrer Produktionsinstanz.

Ich kann mir auch Szenarien vorstellen, in denen man vor einem VIP-Swap einige Szenarien auf der Staging-Instanz durchspielen möchte, aber die Produktionsdaten nicht verunreinigen will. Zu diesem Zweck verwenden viele Unternehmen spezielle Konten - Daten, die mit diesen Konten verknüpft sind, sind bekannt (oder irgendwie gekennzeichnet), dass sie nicht von echten Kunden stammen, so dass sie in Berichten, Rechnungen usw. übergangen werden können.

Re: "Sich auf das VIP zu verlassen und die Datenbankumschaltung darauf basierend zu kodieren, ist wahrscheinlich nicht die beste Idee, denke ich." Wenn Sie mit "hard-coding" das Auslesen aus einer Konfigurationsdatei meinen, ist das wahrscheinlich keine schlechte Idee, wenn Sie einen Ansatz wie oben beschrieben verwenden. Ich habe von einigen Leuten gehört, die mit einem "Finde heraus, ob wir uns in einem Staging Slot befinden und mach etwas anderes im Code" Ansatz arbeiten, aber ich empfehle eher das, was ich oben beschrieben habe.