Eine effiziente Bereitstellungsstrategie auszuwählen, ist für jedes DevOps-Team eine wichtige Entscheidung. An Optionen mangelt es nicht, aber Sie möchten die Strategie finden, die am besten auf Ihre Arbeit abgestimmt ist.

Ist Ihre Organisation agil? Setzen Sie Continuous Integration und Continuous Delivery (CI/CD) ein? Entwickeln Sie eine Webapplikation? Eine mobile App? Eine lokale Desktop- oder eine Cloud-basierte Applikation? All diese Faktoren und viele weitere bestimmen über die Effizienz einer Bereitstellungsstrategie.

Aber ganz unabhängig von der Strategie dürfen Sie nicht vergessen, dass sich Probleme bei der Bereitstellung nicht vermeiden lassen. Ein „Merge“ kann schief gehen, es können Bugs auftreten oder ein menschlicher Fehler kann in der Produktion problematisch werden. Der Punkt ist, dass Sie sich von der Suche nach der perfekten Bereitstellungsstrategie nicht verrückt machen lassen sollten. Denn diese Strategie gibt es nicht.

Versuchen Sie stattdessen, eine Strategie zu finden, die äußerst belastbar ist und sich an Ihre Arbeitsweise anpassen lässt. Anstatt zu versuchen, unvermeidliche Fehler zu vermeiden, sollten Sie den Code so bereitstellen, dass Fehler minimiert werden und Sie schnell reagieren können, wenn sie dann doch auftreten. Für viele Teams liegt die Lösung dieses Problems in Canary Deployments.

Canary Deployments können Ihnen helfen, Ihren besten Code so effizient wie möglich in die Produktion zu geben. In diesem Artikel werden wir erklären, was Canary Deployments sind und was nicht. Wir gehen auf die Pros und Kontras von Canary Deployments ein, vergleichen sie mit anderen Bereitstellungsstrategien und zeigen Ihnen, wie Sie mit Ihrem Team ganz einfach Canary Deployments durchführen können.

In diesem Artikel greifen wir folgende Punkte auf:

[toc]

Was ist ein Canary Deployment?

Canary Deployments sind Best Practice für Teams, die sich für den Prozess Continuous Delivery entschieden haben. Bei einem Canary Deployment wird ein neues Feature zunächst einer kleinen Teilgruppe von UserInnen zur Verfügung gestellt. Das neue Feature wird je nach Traffic einige Minuten bis mehrere Stunden lang überwacht, oder zumindest so lange, bis aussagekräftige Daten vorhanden sind. Wenn das Team ein Problem feststellt, wird das neue Feature schnell zurückgezogen. Werden keine Probleme festgestellt, wird das Feature für alle UserInnen freigeschaltet.

Der Begriff „Canary Deployment“ hat eine faszinierende Geschichte. Er ist auf die englische Redewendung „Canary in a coal mine“ (Kanarienvogel im Kohlebergwerk) zurückzuführen, als Kanarienvögel oder andere kleine Singvögel in Kohlebergwerken als Frühwarnsystem eingesetzt wurden. Die Bergleute brachten Vögel in Käfigen unter Tage. Wenn die Vögel erkrankten oder starben, war dies ein Warnhinweis dafür, dass sich geruchlose giftige Gase, wie Kohlenmonoxid, ausbreiteten. Ein unmenschliches, aber wirksames Verfahren in Großbritannien und den USA, bis die Kanarienvögel 1986 durch elektronische Sensoren ersetzt wurden.

Ein Canary Deployment macht aus einer Teilgruppe von UserInnen – idealerweise eine fehlertolerante Menge – ein eigenes Frühwarnsystem. Diese Gruppe von UserInnen identifiziert Bugs, fehlerhafte Features und nicht-intuitive Features, bevor Ihre Software einer größeren Zielgruppe zugänglich gemacht wird.

Ihre Canary UserInnen können selbst identifizierte Early Adopters sein, ein demografisch festgelegtes Zielsegment, eine zufallsbedingte Stichprobe, d. h. ein Mix aus UserInnen, der am sinnvollsten ist, um Ihr neues Feature in der Produktion zu überprüfen.

Bei den Überlegungen zu Canary Deployments kann es hilfreich sein, an das Risikomanagement zu denken. Sie können neue, interessante Features regelmäßiger einführen, ohne sich Sorgen machen zu müssen, ob sich eins der neuen Features auf die User Experience aller UserInnen negativ auswirkt.

Canary Releases vs. Canary Deployments

Die Begriffe „Canary Release“ und „Canary Deployment“ werden gelegentlich auch wie Synonyme gebraucht. Aber in DevOps müssen sie unterschieden werden. Eine Canary Release ist ein Test Build einer vollständigen Applikation. Beispielsweise ein nächtlicher Release oder eine Beta-Version.

Manche Teams veröffentlichen Canary Releases oft in der Hoffnung, dass Early Adopters und Power UserInnen, die mit Entwicklungsprozessen besser vertraut sind, die neue Applikation herunterladen, um sie in der Praxis zu testen. Die Browser-Teams von Mozilla und Google und viele andere sind von dieser Release-Strategie begeistert.

Canary Deployments ihrerseits sind das, was wir bereits beschrieben haben. Ein Team veröffentlicht neue Features in der Produktion für Early Adopters oder verschiedene Teilgruppen von UserInnen, die über einen Load Balancer oder ein Feature Flag auf die neue Software geleitet werden. Der Großteil der UserInnen sieht weiterhin die aktuelle, stabile Software.

Canary Deployment – Pros und Kontras

Canary Deployments können als Release Strategie erfolgversprechend und effektiv sein. Aber sie sind nicht für jedes mögliche Szenario die richtige Strategie. Gehen wir auf einige Pros und Kontras von Canary Deployments ein, damit Sie besser entscheiden können, ob sie für Ihr DevOps-Team sinnvoll sind.

Pros

Unterstützung von CI/CD-Prozessen

