Eine der wichtigsten Kennzahlen für DevOps ist die Geschwindigkeit, in der neue Features ausgeliefert werden. Wenn Entwickler, Ops- und Support-Teams gut aufeinander abgestimmt sind, können sie eine neue Software zügig in die Produktion geben, was schneller einen Mehrwert generiert und oft darüber entscheidet, ob sich Ihr Unternehmen einen Wettbewerbsvorteil verschafft.
Eine schnelle Auslieferung verkürzt auch die Zeit zwischen Softwareentwicklung und Feedback der UserInnen, ein entscheidender Faktor für Teams, die auf Continuous Integration und Continuous Deployment (CI/CD) setzen.
Vor diesem Hintergrund sollten Sie daran denken, Blue-Green Deployment in Ihr CI/CD Toolkit einzuführen. Mit diesem Prozess lassen sich technische und unternehmerische Risiken von Software-Releases reduzieren.
Bei diesem Modell werden zwei identische Produktionsumgebungen mit der Bezeichnung „Blau“ und „Grün“ parallel ausgeführt. Allerdings ist nur eine der beiden Umgebungen aktiv und erhält die Transaktionen der UserInnen. Die andere Umgebung ist produktionsfähig, aber nicht aktiv.
In diesem Artikel beschäftigen wir uns mit der Frage, wie Blue-Green Deployments funktionieren. Wir gehen näher auf die Pros und Kontras dieses Konzepts für Software-Releases ein. Darüber hinaus erklären wir, wie Blue-Green Deployments im Vergleich mit anderen Deployment-Methoden dastehen, und empfehlen Ihnen einige Best Practices für reibungslose Blue-Green-Deployments.
In diesem Artikel greifen wir folgende Punkte auf:
[toc]
Wie funktionieren Blue-Green Deployments?
Eine der größten Herausforderungen beim Deployment-Prozess ist das Cutover vom Testen auf die Produktion. Es muss schnell und reibungslos erfolgen, um die Ausfallzeit zu minimieren.
Das Blue-Green Deployment löst diese Aufgabe, indem zwei parallele Produktionsumgebungen verwendet werden. Dabei ist immer nur eine der beiden Umgebungen aktiv und erhält die Transaktionen der UserInnen. Im Bild unten ist es die grüne Umgebung. Das blaue – nicht aktive – System ist eine nahezu identische Kopie.
Ihr Team verwendet das blaue, nicht aktive System als Staging-Umgebung für die finale Testrunde, wenn ein neues Feature veröffentlicht werden soll. Sobald die neue Software in der blauen Umgebung problemlos funktioniert, kann Ihr Ops-Team den Datenverkehr auf die blaue Umgebung umleiten und dieses System dann live schalten. Anschließend können Sie das Feature in der grünen – inzwischen nicht aktiven – Umgebung implementieren, damit beide Systeme wieder synchron sind.
Damit wäre eigentlich das Wichtigste zum Blue-Green Deployment gesagt. Sie sind sehr flexibel, was die Strukturierung der parallelen Systeme und den Wechsel auf das jeweils andere System betrifft. Es könnte zum Beispiel sein, dass Sie keine parallelen Datenbanken pflegen möchten. In diesem Fall ändern Sie einfach das Routing und leiten den Datenverkehr auf Web- und App-Server weiter. Bei einem anderen Projekt könnten Sie ein Blue-Green Deployment verwenden, um ein noch nicht getestetes Feature im aktiven System zu veröffentlichen, wobei aber das Feature für A/B User-Tests hinter ein Feature Flag gesetzt wird.
Beispiel für ein Blue-Green Deployment
Angenommen, Sie sind in einem e-Commerce-Nischenunternehmen für ein DevOps-Team zuständig. Sie bieten Outfits und Accessoires an, die auf einem kleinen, jedoch hochwertigen Markt gefragt sind. Auf Ihrer Website können die KundInnen Produkte On-Demand personalisieren und bestellen.
Das Backend Ihrer Website enthält viele Microservices in einigen verschiedenen Containern. Sie haben Microservices für die Bestandsverwaltung, das Auftragsmanagement, Personalisierungs-Apps und ein integriertes soziales Netzwerk zur Unterstützung der Nischencommunity Ihrer KundInnen.
Ihr Team gibt frühzeitig und häufig Releases heraus, weil die anhaltende Beliebtheit Ihrer Website Ihrer Meinung nach dem CI/CD-Modell zu verdanken ist. Weil diese Nischencommunity auf der ganzen Welt verstreut ist, bleibt der Traffic auf Ihrer Website recht stabil. Deshalb ist es immer schwierig, einen relativ ruhigen Zeitpunkt zu finden, um Ihr Produktionssystem zu aktualisieren.
Sobald eines Ihrer Teams erklärt, dass das aktualisierte Customization Interface für den finalen Test in der Produktionsumgebung bereit steht, entscheiden Sie sich für ein Blue-Green Deployment, damit das Interface sofort veröffentlicht werden kann.
Am nächsten Tag entschließt sich Ihr Team vor der Mittagpause, den neuen Customizer bereitzustellen. Ab dieser Entscheidung wird der gesamte Traffic auf das blaue Produktionssystem geleitet. Sie aktualisieren die Software auf dem inaktiven grünen System und bitten die Tester und TesterInnen, eine QA durchzuführen. Weil alles in bester Ordnung zu sein scheint, verwendet Ihr Ops-Team einen Load-Balancer, um die User Sessions von „Blau“ auf „Grün“ zu leiten.
Nachdem der gesamte Traffic auf „Grün“ geleitet wurde, machen Sie diese Umgebung zur offiziellen Produktionsumgebung und setzen „Blau“ auf inaktiv. Ihr Dev-Team pusht den aktualisierten Customizer Code auf „Blau“, bestellt das Mittagessen und wirft einen Blick auf Ihren Backlog.
Pros von Blue-Green Deployments: Vorteile und Use Cases
Ein wesentlicher Vorteil von Blue-Green Deployments gegenüber anderen Strategien für Software-Releases ist ihre Flexibilität. Sie können in verschiedensten Umgebungen und vielen Use Cases nützlich sein.
Schnelle Releases
Für Product Owner, die innerhalb von CI/CD Frameworks arbeiten, sind Blue-Green Deployments eine ausgezeichnete Methode, Ihre Software in Produktion zu nehmen. Software können Sie praktisch zu jedem Zeitpunkt veröffentlichen. Sie müssen den Release nicht mehr auf ein Wochenende verschieben oder außerhalb der Geschäftszeiten planen: Meistens können Sie die Software einfach durch Umschalten aktiv stellen. Weil mit diesen Deployments keine Ausfallzeiten verbunden sind, haben sie keine negativen Auswirkungen auf die UserInnen.
Sie sind auch für DevOps-Teams weniger disruptiv. Sie müssen Updates nicht mehr überstürzt in einem bestimmten Zeitfenster vornehmen, wodurch sich Deployment-Fehler und unnötiger Stress vermeiden lassen. Auch für Führungsteams hat diese Methode Vorteile. Sie müssen bei einem Ausfall nicht ständig auf die Uhr schauen und sich den Umsatzverlust ausrechnen.
Rollbacks leicht gemacht
Der umgekehrte Prozess kann genauso schnell durchgeführt werden. Weil Blue-Green Deployments zwei parallele Produktionsumgebungen verwenden, können Sie bei einem Problem in Ihrer Liveumgebung schnell auf die stabile Umgebung zurückschalten.
Dadurch lassen sich die Risiken beim Experimentieren während der Produktion reduzieren. Ihr Team kann Probleme durch die Umleitung auf die stabile Produktionsumgebung einfach beheben. Dabei besteht die Gefahr Transaktionen der UserInnen zu verlieren – wir kommen später noch darauf zurück – doch es gibt eine Reihe von Strategien, um mit dieser Situation umzugehen.
Sie können Ihre App während eines Cutover vorübergehend in den Read-Only Modus setzen. Oder Sie können rollierende Cutover mit einem Load-Balancer durchführen, während Sie den Abschluss der Transaktionen in der Liveumgebung abwarten.
Integriertes Disaster Recovery
Weil Blue-Green Deployments zwei Produktionsumgebungen verwenden, bieten sie implizit Disaster Recovery für Ihre Business-Systeme. Eine duale Produktionsumgebung fungiert als eigenes Hot Backup.
Load Balancing
Bei parallelen Blue-Green Produktionsumgebungen lässt sich der Load-Balancer leicht bewerkstelligen. Wenn zwei Umgebungen funktionsmäßig identisch sind, können Sie einen Load-Balancer oder ein Feature Toggle in der Software verwenden, um Traffic nach Bedarf auf verschiedene Umgebungen zu leiten.
Einfacheres A/B Testing
Ein weiterer Use Case für parallele Produktionsumgebungen ist A/B Testing. Sie können neue Features in die inaktive Umgebung laden und den Traffic dann mit einem Feature Toggle zwischen Ihrer blauen und Ihrer grünen Umgebung aufteilen.
Sammeln Sie Daten von diesen geteilten User Sessions, überwachen Sie Ihre KPI und wenn die Analysen der neuen Features in Ihrem Management-System in Ordnung zu sein scheinen, können Sie den Traffic auf die aktualisierte Umgebung umleiten
Kontras von Blue-Green Deployments: Probleme, über die Sie sich im Klaren sein sollten
Blue-Green Deployments bieten viele Vorteile, stellen DevOps-Teams jedoch auch vor große Herausforderungen hinsichtlich Infrastruktur und Praktiken. Bevor Sie Blue-Green Deployments in Ihren CI/CD-Prozess integrieren, sollten Sie diese Probleme verstehen.
Blue-Green Deployments sind ressourcenintensiv
Wie inzwischen klar ist, müssen Sie für ein Blue-Green Deployment Ressourcen für zwei Produktionsumgebungen bereitstellen und beide Umgebungen pflegen. Für einige Unternehmen können die entsprechenden finanziellen Kosten und der Zeitaufwand für den Sysadmin zu hoch sein.
Andere Unternehmen können diese Ressourcen möglicherweise nur für ihre besonders hochwertigen Produkte bereitstellen. Soll das DevOps-Team in diesem Fall Software nur für bestimmte Produkte in einem CI/CD-Modell veröffentlichen? Langfristig ist dies möglicherweise nicht tragbar.
Zusätzlicher Aufwand für die Datenbankverwaltung
Die Verwaltung einer bzw. mehrerer Datenbanken in parallelen Produktionsumgebungen kann kompliziert sein. Sie müssen daran denken, was sie nach einem Software Update brauchen, sowohl in der blauen als auch in der grünen Umgebung, wie zum Beispiel alle externen Services, die Sie aufrufen.
Was passiert zum Beispiel, wenn eine Spalte der Datenbank aufgrund einer Änderung des Features umbenannt werden muss? Sobald Sie den Namen der Spalte in der blauen Umgebung ändern, funktioniert die grüne Umgebung (mit dem alten Code) mit dieser Datenbank nicht mehr.
Kann Ihre gesamte Produktionsumgebung überhaupt mit zwei separaten Datenbanken funktionieren? Meistens nicht, nämlich wenn Sie Ihr Blue-Green System für Load-Balancing, Testing oder irgendeine andere Funktion verwenden, außer als Hot Backup.
Produktmanagement
Abgesehen von der Systemadministration, erfordert das Produktmanagement in zwei nahezu identischen Umgebungen auch mehr Ressourcen. Produktmanager brauchen zuverlässige Tools, um nachzuverfolgen, wie ihre Software performt, welche Services die verschiedenen Teams aktualisieren und wie sie die entsprechenden KPI überwachen können. Weil diese Aktivitäten überwacht und kontrolliert werden müssen, ist ein zuverlässiges Produkt- und Feature-Management Dashboard besonders wichtig.
Blue-Green Deployments und Rolling Deployments
Blue-Green Deployments sind selbstverständlich nicht die einzige Option für schnelle Software-Releases. Ein weiteres beliebtes Konzept ist das Rolling Deployment.
Auch Rolling Deployments benötigen eine Produktionsumgebung, bei der eine Applikation auf mehreren Servern gehostet wird. Oft, aber nicht immer, ist ein Load-Balancer vorgeschaltet, um den Traffic zu verteilen. Wenn das DevOps-Team für ein Update seiner Applikation bereit ist, wird ein gestaffelter Release konfiguriert, wobei die aktualisierte Applikation von einem Server zum nächsten gepusht wird.
Beim Ausrollen des Release läuft die aktualisierte Applikation auf einigen Live-Servern, während auf anderen noch die alte Version läuft. Beim Blue-Green Deployment hingegen ist die aktualisierte Software für alle UserInnen live oder inaktiv.
Wenn UserInnen eine Session mit der Applikation starten, leitet sie der Load-Balancer entweder auf die alte oder auf die neue Version der Applikation weiter. Wenn das Rollout abgeschlossen ist, wird jede eingehende neue User Session auf die aktualisierte Version der Software geleitet. Sollte während des Rollouts ein Fehler auftreten, kann das DevOps-Team die Aktualisierung stoppen und den gesamten Traffic auf die verbleibenden einwandfrei funktionierenden Server umleiten, bis der Fehler behoben ist.
Rolling Deployments sind eine praktikable Option für Unternehmen mit Ressourcen, die für das Hosting einer Produktionsumgebung dieser Größenordnung notwendig sind. Für diese Unternehmen sind sie eine effiziente Methode, um kleine, graduelle Updates zu veröffentlichen – genau wie Sie das bei agilen Entwicklungsmethoden machen würden.
In anderen Use Cases sind Blue-Green Deployments möglicherweise die bessere Wahl. Wenn Sie zum Beispiel ein wichtiges Update vornehmen möchten und die UserInnen keinen Zugriff auf die alte Version haben sollen, ist ein „alles oder nichts“ Konzept wie das Blue-Green Deployment genau richtig.
Angenommen, Ihre Applikation erfordert ein hohes Maß an technischem Support oder Kundensupport. In diesem Fall ist der Support während der Rolling Deployment Windows noch mehr gefordert, weil die Support-Mitarbeiter nicht wissen können, welche Version der Applikation bei einem User oder einer Userin läuft.
Blue-Green Deployments und Canary Releases
Rolling Deployments und Blue-Green Deployments sind nicht die einzigen Release Strategien. Canary Releases stellen eine weitere Möglichkeit dar. Bei einer Canary Release erhält zuerst nur ein Teil aller Produktionsumgebungen ein Software-Update. Doch statt das Deployment auf den Rest auszurollen, bleibt dieser partielle Release für Testzwecke auf den Teilbereich beschränkt. Ein Teil der UserInnen wird dann durch einen Load-Balancer oder ein Feature Flag zur neuen Software weitergeleitet.
Canary Releases sind sinnvoll, wenn Sie von identifizierbaren UserInnen Daten und Feedback zu einer aktualisierten Software erhalten möchten. Canary Releases fügen sich perfekt in umfassendere rollierende Deployments ein: Sie können die aktualisierte Software schrittweise an immer größere Segmente Ihrer User Base ausrollen, bis schließlich alle Produktionsserver aktualisiert sind.
Best Practices für Blue-Green Deployment
Sie haben viele Möglichkeiten, Software schnell zu veröffentlichen. Wenn Sie Blue-Green Deployment als neue Software Release-Strategie in Betracht ziehen, empfehlen wir Ihnen die folgenden Best Practices.
Automatisieren Sie, was automatisierbar ist
Beim Release-Prozess so oft wie möglich auf Scripting und Automatisierung zurückzugreifen, bietet viele Vorteile. Sie führen nicht nur schneller zum Cutover, sondern lassen auch weniger Raum für menschliche Fehler. Ein Entwickler kann nicht versehentlich einen Punkt auf einer Checkliste vergessen, wenn die Liste von einem Script oder einer Management-Plattform abgearbeitet wird. Wenn alles in ein Script gepackt wird, kann jeder das Deployment durchführen, ob Entwickler oder nicht. Sie müssen nicht warten, bis Ihr Systemexperte wieder im Büro ist.
Überwachen Sie Ihre Systeme
Überwachen Sie immer sowohl die blaue als auch die grüne Umgebung. Damit ein Blue-Green Deployment reibungslos verläuft, müssen Sie wissen, was im aktiven und im inaktiven System vor sich geht.
Beide Systeme benötigen wahrscheinlich dasselbe Warnsystem, für das jedoch verschiedene Prioritäten gesetzt werden. Sie möchten zum Beispiel sofort erfahren, wenn in Ihrem Live-System ein Fehler auftritt. Im inaktiven System hingegen reicht es, wenn der betreffende Fehler im Laufe des Arbeitstages behoben wird.
Schreiben Sie rückwärts und vorwärts kompatible Codes
In einigen Fällen können die neue und die alte Version Ihrer Software während eines Cutovers nicht gleichzeitig ausgeführt werden. Angenommen, Sie müssen das Datenbankschema ändern: In diesem Fall wäre es sinnvoll, Ihre Updates so zu strukturieren, dass sowohl das blaue als auch das grüne System über das gesamte Cutover funktionsfähig ist.
Eine Lösung wäre, Ihre Releases in eine Reihe von noch kleineren Release-Paketen aufzuteilen. Nehmen wir an, unser e-Commerce Unternehmen detailliert sein Sortiment und muss seine Datenbank aktualisieren. Um Klarheit zu schaffen, soll das Feld „Hemd“ in „langaermliges_Hemd“ umbenannt werden.
Dieses Update könnte folgendermaßen aufgegliedert werden:
- Veröffentlichung einer Zwischenversion des Codes, die mit einem Flag aktiviert wird und sowohl die Ergebnisse von „Hemd“ als auch von „langaermliges_Hemd“ interpretieren kann.
- Migration der gesamten Datenbank, um das Feld umzubenennen.
- Veröffentlichung der endgültigen Codeversion – oder Umlegen des Feature Flags – damit die Software nur „langaermliges_Hemd“ verwendet.
Führen Sie mehr und kleinere Deployments durch
Kleinere, häufigere Updates haben sich bereits als integraler Bestandteil der agilen Entwicklung und von CI/CD etabliert. Bei Blue-Green Deployments ist diese Vorgehensweise noch wichtiger. Geringere Deployment-Zeiten verkürzen die Feedback-Schleifen, die Informationen für das nächste Release liefern. Dadurch wird jedes inkrementelle Upgrade effektiver und wertvoller für Ihr Unternehmen.
Reorganisieren Sie Ihre Applikationen in Microservices
Diese Methode geht Hand in Hand mit kleineren Deployments. Durch die Restrukturierung des Applikationscodes in Microservices können Sie Updates und Änderungen einfacher verwalten. Verschiedene Features werden so unterteilt, dass sie leichter getrennt aktualisiert werden können.
Verwenden Sie Feature Flags zur weiteren Risikoreduzierung
An sich öffnen Blue-Green Deployments ein einziges, kurzes Risikofenster. Sie aktualisieren alles, alles oder nichts, können aber jederzeit einen Rückzieher machen, falls ein Problem auftritt.
Blue-Green Deployments verursachen mit jedem Cutover aber auch einen ziemlich konstanten Administrationsaufwand. Sie können diesen Mehraufwand zwar durch Automatisierung reduzieren, doch der Prozess bleibt gleich – egal ob Sie nur eine Codezeile oder Ihre gesamte e-Commerce Suite aktualisieren.
AB Tasty Feature Flag Service
Mit Feature Flags lässt sich bis ins Detail kontrollieren, wie und wann UserInnen neu verfügbare Software nutzen können. Feature Flags verhalten sich wie leistungsstarke „If“-Statements, ab denen während der Laufzeit mindestens einem von zwei oder mehreren verschiedenen Codepfaden abhängig von einer gegebenen Bedingung gefolgt wird.
Diese Bedingungen können einfache „Ja/Nein“ Prüfungen oder komplexe Entscheidungsbäume sein. Feature Flags machen Software Releases überschaubarer, denn mit ihnen lässt sich Feature für Feature kontrollieren, was ein- oder ausgeschaltet ist.
Ihr e-Commerce Unternehmen kann beispielsweise ein Blue-Green Deployment seines Microservices Customizer durchführen, aber den neuen Code im Live-System hinter einem Feature Flag inaktiv lassen. Das DevOps-Team kann das betreffende Feature dann je nach gewünschter Bedingung zum gewünschten Zeitpunkt einschalten.
Eventuell möchte das Team weitere A/B-Tests in Produktion nehmen oder weitere Tauglichkeitstests vornehmen. Oder es könnte für das Team sinnvoller sein, für eine identifizierte Gruppe von Early UserInnen ein Canary Release des Customizer durchzuführen.
Ihre Feature Flags können zusammen mit einem Load Balancer bestimmen, welche UserInnen welche Applikation und Feature-Subsets während eines Blue-Green Deployments zu sehen bekommen. Statt ganze Applikationen auf einmal umzuschalten, können Sie auf die neue Applikation wechseln und dann im aktiven und inaktiven System nach und nach einzelne Feature aktivieren und deaktivieren, bis das Upgrade vollständig durchgeführt ist. Dieser schrittweise durchgeführte Prozess reduziert das Risiko und hilft Ihnen, Bugs aufzuspüren, da die einzelnen Features nach und nach live geschaltet werden.
Sie können Feature Flags manuell in Ihrer Codebase steuern oder für eine effektivere Steuerung Feature Flag Services verwenden. Diese Plattformen bieten ein detailliertes Reporting und KPI-Tracking sowie ein ausführliches Spektrum von DevOps Management-Tools.
Wir empfehlen Ihnen, Feature Flags zu verwenden, wenn Sie ein Blue-Green Deployment für einen größeren Release der Applikation durchführen. Sie sind auch in kleineren Deployments praktisch, bei denen Sie nicht unbedingt zwischen den Umgebungen umschalten. Sie können nach und nach Features in der blauen Umgebung einzeln aktivieren und die grüne Umgebung im Standby als Hot Backup verwenden, falls ein ernsthaftes Problem auftritt. Die Kombination aus Blue-Green Deployments und Feature Flags eignet sich ausgezeichnet für eine Continuous Delivery jeder Größenordnung.
Ziehen Sie in Betracht, Blue-Green Deployments in das Arsenal Ihrer DevOps hinzuzufügen
Blue-Green Deployments eignen sich bestens für Software Releases jeder Größe, egal, ob es sich um eine ganze Applikation, größere Updates, einen einzigen Microservice oder das Update eines kleinen Features handelt.
Bevor Sie sich für Blue-Green Deployments entscheiden, müssen Sie auf jeden Fall prüfen, wie gut sie sich in Ihren aktuellen Delivery Prozess integrieren lassen. In diesem Artikel haben wir erklärt, wie Blue-Green Deployments funktionieren, was für und was gegen ihre Verwendung in Ihrem Delivery Prozess spricht und wie sie sich von anderen möglichen Deployment-Methoden differenzieren. Sie sollten sich jetzt eine Vorstellung davon machen können, ob Blue-Green Deployments für Ihr Unternehmen in Frage kommen.
