Vor diesem Hintergrund sollten Sie daran denken, Blue-Green Deployment in Ihr CI\/CD Toolkit<\/a> einzuf\u00fchren. Mit diesem Prozess lassen sich technische und unternehmerische Risiken von Software-Releases reduzieren.<\/p>\n Bei diesem Modell werden zwei identische Produktionsumgebungen mit der Bezeichnung \u201eBlau\u201c und \u201eGr\u00fcn\u201c parallel ausgef\u00fchrt. Allerdings ist nur eine der beiden Umgebungen aktiv und erh\u00e4lt die Transaktionen der UserInnen. Die andere Umgebung ist produktionsf\u00e4hig, aber nicht aktiv.<\/p>\n In diesem Artikel besch\u00e4ftigen wir uns mit der Frage, wie Blue-Green Deployments funktionieren. Wir gehen n\u00e4her auf die Pros und Kontras dieses Konzepts f\u00fcr Software-Releases ein. Dar\u00fcber hinaus erkl\u00e4ren wir, wie Blue-Green Deployments im Vergleich mit anderen Deployment-Methoden dastehen, und empfehlen Ihnen einige Best Practices f\u00fcr reibungslose Blue-Green-Deployments.<\/p>\n In diesem Artikel greifen wir folgende Punkte auf:<\/p>\n [toc]<\/p>\n Eine der gr\u00f6\u00dften Herausforderungen beim Deployment-Prozess<\/strong> ist das Cutover vom Testen auf die Produktion. Es muss schnell und reibungslos erfolgen, um die Ausfallzeit zu minimieren.<\/p>\n Das Blue-Green Deployment l\u00f6st diese Aufgabe, indem zwei parallele Produktionsumgebungen verwendet werden. Dabei ist immer nur eine der beiden Umgebungen aktiv und erh\u00e4lt die Transaktionen der UserInnen. Im Bild unten ist es die gr\u00fcne Umgebung. Das blaue \u2013 nicht aktive \u2013 System ist eine nahezu identische Kopie.<\/p>\n Ihr Team verwendet das blaue, nicht aktive System als Staging-Umgebung f\u00fcr die finale Testrunde, wenn ein neues Feature ver\u00f6ffentlicht 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\u00dfend k\u00f6nnen Sie das Feature in der gr\u00fcnen \u2013 inzwischen nicht aktiven \u2013 Umgebung implementieren, damit beide Systeme wieder synchron sind.<\/p>\n Damit w\u00e4re 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\u00f6nnte zum Beispiel sein, dass Sie keine parallelen Datenbanken pflegen m\u00f6chten. In diesem Fall \u00e4ndern Sie einfach das Routing und leiten den Datenverkehr auf Web- und App-Server weiter. Bei einem anderen Projekt k\u00f6nnten Sie ein Blue-Green Deployment verwenden, um ein noch nicht getestetes Feature im aktiven System zu ver\u00f6ffentlichen, wobei aber das Feature f\u00fcr A\/B User-Tests hinter ein Feature Flag gesetzt wird.<\/p>\n Angenommen, Sie sind in einem e-Commerce-Nischenunternehmen f\u00fcr ein DevOps-Team zust\u00e4ndig. Sie bieten Outfits und Accessoires an, die auf einem kleinen, jedoch hochwertigen Markt gefragt sind. Auf Ihrer Website k\u00f6nnen die KundInnen Produkte On-Demand personalisieren und bestellen.<\/p>\n Das Backend Ihrer Website enth\u00e4lt viele Microservices in einigen verschiedenen Containern. Sie haben Microservices f\u00fcr die Bestandsverwaltung, das Auftragsmanagement, Personalisierungs-Apps und ein integriertes soziales Netzwerk zur Unterst\u00fctzung der Nischencommunity Ihrer KundInnen.<\/p>\n Ihr Team gibt fr\u00fchzeitig und h\u00e4ufig Releases heraus, weil die anhaltende Beliebtheit Ihrer Website Ihrer Meinung nach dem CI\/CD-Modell<\/strong> 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.<\/p>\n Sobald eines Ihrer Teams erkl\u00e4rt, dass das aktualisierte Customization Interface f\u00fcr den finalen Test in der Produktionsumgebung bereit steht, entscheiden Sie sich f\u00fcr ein Blue-Green Deployment, damit das Interface sofort ver\u00f6ffentlicht werden kann.<\/p>\n Am n\u00e4chsten Tag entschlie\u00dft 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\u00fcnen System und bitten die Tester und TesterInnen, eine QA durchzuf\u00fchren. Weil alles in bester Ordnung zu sein scheint, verwendet Ihr Ops-Team einen Load-Balancer, um die User Sessions von \u201eBlau\u201c auf \u201eGr\u00fcn\u201c zu leiten<\/strong>.<\/p>\n Nachdem der gesamte Traffic auf \u201eGr\u00fcn\u201c geleitet wurde, machen Sie diese Umgebung zur offiziellen Produktionsumgebung und setzen \u201eBlau\u201c auf inaktiv. Ihr Dev-Team pusht den aktualisierten Customizer Code auf \u201eBlau\u201c, bestellt das Mittagessen und wirft einen Blick auf Ihren Backlog.<\/p>\n Ein wesentlicher Vorteil von Blue-Green Deployments gegen\u00fcber anderen Strategien f\u00fcr Software-Releases ist ihre Flexibilit\u00e4t. Sie k\u00f6nnen in verschiedensten Umgebungen und vielen Use Cases n\u00fctzlich sein.<\/p>\n F\u00fcr Product Owner, die innerhalb von CI\/CD Frameworks arbeiten, sind Blue-Green Deployments eine ausgezeichnete Methode, Ihre Software in Produktion zu nehmen<\/strong>. Software k\u00f6nnen Sie praktisch zu jedem Zeitpunkt ver\u00f6ffentlichen.\u00a0 Sie m\u00fcssen den Release nicht mehr auf ein Wochenende verschieben oder au\u00dferhalb der Gesch\u00e4ftszeiten planen: Meistens k\u00f6nnen Sie die Software einfach durch Umschalten aktiv stellen. Weil mit diesen Deployments keine Ausfallzeiten verbunden sind, haben sie keine negativen Auswirkungen auf die UserInnen.<\/strong><\/p>\n Sie sind auch f\u00fcr DevOps-Teams weniger disruptiv. Sie m\u00fcssen Updates nicht mehr \u00fcberst\u00fcrzt in einem bestimmten Zeitfenster vornehmen, wodurch sich Deployment-Fehler<\/a> und unn\u00f6tiger Stress vermeiden lassen. Auch f\u00fcr F\u00fchrungsteams hat diese Methode Vorteile. Sie m\u00fcssen bei einem Ausfall nicht st\u00e4ndig auf die Uhr schauen und sich den Umsatzverlust ausrechnen.<\/p>\n Der umgekehrte Prozess kann genauso schnell durchgef\u00fchrt werden. Weil Blue-Green Deployments zwei parallele Produktionsumgebungen verwenden,<\/strong> k\u00f6nnen Sie bei einem Problem in Ihrer Liveumgebung schnell auf die stabile Umgebung zur\u00fcckschalten.<\/p>\n Dadurch lassen sich die Risiken beim Experimentieren w\u00e4hrend 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 \u2013 wir kommen sp\u00e4ter noch darauf zur\u00fcck \u2013 doch es gibt eine Reihe von Strategien, um mit dieser Situation umzugehen.<\/p>\n Sie k\u00f6nnen Ihre App w\u00e4hrend eines Cutover vor\u00fcbergehend in den Read-Only Modus setzen. Oder Sie k\u00f6nnen rollierende Cutover mit einem Load-Balancer durchf\u00fchren, w\u00e4hrend Sie den Abschluss der Transaktionen in der Liveumgebung abwarten.<\/p>\n Weil Blue-Green Deployments zwei Produktionsumgebungen verwenden, bieten sie implizit Disaster Recovery f\u00fcr Ihre Business-Systeme<\/strong>. Eine duale Produktionsumgebung fungiert als eigenes Hot Backup.<\/p>\n Bei parallelen Blue-Green Produktionsumgebungen l\u00e4sst sich der Load-Balancer leicht bewerkstelligen. Wenn zwei Umgebungen funktionsm\u00e4\u00dfig identisch sind, k\u00f6nnen Sie einen Load-Balancer oder ein Feature Toggle in der Software verwenden, um Traffic nach Bedarf auf verschiedene Umgebungen zu leiten<\/strong>.<\/p>\n Ein weiterer Use Case f\u00fcr parallele Produktionsumgebungen ist A\/B Testing<\/a>. Sie k\u00f6nnen neue Features in die inaktive Umgebung laden und den Traffic dann mit einem Feature Toggle zwischen Ihrer blauen und Ihrer gr\u00fcnen Umgebung aufteilen.<\/p>\n Sammeln Sie Daten von diesen geteilten User Sessions, \u00fcberwachen Sie Ihre KPI und wenn die Analysen der neuen Features in Ihrem Management-System in Ordnung zu sein scheinen, k\u00f6nnen Sie den Traffic auf die aktualisierte Umgebung umleiten<\/p>\n Blue-Green Deployments bieten viele Vorteile, stellen DevOps-Teams jedoch auch vor gro\u00dfe Herausforderungen hinsichtlich Infrastruktur und Praktiken. Bevor Sie Blue-Green Deployments in Ihren CI\/CD-Prozess<\/strong> integrieren, sollten Sie diese Probleme verstehen.<\/p>\n Wie inzwischen klar ist, m\u00fcssen Sie f\u00fcr ein Blue-Green Deployment Ressourcen f\u00fcr zwei Produktionsumgebungen bereitstellen und beide Umgebungen pflegen. F\u00fcr einige Unternehmen k\u00f6nnen die entsprechenden finanziellen Kosten und der Zeitaufwand f\u00fcr den Sysadmin zu hoch sein. Die Verwaltung einer bzw. mehrerer Datenbanken in parallelen Produktionsumgebungen kann kompliziert sein. Sie m\u00fcssen daran denken, was sie nach einem Software Update brauchen, sowohl in der blauen als auch in der gr\u00fcnen Umgebung, wie zum Beispiel alle externen Services, die Sie aufrufen. Abgesehen von der Systemadministration, erfordert das Produktmanagement in zwei nahezu identischen Umgebungen auch mehr Ressourcen. Produktmanager brauchen zuverl\u00e4ssige Tools, um nachzuverfolgen, wie ihre Software performt,<\/strong> welche Services die verschiedenen Teams aktualisieren und wie sie die entsprechenden KPI \u00fcberwachen k\u00f6nnen. Weil diese Aktivit\u00e4ten \u00fcberwacht und kontrolliert werden m\u00fcssen, ist ein zuverl\u00e4ssiges Produkt- und Feature-Management Dashboard besonders wichtig.<\/p>\n Blue-Green Deployments sind selbstverst\u00e4ndlich nicht die einzige Option f\u00fcr schnelle Software-Releases. Ein weiteres beliebtes Konzept ist das Rolling Deployment.<\/strong><\/p>\n Auch Rolling Deployments ben\u00f6tigen 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\u00fcr ein Update seiner Applikation bereit ist, wird ein gestaffelter Release konfiguriert, wobei die aktualisierte Applikation von einem Server zum n\u00e4chsten gepusht wird.<\/p>\n Beim Ausrollen des Release l\u00e4uft die aktualisierte Applikation auf einigen Live-Servern, w\u00e4hrend auf anderen noch die alte Version l\u00e4uft. Beim Blue-Green Deployment hingegen ist die aktualisierte Software f\u00fcr alle<\/em> UserInnen live oder inaktiv.<\/p>\n 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.<\/strong> Sollte w\u00e4hrend 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.<\/p>\n Rolling Deployments sind eine praktikable Option f\u00fcr Unternehmen mit Ressourcen, die f\u00fcr das Hosting einer Produktionsumgebung dieser Gr\u00f6\u00dfenordnung notwendig sind. F\u00fcr diese Unternehmen sind sie eine effiziente Methode, um kleine, graduelle Updates zu ver\u00f6ffentlichen \u2013 genau wie Sie das bei agilen Entwicklungsmethoden machen w\u00fcrden.<\/p>\n In anderen Use Cases sind Blue-Green Deployments m\u00f6glicherweise die bessere Wahl. Wenn Sie zum Beispiel ein wichtiges Update vornehmen m\u00f6chten und die UserInnen keinen Zugriff auf die alte Version haben sollen, ist ein \u201ealles oder nichts\u201c Konzept wie das Blue-Green Deployment genau richtig.<\/p>\n Angenommen, Ihre Applikation erfordert ein hohes Ma\u00df an technischem Support oder Kundensupport. In diesem Fall ist der Support w\u00e4hrend der Rolling Deployment Windows noch mehr gefordert, weil die Support-Mitarbeiter nicht wissen k\u00f6nnen, welche Version der Applikation bei einem User oder einer Userin l\u00e4uft.<\/p>\n Rolling Deployments und Blue-Green Deployments sind nicht die einzigen Release Strategien. Canary Releases stellen eine weitere M\u00f6glichkeit dar. Bei einer Canary Release erh\u00e4lt zuerst nur ein Teil aller Produktionsumgebungen ein Software-Update. Doch statt das Deployment auf den Rest auszurollen, bleibt dieser partielle Release f\u00fcr Testzwecke auf den Teilbereich beschr\u00e4nkt. Ein Teil der UserInnen wird dann durch einen Load-Balancer oder ein Feature Flag zur neuen Software weitergeleitet.<\/strong><\/p>\n Canary Releases sind sinnvoll, wenn Sie von identifizierbaren UserInnen Daten und Feedback zu einer aktualisierten Software erhalten m\u00f6chten. Canary Releases f\u00fcgen sich perfekt in umfassendere rollierende Deployments ein: Sie k\u00f6nnen die aktualisierte Software schrittweise an immer gr\u00f6\u00dfere Segmente Ihrer User Base ausrollen, bis schlie\u00dflich alle Produktionsserver aktualisiert sind.<\/p>\n Sie haben viele M\u00f6glichkeiten, Software schnell zu ver\u00f6ffentlichen. Wenn Sie Blue-Green Deployment als neue Software Release-Strategie in Betracht ziehen, empfehlen wir Ihnen die folgenden Best Practices.<\/p>\n Beim Release-Prozess so oft wie m\u00f6glich auf Scripting und Automatisierung zur\u00fcckzugreifen, bietet viele Vorteile.<\/strong> Sie f\u00fchren nicht nur schneller zum Cutover, sondern lassen auch weniger Raum f\u00fcr 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\u00fchren, ob Entwickler oder nicht. Sie m\u00fcssen nicht warten, bis Ihr Systemexperte wieder im B\u00fcro ist.<\/p>\n \u00dcberwachen Sie immer sowohl die blaue als auch die gr\u00fcne Umgebung. Damit ein Blue-Green Deployment reibungslos verl\u00e4uft, m\u00fcssen Sie wissen, was im aktiven und im inaktiven System vor sich geht.<\/p>\n Beide Systeme ben\u00f6tigen wahrscheinlich dasselbe<\/strong> Warnsystem, f\u00fcr das jedoch verschiedene Priorit\u00e4ten gesetzt werden.<\/strong> Sie m\u00f6chten 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.<\/p>\n In einigen F\u00e4llen k\u00f6nnen die neue und die alte Version Ihrer Software w\u00e4hrend eines Cutovers nicht gleichzeitig ausgef\u00fchrt werden. Angenommen, Sie m\u00fcssen das Datenbankschema \u00e4ndern: In diesem Fall w\u00e4re es sinnvoll, Ihre Updates so zu strukturieren, dass sowohl das blaue als auch das gr\u00fcne System \u00fcber das gesamte Cutover funktionsf\u00e4hig ist.<\/p>\n Eine L\u00f6sung w\u00e4re, 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 \u201eHemd\u201c in \u201elangaermliges_Hemd<\/em>\u201c umbenannt werden.<\/p>\n Dieses Update k\u00f6nnte folgenderma\u00dfen aufgegliedert werden:<\/p>\n Kleinere, h\u00e4ufigere 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\u00fcrzen die Feedback-Schleifen,<\/strong> die Informationen f\u00fcr das n\u00e4chste Release liefern. Dadurch wird jedes inkrementelle Upgrade effektiver und wertvoller f\u00fcr Ihr Unternehmen.<\/p>\n Diese Methode geht Hand in Hand mit kleineren Deployments. Durch die Restrukturierung des Applikationscodes in Microservices k\u00f6nnen Sie Updates und \u00c4nderungen einfacher verwalten. Verschiedene Features werden so unterteilt, dass sie leichter getrennt aktualisiert werden k\u00f6nnen.<\/p>\n An sich \u00f6ffnen Blue-Green Deployments ein einziges, kurzes Risikofenster. Sie aktualisieren alles, alles oder nichts, k\u00f6nnen aber jederzeit einen R\u00fcckzieher machen, falls ein Problem auftritt.<\/p>\n Blue-Green Deployments verursachen mit jedem Cutover aber auch einen ziemlich konstanten Administrationsaufwand. Sie k\u00f6nnen diesen Mehraufwand zwar durch Automatisierung reduzieren, doch der Prozess bleibt gleich \u2013 egal ob Sie nur eine Codezeile oder Ihre gesamte e-Commerce Suite aktualisieren. Wingify Feature Flag Service<\/p>\n Mit Feature Flags l\u00e4sst sich bis ins Detail kontrollieren, wie und wann UserInnen neu verf\u00fcgbare Software nutzen k\u00f6nnen. Feature Flags verhalten sich wie leistungsstarke \u201eIf\u201c-Statements, ab denen w\u00e4hrend der Laufzeit mindestens einem von zwei oder mehreren verschiedenen Codepfaden abh\u00e4ngig von einer gegebenen Bedingung gefolgt wird.<\/p>\nWie funktionieren Blue-Green Deployments?<\/h2>\n
![\"Routing-Diagramm](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/blue_green_deployments.jpg\")
Beispiel f\u00fcr ein Blue-Green Deployment<\/h2>\n
![\"Load-Balancer](\"https:\/\/www.redhat.com\/cms\/managed-files\/blue-green-deployment-model.gif\")
Pros von Blue-Green Deployments: Vorteile und Use Cases<\/h2>\n
Schnelle Releases<\/h3>\n
Rollbacks leicht gemacht<\/h3>\n
Integriertes Disaster Recovery<\/h3>\n
![\"Disaster](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/sever-3100049_1920-min-1024x745.jpg\")
Load Balancing<\/h3>\n
Einfacheres A\/B Testing<\/h3>\n
Kontras von Blue-Green Deployments: Probleme, \u00fcber die Sie sich im Klaren sein sollten<\/h2>\n
Blue-Green Deployments sind ressourcenintensiv<\/h3>\n
\nAndere Unternehmen k\u00f6nnen diese Ressourcen m\u00f6glicherweise nur f\u00fcr ihre besonders hochwertigen Produkte bereitstellen. Soll das DevOps-Team in diesem Fall Software nur f\u00fcr bestimmte Produkte in einem CI\/CD-Modell ver\u00f6ffentlichen? Langfristig ist dies m\u00f6glicherweise nicht tragbar.<\/p>\nZus\u00e4tzlicher Aufwand f\u00fcr die Datenbankverwaltung<\/h3>\n
\nWas passiert zum Beispiel, wenn eine Spalte der Datenbank aufgrund einer \u00c4nderung des Features umbenannt werden muss? Sobald Sie den Namen der Spalte in der blauen Umgebung \u00e4ndern, funktioniert die gr\u00fcne Umgebung (mit dem alten Code) mit dieser Datenbank nicht mehr.
\nKann Ihre gesamte Produktionsumgebung \u00fcberhaupt mit zwei separaten Datenbanken funktionieren? Meistens nicht, n\u00e4mlich wenn Sie Ihr Blue-Green System f\u00fcr Load-Balancing, Testing oder irgendeine andere Funktion verwenden, au\u00dfer als Hot Backup.<\/p>\n![\"Blue-Green](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/bluegreen1.jpg\")
Produktmanagement<\/h3>\n
Blue-Green Deployments und Rolling Deployments<\/h2>\n
![\"Rolling](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/rolling_deployment_desktop.jpg\")
Blue-Green Deployments und Canary Releases<\/h2>\n
Best Practices f\u00fcr Blue-Green Deployment<\/h2>\n
Automatisieren Sie, was automatisierbar ist<\/h3>\n
\u00dcberwachen Sie Ihre Systeme<\/h3>\n
![\"\u00dcberwachung](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/christina-wocintechchat-com-2JDDn7iSGH8-unsplash-1024x683.jpg\")
Schreiben Sie r\u00fcckw\u00e4rts und vorw\u00e4rts kompatible Codes<\/h3>\n
\n
F\u00fchren Sie mehr und kleinere Deployments durch<\/h3>\n
Reorganisieren Sie Ihre Applikationen in Microservices<\/h3>\n
Verwenden Sie Feature Flags zur weiteren Risikoreduzierung<\/h3>\n
\n![\"Wingify](\"https:\/\/static.wingify.com\/gcp\/uploads\/abtasty\/feature_management_progressive_rollout_kpi_tracking.jpg\"){kind=tracking}
<\/p>\n