Canary Deployments bewirken ein schnelleres Feedback zu neuen Features in Produktion. DevOps-Teams erhalten reale Nutzungsdaten schneller, wodurch sie die nächsten Features schneller und deutlich effektiver verfeinern und integrieren können. Solche kurzen Entwicklungsschleifen sind eines der Markenzeichen von Continuous Integration/Continuous Delivery.

Granulare Kontrolle über Feature-Bereitstellungen

Wenn Ihr Team zu kleineren, regelmäßigen Feature-Bereitstellungen schreitet, verringern Sie die Gefahr, dass Ihr Arbeitsablauf durch Fehler unterbrochen wird. Nicht viele UserInnen werden von einem Fehler im Canary Deployment betroffen sein. Diesen Fehler zu beheben, wird nur eine geringfügige Angelegenheit sein. Nicht alle Ihre UserInnen sind betroffen und Sie müssen keine KollegInnen von der geplanten Arbeit abziehen, um ein größeres Produktionsproblem zu lösen.

Realitätsnahe Tests

Interne Tests haben ihre Berechtigung, sind aber kein Ersatz für Test von Applikationen bei realen UserInnen. Canary Deployments sind eine ausgezeichnete Strategie für Tests in einem kleineren Umfang unter realen Bedingungen, ohne die erheblichen Risiken, die Sie eingehen, wenn Sie eine völlig neue Applikation in Produktion geben.

Schnell verbessertes Engagement

Neben besseren technischen Tests können Sie mit Canary Deployments auch schnell feststellen, wie UserInnen mit Ihren neuen Features umgehen. Werden die Sessions länger? Steigen die Kennzahlen für ihr Engagement in diesem Canary Deployment? Wenn keine Fehler gefunden werden, können Sie das Feature allen UserInnen anzeigen.

Sie müssen nicht warten, bis der Test einer umfangreichen Bereitstellung abgeschlossen ist. Binden Sie diese UserInnen ein und fahren Sie mit den nächsten Features fort.

Mehr Daten für Business Cases

Entwickler mögen zwar den Wert ihres Codes erkennen, DevOps-Teams aber müssen gegenüber der Geschäftsleitung und dem gesamten Unternehmen begründen, warum sie mehr Ressourcen brauchen.

Canary Deployments geben schnell Aufschluss darüber, welche Nachfrage für neue Features bestehen könnte. Führen Sie ein Canary Deployment für ein überzeugendes neues Feature bei einer kleinen Gruppe einflussreicher UserInnen durch, damit sie darüber sprechen können. Nutzen Sie Kennzahlen für Engagement und Werbung, um Argumente vorzubringen, warum Sie eine größere neue Initiative in Verbindung mit diesem Feature vorantreiben wollen.

Stärkeres Risikomanagement

Canary Deployments sind im Grunde genommen eine Reihe von Mikrotests. Wenn Sie schrittweise neue Features einführen und sie sukzessive mit Canary-Tests überprüfen, können Sie die Gesamtkosten von Fehlern oder größere Systemprobleme erheblich reduzieren. Sie werden niemals eine größere Version zurücknehmen müssen, einen PR-Schaden erleiden und eine große und komplizierte Codebase überarbeiten müssen.

Kontras

Mehr Betriebskosten

Wie jeder komplexe Prozess haben auch Canary Deployments einige Nachteile. Wenn Sie einen Load Balancer zur Aufteilung von UserInnen für ein Canary Deployment verwenden möchten, brauchen Sie eine zusätzliche Infrastruktur und müssen einen zusätzlichen Verwaltungsaufwand betreiben.

In diesem Szenario erstellen Sie eine zweite Produktionsumgebung und ein zweites Backend neben Ihrer primären Umgebung. Sie haben dann zwei Codebases, zwei App-Server, u. U. zwei Webserver und eine Netzwerkinfrastruktur, die gewartet werden muss.

Alternativ dazu verwenden viele DevOps-Teams Feature Flags, um ihre Canary Deployments auf einem einzigen System zu verwalten. Ein Feature Flag kann UserInnen in einen Canary-Test während der Laufzeit innerhalb einer einzigen Codebasis aufteilen. Canary-UserInnen sehen das neue Feature, während alle anderen den existierenden Code ausführen.

Die Bereitstellung lokaler Applikationen: keine leichte Aufgabe

Wenn Sie eine lokal installierte Applikation entwickeln, laufen Sie Gefahr, dass die UserInnen ein manuelles Update vornehmen müssen, um die neueste Version Ihrer Software zu erhalten. Wenn Ihr Canary Deployment in diesem letzten Update enthalten ist, wird Ihr neues Feature möglicherweise nicht auf allen Client-Systemen installiert, die Sie aber für gute Testergebnisse brauchen.

Mit anderen Worten: Je mehr Ihre Software clientseitig läuft, desto weniger ist sie für Canary Deployments geeignet. Ein vollständiges Canary-Release könnte sich hier besser eignen, um reale Testergebnisse zu erhalten.

UserInnen werden weiterhin mit Softwareproblemen konfrontiert

Ein Canary Deployment soll ein neues Feature zwar nur einigen wenigen UserInnen präsentieren und die breitere User Base auslassen, konfrontiert aber End-UserInnen weiterhin mit einem Code, der nicht ausgiebig getestet wurde. Wenn ein Ausfall eines bestimmten Features bei nur wenigen UserInnen schon zu große negative Auswirkungen für Ihr Unternehmen hat, sollten Sie auf ein Canary Deployment verzichten und strengere interne Tests durchführen.

Wann sollte man auf Canary Deployments verzichten?

Canary Deployments sind zwar eine ausgezeichnete Strategie für Unternehmen, die ständig auf Experimente und Innovationen setzen, sind aber nicht für jeden geeignet. Canary Deployments sind möglicherweise nicht die richtige Strategie, wenn:

