Die 6 Arten von Feature Flags, die Sie bei Optimizely kennenlernen werden: Feature-Rollouts

Tl;dr

🔒AccessLevel? Jeder Ingenieur bei Optimizely.
😬Risiko-Level? Hängt davon ab, was eingeführt werden soll.
👩‍💻Tests? Einheit, Integration, End-to-End und manuell (alle Tests!)
⏰Lebensdauer? Kurz. Entfernen Sie diese, sobald die Funktionen angenommen sind.

Feature-Rollouts sind eine Methode der trunk-basierten Entwicklung , die unsere Entwickler nutzen, um Continuous Delivery zu praktizieren. Teams können Code in einen gemeinsamen Integrationszweig (Master) einchecken und diesen Zweig jederzeit in die Produktion überführen. Dies gibt den Entwicklungsteams die Flexibilität, selbst zu bestimmen, wann sie ein Feature veröffentlichen möchten, anstatt auf die Bereitstellung von Code zu warten. Feature Flags ermöglichen es, dass die Bereitstellung eine interne Workflow-Entscheidung ist und die Freigabe des Codes für die Produktion eine geschäftliche Entscheidung ist.

Diese Flexibilität ist zwar eine nette Funktion, aber die wirkliche Stärke liegt in der Möglichkeit für Ingenieure, mit einem einzigen Mausklick zu kontrollieren, wie viel von ihrer Funktion für ihre Kunden zugänglich ist. Entwicklungsteams können eine bestimmte Gruppe von Kunden auswählen, für die sie ihre Funktion freigeben (Beta-Kunden), oder eine bestimmte Anzahl von Kunden (20% der Produktion). Wenn die Funktion funktioniert, können sie die Funktion für alle Kunden freigeben. Wenn etwas schief geht, können sie die Änderung komplett zurücknehmen und so das Risiko bei der Freigabe der Funktion minimieren. Da diese Flaggen dazu dienen, eine permanente Funktion bereitzustellen, muss die Feature Flagge entfernt werden, sobald die Funktion angenommen wurde.

Wie verwenden wir Feature-Rollouts bei Optimizely?

Foto von SpaceX

Das Optimizely Entwicklungsteam liefert fast alle unsere Funktionen über Feature-Rollouts aus. Es gibt ein paar Ausnahmen, bei denen dies nicht der Fall ist (Verschönerung des Codes, externe Dokumentation, interne Dokumentation, kleine Fehlerbehebungen), aber die meisten unserer Funktionen werden über ein Feature-Rollout bereitgestellt.

Der allgemeine Lebenszyklus eines typischen Feature-Rollouts sieht wie folgt aus:

1. In der Phase der technischen Entwurfsdokumentation besprechen der Entwickler und das Produktteam:
   1. Das Design der neuen Funktion
   2. Risiko des Rollbacks (siehe den Abschnitt über Risiken weiter unten)
   3. Einführungsstrategie(gestaffelte Rollouts)
   4. Entfernungsstrategie und Ausstiegskriterien (wann und wer wird diese Markierung entfernen)
2. Der Entwickler erstellt die Funktion:
   1. Beendet die Codierung und erstellt die Funktion
   2. Fügt das Optimizely Feature Flag hinzu, um das Feature zu aktivieren
   3. Fügt Unit-Tests der neuen Komponente hinzu, die hinter dem Feature Flag steht
   4. Fügt alle E2E-Tests hinzu (siehe unten den Abschnitt über Tests)
3. Der Entwickler erstellt einen Pull Request und verknüpft ein Feature Flag Jira-Ticket mit dem PR, um ihn zu verfolgen und zu steuern. Das Jira-Ticket enthält die folgenden Informationen:
   1. Owner des Feature Flags
   2. Risiko für Rollback
   3. Details zum Feature Flag on vs. off und dem Ort des Repositorys
   4. In welchem Status sich das Flag derzeit befindet (In Entwicklung, Testen, Ausrollen, Bereitgestellt, Bereit zum Entfernen, Entfernt)
