Was sind Bereitstellungsmuster?
Ein Bereitstellungsmuster ist eine automatisierte Methode, um ein Rollout neuer Anwendungsfeatures für Ihre Benutzer reibungslos auszuführen. Ein geeignetes Bereitstellungsmuster hilft Ihnen, die Downtime zu minimieren. Einige Muster ermöglichen es Ihnen auch, den Rollout neuer Features schrittweise auszuführen. Auf diese Weise können Sie neue Features mit ausgewählten Benutzern überprüfen, bevor Sie diese Features für alle verfügbar machen.
In diesem Abschnitt lernen Sie einige gängige Bereitstellungsmuster kennen. Außerdem erfahren Sie, wie Azure App Service bei der Implementierung des Musters hilft, das vom Tailspin-Team ausgewählt wurde.
Morgenbesprechung
Das Tailspin-Team hat ein gutes Gefühl. Ihre Pipeline hat ihren Prozess beschleunigt. Das Team verfügt über eine Entwicklungsumgebung, in der sie die Web-App mit einer Datenbank integrieren können. Sowohl Tim als auch Amita sind froh, über automatisierte Tests zu verfügen, die ihnen die Arbeit erleichtern. Im Allgemeinen sind weniger Verzögerungen und weniger Fehler ersichtlich.
Aber es gibt, wie immer, ein Problem. Schauen wir bei der Teambesprechung vorbei, in der Tim spricht.
Tim: Es ist so schwer, alle zufrieden zu stellen. Irwin findet, dass es zu lange dauert, neue Features freizugeben. Ich kann nichts unternehmen, bis das Management das Release genehmigt hat, und im Moment gibt es keine reibungslose Möglichkeit, ein Rollout der Features auszuführen, nachdem sie dem Vorgang zugestimmt haben. Der Prozess ist nicht nur langwierig, sondern auch chaotisch. Er wird manuell durchgeführt und es gibt Downtimes. Der gesamte Vorgang kann fünf Tage dauern. Ich weiß, dass das zu lang ist, aber was soll ich tun? Vielleicht habe ich eine Eingebung, wenn ich einfach mehr Kaffee trinke.
Andy: Kaffee ist zur effektiven Problemlösung unerlässlich, kein Zweifel.
Ich denke, ein gutes Bereitstellungsmuster ist die Lösung, nach der wir suchen. Ein Bereitstellungsmuster ist ein automatisierter Weg, um die Übernahme durchzuführen. Auf diese Weise bringen wir die Software von der letzten Vorproduktionsphase in die Liveproduktionsumgebung.
Die Wahl des richtigen Musters würde Ihnen auf jeden Fall helfen, z. B. durch Minimierung der Downtime. Ein weiterer Vorteil eines Bereitstellungsmusters ist, dass es uns die Möglichkeit gibt, Tests auszuführen, die wirklich in der Produktionsumgebung stattfinden sollen.
Andy schreibt auf das Whiteboard.
Hier sind die Möglichkeiten, die wir in Betracht ziehen sollten:
- Blaugrün-Bereitstellung
- Canary-Releases
- Feature Toggles
- Dunkle Starts
- A/B-Tests
- Bereitstellung mit progressiver Exposition
Lassen Sie uns die einzelnen Muster kurz besprechen.
Blaugrün-Bereitstellungen
Eine Blau-Grün-Bereitstellung reduziert Risiken und Downtimes durch den Betrieb von zwei identischen Umgebungen. Diese Umgebungen werden als Blau und Grün bezeichnet. Nur eine der Umgebungen befindet sich hierbei immer im Livezustand. Eine Blau-Grün-Bereitstellung umfasst in der Regel einen Router oder Lastenausgleich, der hilft, den Datenverkehrsfluss zu steuern.
Nehmen wir an, die blaue Umgebung ist live. Wenn wir ein neues Release vorbereiten, führen wir unsere letzten Tests in der grünen Umgebung durch. Nachdem die Software in der grünen Umgebung arbeitet, schalten wir einfach den Router so um, dass alle eingehenden Anforderungen an die grüne Umgebung geleitet werden.
Die Blau-Grün-Bereitstellung bietet uns auch eine schnelle Möglichkeit, ein Rollback durchzuführen. Wenn in der grünen Umgebung etwas schief geht, dann schalten wir den Router einfach zurück auf die blaue Umgebung.
Canary-Releases
Ein Canary-Release ist eine Möglichkeit, potenzielle Probleme frühzeitig zu erkennen, ohne alle Benutzer dem Problem auszusetzen. Die Idee ist, dass wir ein neues Feature nur einer kleinen Teilmenge von Benutzern zur Verfügung stellen, bevor wir es für alle verfügbar machen.
Bei einem Canary-Release überwachen wir die Abläufe, wenn wir das Feature freigeben. Wenn das Release Probleme verursacht, wenden wir eine Korrektur an. Nachdem sich das Canary-Release als stabil erwiesen hat, übernehmen wir es in die eigentliche Produktionsumgebung.
Feature Toggles
Verwenden Sie Feature Toggles, um zur Laufzeit einen „Schalter umzulegen“. Wir können neue Software bereitstellen, ohne andere neue oder geänderte Funktionen für unsere Benutzer verfügbar zu machen.
Bei diesem Bereitstellungsmuster werden von Mara und mir neue Features hinter einem Feature Toggle erstellt. Bei einem Release ist die Funktion deaktiviert, sodass sie keinen Einfluss auf die Produktionssoftware hat. Je nachdem, wie wir den Toggle konfigurieren, können wir ihn aktivieren und das Feature wie gewünscht verfügbar machen.
Beispielsweise könnten wir das Feature zuerst ein paar Benutzer*innen zur Verfügung stellen, um deren Reaktion zu prüfen. Dieser zufälligen Stichprobe von Benutzern wird das Feature zur Verfügung gestellt. Oder wir können das Feature einfach für alle Benutzer in der Liveumgebung aktivieren.
Aber dieses Bereitstellungsmuster könnte Mara und mir mehr nützen als allen anderen. Ein großer Vorteil des Feature Toggle-Musters ist, dass es uns hilft, zu viele Branches zu vermeiden. Das Zusammenführen von Branches kann mühsam sein.
Dunkle Starts
Ein dunkler Start ist vergleichbar mit einem Canary-Release oder dem Umschalten eines Feature Toggles. Anstatt ein neues Feature für alle Benutzer verfügbar zu machen, geben wir das Feature bei einem dunklen Start für eine kleine Gruppe von Benutzern frei.
Diese Benutzer wissen nicht, dass Sie das Feature für uns testen. Wir weisen sie nicht einmal auf das neue Feature hin. Aus diesem Grund wird es als „dunkler Start“ bezeichnet. Die Software wird schrittweise oder unbemerkt für die Benutzer freigegeben, damit wir Feedback erhalten und die Leistung testen können.
A/B-Tests
A/B-Tests vergleichen zwei Versionen einer Webseite oder App, um festzustellen, welche davon besser abschneidet. A/B-Tests sind wie ein klassisches Experiment.
Bei A/B-Tests zeigen wir Benutzern nach dem Zufallsprinzip zwei oder mehr Variationen einer Seite an. Anschließend verwenden wir statistische Analysen, um zu entscheiden, welche Variation für unsere Ziele besser geeignet ist.
Bereitstellung mit progressiver Exposition
Eine Bereitstellung mit progressiver Exposition wird manchmal als ringbasierte Bereitstellung bezeichnet. Dies ist eine weitere Möglichkeit, die Auswirkungen von Änderungen auf die Benutzer*innen zu begrenzen und gleichzeitig sicherzustellen, dass diese Änderungen in einer Produktionsumgebung gültig sind.
Ringe sind im Grunde eine Erweiterung der Canary-Stage. Das Canary-Release wird zu einer Stage veröffentlicht, um den Effekt zu messen. Das Hinzufügen eines weiteren Rings ist im Wesentlichen das gleiche Konzept.
In a ring-based deployment, we deploy changes to risk-tolerant customers first.Bei einer ringbasierten Bereitstellung werden Änderungen zuerst bei risikofreudigen Kunden bereitgestellt. Dann erfolgt schrittweise der Rollout für eine größere Anzahl von Kunden.
Implementieren der Blau-Grün-Bereitstellung
Andy schaut Tim an.
Andy: Das ist eine Menge, ich weiß. Möchten Sie sich etwas Zeit nehmen, um darüber nachzudenken? Oder Sie und ich könnten...
Tim: Blau-Grün.
Alle im Raum lachen.
Mara: Ist das der Kaffee, der da spricht?
Tim: Feature Toggles umfassen eine Änderung der Arbeitsweise von Ihnen und Andy. Lassen Sie uns der Reihe nach vorgehen. Die Methoden, die ein Feature schrittweise verfügbar machen, erfordern statistische Analysen oder Feature Toggles.
Eine Blau-Grün-Bereitstellung ist etwas, das ich steuern kann. Das Umschalten eines Routers ist unkompliziert. Es ist einfach und klingt sicher. Bei einer Blau-Grün-Bereitstellung verfügt das Management über eine Umgebung, die bewertet werden kann. Wenn sie ihr Einverständnis erteilen, können wir einfach umschalten. Setzen wir dort an.
Die Frage ist also, wie implementieren wir eine Blau-Grün-Bereitstellung in unserer Pipeline?
Was sind Bereitstellungsslots?
Andy: Da wir Azure App Service verwenden, können wir die Vorteile von Bereitstellungsslots nutzen. Bereitstellungsslots sind ausgeführte Apps mit eigenen Hostnamen.
Ich weiß, dass wir noch nicht bereit sind, die Space Game-Website als Teil der automatisierten Pipeline in der Produktionsumgebung bereitzustellen. Aber als Test können wir einen Bereitstellungsslot zu unserer Stagingumgebung hinzufügen.
Anstatt einen Lastenausgleich oder einen Router einzurichten, können wir einfach einen zweiten Slot zur App Service-Instanz hinzufügen, die wir in unserer bestehenden Stagingumgebung verwenden. Wir können den primären Slot Blau und den sekundären Slot Grün nennen.
Auf diese Weise können wir neue Features ohne Downtime bereitstellen. Wir tauschen eine Anwendung und ihre Konfiguration zwischen den beiden Bereitstellungsslots aus. Im Grunde tauschen wir die IP-Adressen der beiden Slots aus.
Tim: Das gefällt mir. Sie können diese Variation einer Blau-Grün-Bereitstellung als Bereitstellung ohne Downtime bezeichnen.
Andy: Prima! Tim und ich werden an der Implementierung dieses Bereitstellungsmusters arbeiten. Wir können uns alle später treffen, um die Ergebnisse zu prüfen.
Empfehlungen für die Verwendung von Featureflags
Featureflags waren eine der vom Team in Erwägung gezogenen Methoden für die Releasekadenz. Das Team hat sich entschieden, keine Featureflags zu verwenden, aber viele Personen haben sie als hilfreich empfunden. In diesem Abschnitt finden Sie weitere Informationen zu Featureflags.
Featureflags, gelegentlich auch als Feature Toggles bezeichnet, ermöglichen es Ihnen, die Funktionsweise eines Systems zu ändern, ohne den Code anzupassen. Mit diesen Flags können Sie neuen Code in Ihren zentralen Entwicklungsbranch pushen und den Code bereitstellen, der aber nicht unbedingt funktionsfähig sein muss. Die Flags werden in der Regel als Wert von Variablen implementiert, die eine bedingte Logik steuern.
Stellen Sie sich vor, dass Ihr Team in der zentralen Entwicklungsbranch einer Bankanwendung arbeitet. Sie haben sich entschieden, die gesamte Arbeit im Mainbranch zu erledigen, um später chaotische Zusammenführungsvorgänge zu vermeiden. Aber Sie stehen vor einem Problem. Sie ändern die Zinsberechnungen grundlegend, und die Menschen verlassen sich jeden Tag auf diesen Code. Schlimmer noch, die Änderungen werden Sie Wochen kosten. Sie können den Hauptcode nicht so lange unbrauchbar lassen.
In diesem Szenario könnte ein Featureflag eine gute Lösung darstellen. Sie können den Code so ändern, dass Benutzer, die das Featureflag nicht gesetzt haben, weiterhin den ursprünglichen Zinsberechnungscode verwenden können. In der Zwischenzeit hat Ihr Team das Featureflag gesetzt, sodass es den Code, den es ändert, sehen kann.
Eine andere Art von Featurekennzeichnung ist ein Release-Flag. Stellen Sie sich vor, dass Sie, nachdem Sie die Arbeit am Zinsberechnungscode abgeschlossen haben, diesen testen möchten, bevor Sie ihn öffentlich freigeben. Sie verfügen über eine Gruppe von Benutzern, die gut aufgestellt sind, um neuen Code und mögliche Probleme zu behandeln. Sie lassen sie das Feature zuerst testen. Sie ändern die Konfiguration so, dass sie auch das Featureflag gesetzt haben und den neuen Code testen können. Wenn Probleme auftreten, können Sie das Flag schnell deaktivieren.