• Fehler selbst in kleinen Bereitstellungen zu Regelverstößen bei einem bestimmten System beitragen können. Zum Beispiel im Gesundheitswesen, wenn es um Patientendaten bei einem Produktionssystem geht.
• Der Ausfall eines Dienstes lebensbedrohliche Folgen haben kann, wie z. B. bei Applikationen zur Verwaltung des Stromnetzes oder von Notdiensten.
• Die finanziellen oder organisatorischen Folgen des Ausfalls einer Applikation Ihrem Unternehmen irreparablen Schaden zufügen könnten.

Canary Deployments im Vergleich zu anderen Bereitstellungsstrategien

Canary Deployments sind nur eine mögliche Bereitstellungsstrategie für Ihr Team. Sie werden auch oft mit anderen ähnlichen, aber unterschiedlichen Prozessen wie A/B-Tests verwechselt. Sehen wir uns an, wie sich Canary Deployments mit anderen Bereitstellungsstrategien und ähnlichen Prozessen vergleichen lassen, mit denen sie oft verwechselt werden.

Canary Deployments vs. A/B-Tests

Sowohl bei Canary Deployments als auch bei A/B-Tests werden mehrere Produktionsumgebungen oder mehrere mit Flags versehene Codepfade zum Testen verwendet, wobei aber jedes Mal ein anderes Ziel verfolgt wird. DevOps-Teams nutzen Canary Deployments, um festzustellen, ob bei einer neuen Software technische Probleme vorliegen oder bei der Usability Schwierigkeiten bestehen. Bei einem A/B-Test werden zwei verschiedene funktionierende Varianten für bestimmte Punkte wie Usability und Engagement sowie andere UX-Kennzahlen verglichen, um festzustellen, welche unter bestimmten Bedingungen besser abschneidet.

Canary Deployments vs. Blue-Green Deployments

Canary Deployments werden auch mit Blue-Green Deployments verwechselt. In beiden Fällen können parallele Produktionsumgebungen verwendet werden – die mit einem Load Balancer oder Feature Flag verwaltet werden – um das Risiko von Softwareproblemen zu mindern.

Bei einem Blue-Green Deployment starten diese Umgebungen identisch, aber nur eine empfängt Traffic (der blaue Server). Ihr Team veröffentlicht ein neues Feature für die Hot Backup-Umgebung (den grünen Server). Dann verlagert der Router, das Feature Flag usw. nach und nach neue UserInnen Sessions von dem blauen auf den grünen Server, bis der gesamte Traffic zu 100 % auf dem grünen Server liegt. Nach dem Cutover aktualisiert das Team den jetzt alten blauen Server mit dem neuen Feature, der dann zur Hot Backup-Umgebung wird.

Wie die Umstellung bei den beiden Strategien gehandhabt wird, hängt vom gewünschten Ergebnis ab. Blue-Green Deployments sollen Ausfallzeiten vermeiden. Canary Deployments werden verwendet, um ein neues Feature in einer Produktionsumgebung mit minimalem Risiko zu testen. Canary Deployments sind gezielter.

Wie wird ein Canary Deployment durchgeführt?

Für ein Canary Deployment sind nur wenige Schritte erforderlich:

Identifizieren Sie Ihre Canary-Gruppe

Es gibt verschiedene Möglichkeiten, wie Sie UserInnen als Canary-Gruppe auswählen können.

Zufallsbedingte Teilgruppe

Wählen Sie verschiedene UserInnen wirklich nach dem Zufallsprinzip aus, zum Beispiel mit einem Load Balancer. Aber auch eine Flag Management Software kann einen bestimmten Prozentsatz des gesamten Traffics über ein einfaches Modulo an einen Canary-Test weiterleiten.

Early Adopter

Wenn Sie ein Early Adopter-Programm für besonders engagierte UserInnen durchführen, nutzen Sie diese als Canary-Gruppe. Machen Sie es zum Vorteil ihres Programms. Als Gegenleistung, die Bugs zu tolerieren, auf die sie bei einem Canary Deployment stoßen könnten, bieten Sie ihnen Treueprämien an.

Nach Region

Vielleicht möchten Sie bei Ihrem Canary Deployment auf eine bestimmte Region setzen. Legen Sie zum Beispiel fest, dass Ihr Canary Deployment in den späten Abendstunden an europäische IPs geleitet wird. So vermeiden Sie, dass UserInnen tagsüber Ihre neuen Features sehen, erhalten aber eine Handvoll UserInnen Sessions nach Feierabend.

Interne Testpersonen

Sie können jederzeit Sessions aus Ihren internen Subnetzen als Canary Deployment konfigurieren.

Entscheiden Sie sich für Ihre Canary-Kennzahlen

Zweck eines Canary Deployments ist, eine klare Antwort mit „Ja“ oder „Nein“ auf die Frage zu erhalten, ob Ihr Feature sicher ist, um es in die Produktion zu geben. Um diese Frage zu beantworten, müssen Sie zunächst entscheiden, welche Kennzahlen Sie verwenden wollen, und dann die Mittel zur Überwachung der Performance installieren.

Sie können zum Beispiel Folgendes überwachen:

• die Anzahl der internen Fehler
• CPU-Auslastung
• Speicherauslastung
• Latenzzeit

Sie können die Feature Management-Software schnell und einfach anpassen, um die Performance-Analyse zu überwachen. Diese Plattformen können sich als ausgezeichnete Tools erweisen, um die Experimentierkultur anzuregen.

Entscheiden Sie, wie sich der Übergang vom Canary Deployment zum vollständigen Deployment darstellen soll

Wie bereits erwähnt, sollten Canary-Releases nur einige Minuten bis Stunden dauern. Sie sind nicht für lange Experimente bestimmt. Aufgrund dieser knappen Zeit sollte Ihr Team bereits am Anfang entscheiden, wie viele UserInnen oder Sessions in die Canary-Phase eingebunden werden und wie zur vollständigen Bereitstellung übergegangen werden soll, sobald die Kennzahlen positive Benchmarks erreicht haben.