4. Das Produkt verwendet dann das Feature Flag, um das neue Feature bereitzustellen. Die Bereitstellung erfolgt in der Regel in den folgenden Schritten:
   1. Ein Targeting wie QA oder eine Beta-Kundengruppe - Dies ist unsere Canary-Testing-Phase und ermöglicht es uns, in der Produktion zu testen.
   2. Erhöhung des Verkehrsaufkommens - Wir beginnen damit, die Funktion auf einen größeren Teil unserer Kundenbasis auszuweiten. Je nach dem Risiko, das wir mit unserer Änderung verbinden, und dem Umfang bzw. der Auswirkung unserer Änderung können wir uns für einen kleineren Prozentsatz (15-45%) oder einen größeren (60-80%) entscheiden. Indem wir den Datenverkehr an unsere neue Funktion senden, können wir die Protokollierung überprüfen und sicherstellen, dass die Funktion bei der Skalierung korrekt funktioniert. Dieser Rollout-Prozess verringert den Radius, in dem die Funktion mit Fehlern behaftet ist.
   3. Das Produkt ist vollständig ausgerollt - Unsere Funktion ist nun vollständig implementiert.
   4. Feature Flag wird entfernt - Sobald unser Ausstiegskriterium(d.h. Flag ist vollständig ausgerollt und wird 30 Tage lang ohne Zwischenfälle verwendet) erfüllt ist, um unser Feature Flag zu entfernen, werden die Teams dieses Feature entfernen. Einige Teams machen es zu einem Teil ihrer Anforderungen für "Feature Complete", die Flagge zu entfernen. Andere verlassen sich darauf, dass unser Tag zur Entfernung von Feature Flags sie anpingt, um ihre Flaggen zu entfernen.

Beispiel einer Pull-Anfrage

Wer darf Änderungen an Feature-Rollouts vornehmen?

Bei Optimizely arbeiten mehrere Teams eng zusammen, so dass alle Ingenieure Zugriff auf alle Feature-Rollouts Flags haben (es kann sein, dass mehrere Teams ein Flag oder eine Publikumsbedingung für dieses Flag verwenden). Wir prüfen jedoch den Änderungsverlauf, um zu sehen, wer Änderungen an einer Flagge vorgenommen hat, und bitten Sie, bei Änderungen das verknüpfte Jira-Ticket mit Ihrer Begründung zu aktualisieren. Die Kombination dieser beiden Methoden verschafft den Technikern Klarheit darüber, was mit dem Rollout geschieht.

Wie hoch ist das Risiko bei der Verwendung eines Feature-Rollouts?

Wir kategorisieren das Risiko für unsere Rollouts auf einer hohen, mittleren und keiner Skala. Im Folgenden finden Sie die Definitionen, die wir den einzelnen Stufen zuordnen:

• Hoch - NICHT ZURÜCKROLLEN. Es werden schlimme Dinge passieren. Dies sind Einführungen, die nicht ohne katastrophale Auswirkungen zurückgenommen werden können. Ein Beispiel: Wir haben eine Funktion, die eine Entität und den Backend-Datenspeicher, der diese Entität verändert, verändert. Die Deaktivierung der Funktion kann dazu führen, dass Kunden, deren Entitäten bereits geändert wurden, keinen Zugriff mehr auf den Backend-Datenspeicher haben (die Elemente sind nun nicht mehr synchronisiert). Ein Rollback erfordert in der Regel einige Patches für Kunden, für die die Funktion bereits eingeführt wurde.
• Mittel - Diese Funktionen können zurückgesetzt werden, aber es wird nicht empfohlen, dies mit dem Engineering Owner zu besprechen. Je nach Grund kann man ihn dazu überreden, die Rücknahme der Markierung zuzulassen, aber es wird einige Auswirkungen haben. Zum Beispiel könnte ein Beta-Kunde diese Funktionen nutzen und ihre Entfernung würde zu Reibereien mit dem Kunden führen.
• Keine - Dies bedeutet, dass die Markierung jederzeit aufgehoben werden kann. Wenn jedoch jemand die Flagge eines anderen Ingenieurs deaktiviert, muss er diesen anschließend benachrichtigen (bei Optimizely ist das eine nett formulierte Slack-Nachricht, aber das könnte auch in Jira sein), um ihn zu warnen.

