Kurz erklärt: Bei Blue-Green-Deployments wird der Benutzerverkehr auf andere Server umgeleitet, die Ihre aktualisierte Anwendung hosten. Feature-Flags hingegen sind codebasiert und ermöglichen es Benutzern, ein Update durch Änderungen auf Anwendungsebene zu sehen.
Dieser Blogbeitrag gibt einen Überblick darüber, wie Feature-Flags ähnliche Herausforderungen wie Blue-Green-Deployments lösen, jedoch mit mehr Kontrolle und geringerem Entwicklungsaufwand. Schauen wir uns das genauer an:
Ein einfaches Beispiel: Blue-Green-Deployments
Bei einem Blue-Green-Deployment wird ein Teil Ihrer Server für die neue Version Ihrer Anwendung und ein anderer Teil für die vorherige Version verwendet. Im folgenden Diagramm hostet die blaue Servergruppe Ihre aktuelle Version, die grüne die neue. Um Benutzern das Update bereitzustellen, müssen Sie sich mit dem Betriebsteam abstimmen, um den Datenverkehr über den Load Balancer (auch bekannt als Traffic-Router) umzuleiten.
Wenn Sie ein Release veröffentlichen, das mehrere Funktionen aktualisiert, und dabei einen Fehler in einer dieser Funktionen entdecken, können Sie einfach zur vorherigen Version zurückkehren, indem Sie den Datenverkehr auf die vorherige Version oder die Server der „blauen Gruppe“ umleiten. Blue-Green-Deployments sind in dieser Hinsicht jedoch eine ungenaue Lösung, da sie keine Kontrolle auf Funktionsebene ermöglichen. Sie müssen das gesamte Update zurücksetzen, um nur eine Funktion zu deaktivieren.
Vorteile und Nachteile von Blue-Green-Deployments
Eine präzise Lösung: Feature-Flag-Bereitstellungen
Mit Feature-Flags (auch bekannt als Feature-Toggles) verfügt jede Funktion Ihres Softwareupdates über ein eigenes Flag bzw. einen eigenen Toggle, der unabhängig von der vollständigen Version gesteuert werden kann. Mit einem Feature-Flag-Dienst wie Optimizely Rollouts können Sie die Flags innerhalb der Benutzeroberfläche der Feature-Flag-Plattform erstellen und anschließend neue Features oder Codepfade in den Feature-Flag-Code einbetten.
Wenn Sie dieses Mal einen Fehler in einer Ihrer Funktionen entdecken, müssen Sie nicht die gesamte Version zurücksetzen. Sie können die fehlerhafte Funktion einfach in Ihrem Feature-Management-Dashboard deaktivieren – ganz ohne Code-Deployment. Feature-Flags bieten dadurch mehr Kontrolle, reagieren schneller und sparen Entwicklungszeit im Vergleich zu Blue-Green-Deployments, die teamübergreifende Zusammenarbeit und die Pflege mehrerer Versionen auf Ihren Servern erfordern.
Vorteile und Nachteile von Feature-Flag-Deployments
Update nur für eine Teilmenge der Nutzer bereitstellen
Die Vorteile von Feature-Flags für die Veröffentlichung von Funktionen werden besonders deutlich, wenn man an Canary-Releases denkt. Dabei werden Funktionen zunächst nur einer kleinen Teilmenge der Nutzer zur Verfügung gestellt, bevor sie für alle freigegeben werden. Bei der Veröffentlichung einer neuen Version mit Funktionsupdates empfiehlt es sich, die Änderungen zunächst mit einer kleinen Gruppe zu testen, um sicherzustellen, dass alles einwandfrei funktioniert. In der Softwareentwicklung spricht man von Canary-Tests bzw. Canary-Deployments oder gestaffelten Rollouts.
Canary-Tests ermöglichen es, neuen Code oder neue Funktionen zunächst einer kleinen Gruppe von Nutzern zur Verfügung zu stellen, um eventuelle Probleme zu erkennen, bevor sie für alle freigegeben werden. Durch die Beschränkung auf eine ausgewählte Gruppe lässt sich die Verbreitung neuer Releases minimieren, und Teams können Funktionalität und Leistung vor der Freigabe für alle Nutzer überprüfen. Dieser Ansatz hilft auch dabei, Probleme zu erkennen, die erst beim Wechsel von der Entwicklungs- oder Testumgebung in die Produktionsumgebung sichtbar werden.
Canary-Tests lassen sich sowohl mit Blue-Green-Deployments als auch mit Feature-Flags durchführen, allerdings bestehen dieselben Herausforderungen bei der Steuerung des Datenverkehrs auf Serverebene.
Canary-Tests mit Blue-Green-Deployments: Anstatt den gesamten Datenverkehr von der blauen Servergruppe, die die aktuelle Anwendungsversion hostet, zur grünen Servergruppe umzuleiten, kann nur ein Teil des Datenverkehrs auf die neue Version umgeleitet werden. Allerdings haben Sie weiterhin keine Kontrolle auf Feature-Ebene und müssen die gesamte Version zurücksetzen, wenn ein Feature fehlerhaft ist. Auch die Definition von Regeln auf Serverebene ist kompliziert, wenn Sie genauer steuern möchten, welche Kunden Zugriff auf ein Feature erhalten.
Canary-Tests durch Feature-Flag-Bereitstellungen: Mit Feature-Flags können Sie für jede Funktion mit einem Ein-/Ausschalter einen Canary-Test durchführen, indem Sie den Anteil des Datenverkehrs auswählen, der für die jeweilige Funktion freigegeben werden soll. Falls eine Funktion einen Fehler aufweist, können Sie sie einfach deaktivieren, anstatt zur vorherigen Version zurückzukehren. Sie können außerdem Zielgruppen-Targeting verwenden, um Funktionen für bestimmte Kunden oder Kundensegmente zu aktivieren (z. B. nur für Kunden des kostenlosen Tarifs).
Wenn Sie mit Feature Flags beginnen möchten, sehen Sie sich unsere kostenlose Lösung an: Optimizely Rollouts.