Sie können zum Beispiel ein zufälliges Canary Deployment von 5/95 wählen. Konfigurieren Sie ein Feature Flag, um 5 Prozent Ihrer UserInnen zufallsbedingt in den Canary-Test zu verschieben, während die restlichen 95 Prozent auf der stabilen Produktionsversion bleiben. Sind die Ergebnisse positiv, entfernen Sie das Flag und stellen das Feature vollständig bereit.

Vielleicht möchten Sie aber auch einen eher konservativen Ansatz wählen. Bei einer weiteren beliebten Canary-Strategie wird ein Canary-Test logarithmisch bereitgestellt, d. h. man geht von einer Stichprobe von einem Prozent auf zehn Prozent, sieht, wie das neue Feature einer höheren Last standhält, und erhöht dann auf 100 Prozent.

Bestimmen Sie die Infrastruktur

Sobald sich Ihr Team einig ist, müssen Sie sicherstellen, dass die gesamte Infrastruktur passt, damit Ihr Canary Deployment reibungslos verläuft.

Sie brauchen ein System zur Aufteilung der User Base und zur Leistungsüberwachung. Sie können die Aufteilung mit einem Router oder Load Balancer vornehmen, aber auch direkt in Ihrem Code mit einem Feature Flag. Feature Flags sind oft kostengünstiger und schneller einzurichten und können leistungsfähiger sein.

Verwenden Sie Feature Flags für bessere Canary Deployments

Auf den Punkt gebracht ist ein Feature Flag nichts anderes als eine „if“-Anweisung, ab der UserInnen während der Laufzeit verschiedenen Codepfaden abhängig von einer oder mehreren Bedingungen folgen. Bei einem Canary Deployment lautet diese Bedingung, ob der oder die UserIn der Canary-Gruppe angehört oder nicht.

Feature Flag – Beispiel

Angenommen, wir betreiben eine vollkommen neue Social Network Website für E-Sport-Fans. Unser DevOps-Team hat hart an einer Content-Empfehlungsfunktion gearbeitet, die UserInnen basierend auf den angeschauten Livestreams Empfehlungen in Echtzeit gibt. Das Team hat dieses Empfehlungsfeature so verbessert, dass es deutlich schneller ist. In internen Tests hat es sich gut bewährt. Jetzt wollen sie sehen, wie es sich unter realen Bedingungen schlägt.

Das Team möchte für ein Canary Deployment keine Zeit und kein Geld in die Installation einer neuen physischen Infrastruktur investieren. Stattdessen beschließt das Team, ein Feature Flag zu verwenden, um die neue Empfehlungsmaschine zufallsbedingt 5 % der UserInnen-Base zugänglich zu machen.

Das Feature Flag teilt die UserInnen mit einem einfachen Modulo in zwei Gruppen auf, wenn sie einen Livestream laden. Innerhalb weniger Minuten erhält Ihr Team die Ergebnisse von einigen Tausend User Sessions mit dem neuen Code. Tatsächlich wird der Stream schneller geladen und das Engagement der UserInnen verbessert. Aber es kommt zu einem unerwarteten Spike bei der CPU-Auslastung auf dem Produktionsserver. Das Ops-Team erkennt, dass die Leistung sinkt und „killt“ das Canary-Flag.

Das Team beschließt, mit dem Rollout erst fortzufahren, wenn es bei dem neuen Code die Ursache für die unerwartete Spitze der CPU-Auslastung auf dem Server beheben kann. Dank der realen Testergebnisse des Canary Deployments hat das Team eine relativ gute Vorstellung davon, was passiert ist, und macht sich wieder an die Arbeit.

Canary Deployments sind ein wesentlicher Bestandteil Ihres DevOps-Toolkits

Die Strategien der Softwarebereitstellung haben sich in den letzten Jahrzehnten rasant weiterentwickelt. Canary Deployments zählen zu den leistungsstärksten Strategien, die nun für Teams verfügbar sind, die DevOps-Methoden wie CI/CD folgen möchten.

Canary Deployments sind effiziente Strategien, da sie aussagekräftige Daten schnell bereitstellen und liefern können und für nahezu jede App oder jedes Feature eingesetzt werden können, die getestet werden sollen. Sie bieten Ihrem Team schnelles Feedback, wodurch Entwicklungszyklen verkürzt und neuer Code schneller in Produktion gegeben werden kann. Tests des Canary Deployments bieten aussagekräftige Ergebnisse, die Ihnen helfen, dem Unternehmen Business Cases für neue Initiativen aufzustellen.

In diesem Artikel haben wir erklärt, was Canary Deployments sind, welche Vor- und Nachteile sie haben, wie sie im Vergleich zu anderen Bereitstellungsstrategien abschneiden und wie Sie bei der Planung eines Canary Deployments in Ihrem Team vorgehen können. Es gibt viele Management-Tools für Deployments, aber Feature Flags sind möglicherweise die effektivste Option, die Ihr DevOps-Team schon heute nutzen kann.

Feature Flags optimieren und vereinfachen das Testen von Canary Deployments. Features Flags verringern den Bedarf einer zweiten Produktionsumgebung. Mit einer Feature Management Software wie Flagship sind anspruchsvolle Tests und Analysen möglich. Ganz gleich, für welche Methode Sie sich entscheiden, Canary Deployments helfen Ihnen, Ihren UserInnen die beste Software schnell zur Verfügung zu stellen.

Teilen auf

LinkedIn Facebook Twitter

Feature Toggles zählen zu den leistungsfähigsten Methoden, wenn es um die Unterstützung von Continuous Integration und Continuous Delivery (CI/CD) geht. Feature Toggles – auch Feature Flags genannt – sind eine Methode, mit der Features während der Laufzeit geändert werden können, ohne dabei den Code zu ändern.

Entwickler können zum Erstellen von Features Toggles einen „Decision Point“ coden, an dem das System ein bestimmtes Feature ausführt, abhängig davon, ob bestimmte Bedingungen erfüllt werden oder nicht. Mit anderen Worten, mit Feature Toggles können Sie kontextsensitive Software schnell und effizient ausliefern.