Diese Risikostufen werden vor allem bei technischen Vorfällen verwendet, wenn ein Flag eine Störung des Service-Levels verursacht hat. Der Bereitschaftsingenieur prüft in der Regel die Risikostufe (Hoch/Mittel/Keine), und wenn es Keine ist, kann er die Markierung sofort deaktivieren. Dies trägt dazu bei, unsere mittlere Wiederherstellungszeit niedrig zu halten, da wir unsere Vorfälle lösen können, ohne Code zu versenden.

Wie testet Optimizely die Bereitstellung von Feature-Rollouts?

Testpyramide für Feature-Rollouts (Aus dem Buch: Ship Confidently with Progressive Delivery and Experimentieren)

Optimizely verwendet eine Kombination von Teststrategien. Wenn diese zusammen eingesetzt werden, können wir uns darauf verlassen, dass alle Funktionen abgedeckt sind und eine qualitativ hochwertige Veröffentlichung erfolgt:

• Unit-Test - Jedes Feature-Rollout muss einen Unit-Test enthalten, um jede Komponente zu validieren. Unsere Unit-Tests sind klein und wissen nicht, ob sie von einem Feature Flag betroffen sind oder nicht. Jeder erstellte Codepfad verfügt über einen eigenen Satz unabhängiger Unit-Tests.
• Integrationstest - Da Integrationstests Kombinationen von Integrationen testen, die miteinander interagieren, verwenden wir Mocking und Stubs, um den Zustand von Features zu kontrollieren. Wenn wir zum Beispiel eine bestimmte API-Antwort auf ein externes System testen möchten, können wir die Antwort des Optimizely SDK als Stub verwenden, um unseren Test in einen bestimmten Zustand zu bringen, der den Pfad des Feature-Rollouts widerspiegelt. Dadurch kann unser Test auf deterministische Weise ablaufen.
• End-to-End-Test - Dies sind die teuersten Tests, die durchgeführt werden müssen. Daher konzentrieren wir uns nur auf die kritischsten Variationen und verwenden automatisiertes Targeting oder Whitelisting in unseren Testläufen, um einen deterministischen Pfad zu erstellen, auf dem wir uns behaupten können.
• Manuelle Überprüfung - Wir verwenden heuristische Tests, um die risikoreichsten Varianten oder Pfade zu ermitteln, die wir überprüfen müssen. Die manuelle Überprüfung ist den End-to-End-Tests sehr ähnlich, bei denen wir unsere Tester in die eine oder andere Variante zwingen. Wir stellen ihnen auch Informationen aus dem Optimizely Logger und dem Notification Listener zur Verfügung, damit sie einen besseren Einblick in das Verhalten der Flagge erhalten.

Wann entfernt Optimizely seine Feature-Rollouts?

Feature-Rollouts sind dazu gedacht, Code zu implementieren, der dauerhaft ist, sobald wir sicher sind, dass das, was wir implementiert haben, korrekt funktioniert. Für jedes Feature legt das Produktteam fest, welche Kriterien für die Beendigung des Features gelten. Hier sind einige Beispiele:

• X Kunden haben mit der Nutzung der Funktion begonnen, ohne dass es zu größeren Zwischenfällen gekommen ist
• Y Menge an Datenverkehr ist durch die Funktion geflossen, ohne dass der Service beeinträchtigt wurde
• Z Anzahl der Tage, an denen die Funktion der Öffentlichkeit zugänglich war, ohne dass es zu Zwischenfällen kam

Sobald die Ausstiegskriterien erfüllt sind, setzen die einzelnen Teams ihre Strategie zur Entfernung der Funktion um. Insgesamt verfolgen wir als technische Organisation, wie viele Flaggen in den Zustand "bereit zum Entfernen" versetzt wurden, und stellen sicher, dass unsere Feature-Rollout-Flags ständig entfernt werden.

Dies ist der erste Teil einer Serie, in der wir uns mit den verschiedenen Feature Flags bei Optimizely und den Ingenieurteams, die sie implementieren, beschäftigen werden. Bis zum nächsten Mal, wenn wir uns mit dem Feature Flag-Typ Bug Fix beschäftigen.

Wenn Sie mit Feature Flags beginnen oder sie skalieren möchten, sollten Sie sich unsere kostenlose Lösung ansehen: Optimizely Rollouts!

Verwenden Sie Feature-Rollouts in Ihrem Unternehmen? Ich würde gerne von Ihren Erfahrungen hören! Twitter, LinkedIn