Feature Toggles haben viele Einsatzmöglichkeiten, von der Unterstützung der agilen Entwicklung bis hin zu Markttests und zur Optimierung laufender Operationen. Hinter dieser Fähigkeit steckt aber auch die Gefahr, dass Ihr Code unnötig komplexer wird. Sie müssen mit Feature Toggles richtig umgehen können, um das Beste aus ihnen herauszuholen.

In diesem Artikel bieten wir Ihnen einen Überblick darüber, was Feature Toggles bewirken und wie Sie sie in Ihren Entwicklungs- und Produktionsumgebungen implementieren können. Darüber hinaus stellen wir Ihnen einige Best Practices vor, die wir zur Verwendung dieser Toggles empfehlen.

[toc content=“.entry-content“]

Was genau ist ein Feature Toggle?

Einfach gesagt ist ein Feature Toggle ein leistungsstarkes „If“-Statement, ab dem während der Laufzeit mindestens einem oder zwei verschiedenen Codepfaden abhängig von einer oder mehreren Bedingungen gefolgt wird. Hier ein konkretes Beispiel:

normalFeature = {
‚id‘: 1,
‚description‘: u’basic service‘,
’newstuff‘: False
}

testFeature = {
‚id‘: 2,
‚description‘: u’much better service‘,
’newstuff‘: True
}

@app.route(‚/ourapp/api/v1.1/storefront‘, methods=[‚GET‘])
def get_tasks():
if internalTester == True:
return jsonify({‚feature‘: testFeature})
else:
return jsonify({‚feature‘: normalFeature})

Hier haben wir zwei verschiedene generische Features definiert: normalFeature und testFeature. Während der Laufzeit prüft die Applikation in der Konfiguration, ob das Feature von einem oder einer interne(n) Test-UserIn geladen wird. Wenn ja, lädt die Applikation das Test-Feature, das sich in der Entwicklung befindet. Wenn nicht, sieht der oder die „normale“ KundIn das aktuelle Feature.

Feature Toggles können alles sein, ein einfaches „If“-Statement oder komplexe Entscheidungsbäume, die auf viele verschiedene Variablen einwirken. Um festzulegen, welche Richtung ein Toggle nehmen soll, können zahlreiche Bedingungen verwendet werden, u. a. Ergebnisse von Tauglichkeitstests aus anderen Features in der Codebase, eine Einstellung in der Feature Management Software oder eine Variable aus einer Konfig-Datei.

Verschiedene Feature Toggles für verschiedene Aufgaben

Gehen Sie mit Feature Toggles jeweils unterschiedlich um, je nachdem, wie Sie sie bereitstellen möchten. Es kann nützlich sein, Toggles in Kategorien nach zwei Aspekten zu unterteilen: wie lange Toggles in der Entwicklung sind bzw. live geschaltet bleiben und wie dynamisch ihre Funktion ist. Demzufolge können wir Feature Toggles in vier verschiedene Kategorien unterteilen:

• Release Toggles
• Experiment Toggles
• Ops Toggles
• Permission Toggles

Ein Diagramm der vier Kategorien der Feature Toggles (Quelle)

Release Toggles

Diese Toggles unterstützen Entwicklerteams, wenn sie neue Features schreiben. Statt einen Zweig zu erstellen, in dem das Team das neue Feature schreibt, generiert es ein Release Toggle in der Master Codebase, wobei der Code inaktiv bleibt, während an ihm gearbeitet wird. Die Entwickler können den Trunk Code nach wie vor in die Produktion geben, um ihre Auslieferungsziele zu erfüllen.

Release Toggles sollen in der Regel kein fester Bestandteil Ihrer Codebase sein. Sobald das zugehörige Feature endgültig ist, sollten die Toggles entfernt werden. In der Praxis bedeutet dies in der Regel, dass diese Toggles einen Lebenszyklus von einigen Tagen bis zu einigen Wochen durchlaufen und sich in puncto Langlebigkeit somit auf einer Skala im unteren Bereich befinden. Release Toggles sind auch nicht besonders dynamisch. Entweder steht das Feature zur Freigabe bereit oder nicht.

Beispiel für ein Release Toggle

Ein e-Commerce-Unternehmen entwickelt auf Anfrage eines hochkarätigen Kunden eine neue Konfiguratorfunktion. Der Konfigurator überwacht Artikel, die der Kunde bereits zusätzlich ausgewählt hat, und schlägt Artikel-Sets vor, um seine Bestellung abzurunden.

Das Unternehmen möchte dieses Feature im Endeffekt allen Kunden anbieten. Aber derzeit funktioniert der Konfigurator nur nach den Vorgaben dieses einen Kunden. Das Entwicklerteam dieses Konfigurators aktiviert für dieses neue Feature ein Release Toggle, das es inaktiv lässt.

Experiment Toggles

Diese Toggles werden verwendet, um A/B-Tests oder multivariable Tests einfacher zu machen. Sie erstellen einen Toggle Point, hinter dem zwei oder mehrere Codepfade mit den zu testenden Features liegen. Während der Laufzeit teilt das System – oder das Toggle selbst – Nutzer in verschiedene Kohorten auf, an denen diese Features getestet werden.

Durch die Verfolgung aggregierter Experience-Daten bei jeder Kohorte können Sie die Wirkung der verschiedenen Features vergleichen. Experiment Toggles sind eine beliebte Methode für die Optimierung von Marketing-Initiativen, User Experiences und anderer Features für UserInnen.

In der Regel sollten Experiment Toggles nur so lange existieren, bis keine Daten zum Feature-Testing mehr gesammelt werden müssen. Der exakte Zeitrahmen hängt vom Traffic-Volumen bei diesem Feature ab, beläuft sich aber in der Regel auf mehrere Wochen bis mehrere Monate. Diese Einschränkung bezieht sich eher auf den Test selbst als auf das Toggle. Der Nutzen der gesammelten Daten verliert sich im Laufe der Zeit, wenn andere Feature- und Code-Updates Vergleiche mit zuvor gesammelten Nutzerdaten entkräften.

Beispiel für ein Experiment Toggle

Unser e-Commerce-Unternehmen hat die Fehler in seinem neuen Konfigurator beseitigt. Aber es wird darüber diskutiert, welcher der beiden Vorschlagsalgorithmen die beste Experience bietet. Man entschließt sich für einen A/B-Test, um Daten aus der realen Welt zu erhalten.

Das Unternehmen fügt ein Experiment Toggle zum Produktionskonfigurator mit zwei verschiedenen Vorschlagsalgorithmen dahinter hinzu. Das Toggle teilt die UserInnen in zwei Kohorten mit einem Modulo auf, wenn sie versuchen, den Konfigurator zu laden. Nach drei Wochen ist das Team der Meinung, endgültige Daten zu haben, die zeigen, dass mehr UserInnen ihre Bestellungen mit dem Algorithmus B abschließen. Das e-Commerce-Unternehmen entfernt das Experiment Toggle und der Algorithmus B wird für alle UserInnen live geschaltet.

Ops Toggles

Ops Toggles werden zum Abschalten von Features verwendet – wie ein „Kill Switch“ – oder um die Performance der Features anzupassen. Wenn zum Beispiel bestimmte Bedingungen nicht erfüllt werden und etwa KPI-Ziele unter einem Schwellenwert liegen, schaltet das Toggle das betreffende Feature ab, bis sich die Bedingungen verbessern. Ops Toggles sind für die Programmierung neuer Features kurz nach dem Testing oder bei ressourcenintensiven Features nützlich.

Die Langlebigkeit von Ops Toggles hängt von den jeweiligen Anwendungsfällen ab. Wenn Sie ein Ops Toggle zum Einstellen eines neuen Features kurz nach der Entwicklung verwenden, dann brauchen Sie das Toggle wahrscheinlich nur ein paar Monate. Ein Kill Switch-Toggle wird in der Regel jedoch als permanenter Bestandteil des Codes erstellt. Ops Toggles sind in der Regel genauso statisch oder dynamisch wie die Bedingungen, unter denen das kontrollierte Feature genutzt wird. Beispielsweise sind Ops Toggles tendenziell relativ statisch, wenn sie nur mit einer Leistungskennzahl verbunden sind.

Beispiel für ein Ops Toggle

Unser e-Commerce-Unternehmen bereitet sich auf eine Traffic-Spitze für den jährlichen Schlussverkauf vor. Das ist der erste Sale, bei dem der Konfigurator in der Produktion ist. Während der Tests haben die Entwickler festgestellt, dass der vom User bevorzugte B-Algorithmus Systemressourcen stark beansprucht.

Die Operators verlangten einen Kill Switch für den Konfigurator, bevor die Sales-Angebote live geschaltet wurden. Sie wollten nur ein einziges Toggle, auf das sie in der Release Management Software klicken mussten, falls die Performance nachlassen sollte. Und siehe da, am ersten Tag des Schlussverkaufs begann die Performance beim Konfigurator zu fallen. Und das Ops-Team konnte das Feature schnell abschalten, bevor es von zu vielen UserInnen wahrgenommen wurde.

Permission Toggles

Permission Toggles sollen langlebiger sein oder sogar ein fester Bestandteil in Ihrem Code. Sie werden als Methode verwendet, um einem bestimmten Teil von UserInnen Features anzuzeigen. Beispielsweise können Sie ein Permission Toggle verwenden, um ausschließlich Premium UserInnen auf Ihrer Website Premium Inhalte anzubieten. Permission Toggles sind generell die dynamischsten Toggles unter den vier hier definierten Kategorien, da sie in der Regel für eine oder einen UserIn getriggert werden.

Beispiel für ein Permission Toggle

Das einfache Beispiel am Anfang dieses Artikels lässt sich praktisch mit einem Permission Toggle vergleichen. Nach dem jährlichen Schlussverkauf ist unser e-Commerce-Unternehmen der Meinung, Algorithmus B sei zu ressourcenintensiv, um das Feature allen UserInnen anzuzeigen. Stattdessen entscheidet sich das Unternehmen, ein Premium Feature zu erstellen. Das Permission Toggle kann sich wie folgt darstellen:

normalFeature = {
‚id‘: 1,
‚description‘: u’basic service‘,
‚configurator‘: False
}

premiumFeature = {
‚id‘: 2,
‚description‘: u’the better configurator‘,
‚configurator‘: True
}

@app.route(‚/ourapp/api/v1.1/storefront‘, methods=[‚GET‘])
def get_tasks():
if premiumUser == True:
return jsonify({‚feature‘: premiumFeature})
else:
return jsonify({‚feature‘: normalFeature})

Feature Toggles vs. Feature Flags

Eine kleine Randbemerkung: Es gibt einige Diskussionen über den Begriff Feature Toggle verglichen zum Begriff Feature Flag. „Toggle“ trifft eher zu, wenn der Code bei mehreren Hauptzweigen des Codes ein- oder ausgeschaltet ist. „Flag“ trifft eher zu, wenn auf einen Entscheidungspunkt multikonditionale oder eine große Anzahl an Codepfaden folgen.

Feature Toggles in Ihre Roadmap zur Unterstützung agiler Workflows integrieren

Mit Feature Toggles in Ihrem Entwicklungsprozess werden neuere agile Ansätze unterstützt. Sie können eine Software veröffentlichen, während noch Code Sprints für neue Features bearbeitet werden. Diese Features müssen lediglich hinter Toggles verborgen werden, bis sie für die Veröffentlichung, Marketingtests oder den nächsten Schritt im Entwicklungsprozess tauglich sind.

In der Regel würden Sie die kürzlich vom User oder von der Userin gewünschten Features auf Code-Verzweigungen unter einem eher herkömmlichen Wasserfallmodell schreiben. Diese Features würden im Anschluss einen langen Test- und QA-Prozess durchlaufen, bevor Ihr Team die Features wieder in den Trunk Code zurückführen kann. Mit Feature Toggles können Sie den gesamten Entwicklungs- und Testprozess direkt auf dem Trunk Code durchführen.

Unsere Best Practices für die Verwendung von Feature Toggles

Wie bereits erwähnt, stehen Feature Toggles für eine leistungsstarke und flexible Entwicklungsmethode. Wenn Sie Ihre Toggles nicht sorgfältig implementieren und managen, können sie schnell eine chaotische Codebase erhalten.

Es wurden viele verschiedene Best Practices zum Coden von Feature Toggles  vorgeschlagen, aber wir wollten Ihnen einige unserer eigenen Toggles anbieten. Sobald ein unsauberer Entscheidungspunkt in Ihre Codebase geschrieben wird, scheinen viele weitere zu folgen. Wenn diese Best Practices von Anfang an befolgt werden, können Sie solche Probleme in Schach halten.

Verwenden Sie Feature Toggles, um langsam zur agilen Entwicklung zu wechseln

Wenn Ihr Team agile Entwicklungs- und Testmethoden ausprobieren möchte, ohne sich völlig in eine neue Entwicklungsmethode stürzen zu müssen, dann sind Feature Toggles in Ihrer Roadmap ein ausgezeichnetes Mittel für den Anfang. Die Kosten für diese Versuche sind gering. So könnte zum Beispiel zunächst nur ein Team ein Experiment Toggle für einen ersten Canary Release verwenden.

Wenn der Versuch gelingt, können Sie das Experiment Toggle durch ein Ops Toggle ersetzen, wenn das Feature in die Produktion geht. Dann weiten Sie die Nutzung des Toggles auf andere Teams oder Prozesse aus. Führen Sie dieses Toggle früher in die Entwicklungszyklen ein als Release Toggles. Dann sind Sie langsam aber sicher auf dem Weg zur völlig agilen Entwicklung.

Verwenden Sie Toggles sowohl für interne als auch externe Features

Jetzt müsste klar sein: Feature Toggles haben während des gesamten Entwicklungs- und Produktionslebenszyklus Ihrer Software Ihren Zweck. Schränken Sie die Toggle-Nutzung nicht auf Features ein, die nur von KundInnen gesehen werden. Sie können Release und Ops Toggles auch für Backend-Features verwenden. Die Toggles bieten DevOps Teams eine besonders granulare Stufe beim Kontroll- und Risikomanagement des Codes, was wichtig sein kann, wenn Backend-Features geändert werden, die einen entscheidenden Einfluss darauf haben, wie Ihr System performt.

Lassen Sie die Toggle-Planung in Ihre Design-Phase einfließen

Vom Toggle-Namen und den Konfigurationseinstellungen bis zum Entfernen der Toggles und der Zugangskontrolle – alles hängt davon ab, wie Sie neue Features gleich zu Beginn entwerfen. Bauen Sie diese Toggle-Planung in Ihren Designprozess ein und die nächsten sechs Monate Ihres Feature Managements werden um einiges einfacher sein.

Verwenden Sie ein standardisiertes Toggle Namensschema

Viele Unternehmen verwenden einen Style Guide für Entwickler, der festlegt, wie sie Code schreiben und organisieren sollen, wie sie zum Beispiel Abstände, Reihenfolge und Klammern beim Naming anwenden. Wenn Sie Feature Toggles verwenden wollen, sollten Sie auch den Naming-Stil schon frühzeitig im Einführungsprozess Ihrer Toggles standardisieren.

Kurz und bündig zu sein, ist beim Coden für andere Aspekte wichtig. Wenn es aber um Toggle-Namen geht, seien Sie ausführlich. Details bedeuten Klarheit. Ausführliche Toggle Namen helfen Entwicklern und Ops Teams außerhalb Ihres Kernteams zu verstehen, was sie prüfen, wenn ihr einziger Bezug der Toggle Name ist, den Sie sechs Monate zuvor aus einer Laune heraus gewählt haben.

Einige weitere Toggle-Namenskonventionen, die wir vorschlagen:

• Binden Sie den Namen des Teams oder Projekts ein.
• Binden Sie das Datum ein, an dem das Toggle erstellt wurde.
• Identifizieren Sie die Kategorie des Flags.
• Beschreiben Sie das tatsächliche Toggle-Verhalten.

Hier ein Beispiel: algteam_10-12-2021_Ops_configurator-killswitch

Dieser Name bietet einige nützliche Informationen, aus denen jeder oder jede in einem Team ableiten kann, worum es sich handelt, wenn ein Toggle in einer Fehlermeldung genannt wird. Sie wissen, wer das Toggle geschrieben hat, wie lange es in der Codebase war und was das Toggle bewirkt.

Unterschiedliche Toggles unterschiedlich handhaben

Es scheint selbstverständlich, ist aber ein wichtiger Punkt, den es hervorzuheben gilt. Wie wir bereits oben erwähnt haben, können Feature Toggles in vier allgemeine Kategorien unterteilt werden. Sie sollten die einzelnen Kategorien unterschiedlich handhaben.

Denken Sie an den oben erwähnten Konfigurator, als er die Entwicklungsphase, dann Markttests und anschließend den laufenden Betrieb durchlief. Der Konfiguratorcode befand sich die gesamte Zeit hinter einem dieser Features Toggles. Aber die Art und Weise, wie die Entwicklungs- und Produktteams mit diesem Toggle interagieren, muss in jedem Stadium geändert werden.

Zu Beginn der Entwicklung kann das Toggle einfach in der Versionskontrolle konfiguriert werden. Während das e-Commerce-Unternehmen A/B-Tests durchführt, kann das Toggle auf einer Feature Management-Plattform sein. Wenn das Ops-Team einen Kill Switch hinzufügt, kann es sich entscheiden, es in derselben Feature Management-Plattform, aber auf einem anderen Dashboard zu lassen.

AB Tasty Flagship Dashboard (Source)

Feature Toggle-Konfigurationen immer darlegen

Wie bei jedem anderen Codeobjekt auch, ist es besser, Feature Toggle-Konfigurationen als Metadaten zu dokumentieren, damit andere Entwickler, Tester und Produktionsteams ein Dokument in Papierform haben, dem sie folgen können, um genau zu verstehen, wie Ihr Feature Toggle in einer bestimmten Umgebung läuft. Am besten, Sie speichern Ihre Toggle-Konfiguration in einem für Menschen lesbaren Format, damit auch andere außerhalb Ihres Teams verstehen, was ein Toggle bewirkt.

Diese Best Practice ist für die Features nützlich, bei denen längerfristig Toggles verwendet werden sollen. Denken Sie wieder an unser Konfiguratorbeispiel. Ein völlig neuer Product Operator, der versucht, einen plötzlichen, unerwarteten Performance-Rückgang zu verstehen, würde sehr dankbar für eine Datei sein, die für Menschen lesbar ist und ihm erklärt, dass der B-Algorithmus bei Tests ein Jahr zuvor plötzlich ressourcenintensiv wurde.

Behalten Sie die Haltekosten für Feature Toggles im Auge

Wenn Sie Feature Toggles zum ersten Mal benutzen, sollten Sie sich nicht hinreißen lassen, alle auf einmal überall im Code zu verwenden. Feature Toggles lassen sich zwar einfach erstellen, müssen aber richtig gehandhabt und getestet werden, um einen wirklichen Nutzen zu ziehen. Setzen Sie nach und nach mehr Feature Toggles ein oder ziehen Sie die Integration einer Feature Management-Plattform in Ihre Entwicklungs- und Ihre Testumgebung in Betracht.

Stellen Sie Feature Toggles strategisch bereit und halten Sie Ihren Toggle-Bestand so niedrig wie möglich. Verwenden Sie sie, wenn es notwendig ist. Aber überprüfen Sie, ob Toggles die angemessene Methode für die Lösung eines bestimmten Problems sind.

Lassen Sie keine alten Toggles in Ihrem Code. Streichen Sie die Toggles zusammen, sobald sie ausgedient haben. Je mehr inaktive Toggles im Code, desto größer der Mehraufwand für Ihr Team, diese Toggles zu managen. Sie können Toggles entfernen, wenn Sie Code Cleanups auf die To-Do-Liste Ihrer Teams setzen oder diesen Prozess in Ihre Management-Plattform integrieren.

Halten Sie den Toggle Scope möglichst klein

Aufgrund der Wirkung der Toggles neigt man dazu, große Codeabschnitte von einer komplexen Toggle-Reihe zu steuern. Bleiben Sie „standhaft“ und halten Sie den Toggle Scope bei jeder Aufgabe möglichst klein.

Sollte ein Toggle auf mehrere Features übergreifen, kann es für den Rest des Teams zum Albtraum werden, Bugs zu beheben, die Wochen oder Monate zurückliegen und sich jetzt auf die Arbeit des Teams auswirken.

Nehmen wir noch einmal unser Konfiguratorbeispiel. Unser Dev-Team erstellt vier separate Widgets, die der oder die UserIn im Konfiguratortool benutzt. In diesem Szenario würden wir fünf Toggles empfehlen: eins für den Konfigurator selbst und eins für jedes einzelne Widget. Coden Sie die Widget Toggles abhängig vom Konfigurator-Toggle. Wenn in diesem Framework eines der Widgets nicht richtig lädt, werden die anderen dem oder der UserIn angezeigt.

Feature Toggles können den gesamten Entwicklungsprozess verändern

Feature Toggles sind für die Entwicklung, Tests und Steuerung von Code Features im Framework der Continuous Integration und Continuous Delivery eine wirkungsvolle Methode. Sie stehen für eine einfache Methode, mit der Ihr Team einen stabileren Code höherer Qualität nach agilen Prinzipien ausliefern kann.

In diesem Artikel haben wir erklärt, wie Feature Toggles funktionieren, welche Toggles Sie erstellen und wie Sie diese Toggles in Ihrem agilen Prozess verwenden – oder sie in einem Entwicklungsprozess ausprobieren können. Darüber hinaus haben wir Ihnen einige unserer empfohlenen Best Practices vorgestellt, damit Ihr Unternehmen das Beste aus Feature Toggles herausholen kann.

Fangen Sie klein an, um im größeren Rahmen fortzufahren

Es gibt keinen Grund, nicht schon heute Feature Toggles zu nutzen. Fangen Sie klein an und nutzen Sie zunehmend mehr Features Toggles, wenn Ihr Team sich daran gewöhnt und verstanden hat, wie diese Toggles funktionieren. Wenn Sie gerade beginnen, ein vollkommen neues Feature zu coden, richten Sie ein Release Toggle im Trunk Code ein. So brauchen Sie keine Verzweigung. Wenn Sie mit Markttests beginnen, richten Sie ein Experiment Toggle für Split Testings ein.

Wenn Ihr Team sich im Klaren ist, wie es Feature Toggles verwenden möchte, ziehen Sie eventuell eine Feature Management-Plattform für eine optimierte Administration der Toggles in Betracht. Die Optimierung von Entwicklung und Testing war genau das, woran wir gedacht hatten, als wir Flagship, unsere Release- und Feature Management-Plattform, entwickelt haben.

Mit Flagship hat Ihr Team das richtige Tool zur Hand, um Toggle Workflows und Kommunikation zu optimieren. Unabhängig von den Aufgaben oder dem Fokus eines Teams bringt Flagship, unser Feature Management-Tool, alle Voraussetzungen mit, um die richtigen Features auf richtige Weise bereitzustellen.

Teilen auf

LinkedIn Facebook Twitter