Bestimmen Ihrer Feature Flags & Governance als technischer Leiter

Feature Flags (auch bekannt als Feature Toggles) entwickeln sich schnell zur Standardimplementierung für starke Entwicklungsorganisationen. Feature Flags ermöglichen es Teams, Features zu implementieren und zu modifizieren, ohne den Code zu ändern, und einfach A/B-Experimente mit diesen Features in der Produktion durchzuführen , um sicherzustellen, dass die Kunden das beste Erlebnis haben.

Da jedoch immer mehr Entwicklungsunternehmen ihre Feature Flags skalieren, ist es wichtig, die Tatsache zu erörtern, dass nicht alle Feature Flags für dieselben Zwecke verwendet werden und es riskant ist, alle Feature Flags gleich zu behandeln.

Neben der Bestimmung der verschiedenen Arten von Feature Flags ist es wichtig, sich mit der wichtigen Funktion zu befassen, die für die Verwaltung von Feature Flags in großem Umfang erforderlich ist. Governance kann definiert werden als die Festlegung von Richtlinien für das Wie/Was/Warum/Wann Ihrer Feature Flags-Implementierung. Ohne die Standardisierung dieser Richtlinien in Ihrem Unternehmen ist eine ordnungsgemäße Implementierung und Überwachung nicht möglich, was die Entwicklung von Feature Flags gefährden und katastrophale Folgen habenkann .

Governance

Wenn es um die Governance von Feature Flags geht, sehe ich drei wichtige Bereiche, die berücksichtigt werden müssen: die Begrenzung der Lebensdauer von Feature Flags, um technische Schulden zu minimieren, die Festlegung, wer in Ihrem Team Zugriff auf die Änderung von Feature Flags haben sollte, und ein klares Eigentumsmodell für die Bereitstellung von Feature Flags.

Begrenzen Sie die Lebensdauer von Feature Flags, um die technische Verschuldung zu minimieren

Wenn Sie die Verwendung von Feature Flagsskalieren , werden Sie möglicherweise einige langfristige Flaggen haben, die Sie für eine lange Zeit in Ihrem System benötigen. Meiner Erfahrung nach ist es jedoch gefährlich, niemals eine Ihrer Flaggen zu entfernen. Dauerhafte Feature Flags, die permanente Funktionen einschließen, führen zu technischen Schulden. Wenn Sie zu viele "permanente" Feature Flags haben, wird Ihre Codebasis plötzlich:

• schwieriger zu verstehen: Was steckt hinter dieser Funktion?
• schwieriger zu testen: Welcher Codepfad wird tatsächlich ausgeführt?
• anfälliger: Was ist, wenn eine andere Arbeit Ihr Flag deaktiviert?
• schwieriger zu unterstützen: Was passiert, wenn das institutionelle Wissen verloren geht?

Definieren von Zugriffskontrollen für Flags

Feature Flags geben Ihnen die Funktion, eine neue Funktion schnell in der Produktion zu testen und bei Problemen schnell wieder zurückzunehmen. Wenn ein Entwickler am Freitagabend eine neue Funktion einführt und diese Flagge am Sonntagmorgen ein Problem mit dem Kunden verursacht, kann der Bereitschaftsingenieur einfach reingehen und das Problem beheben, ohne ein ganzes Team anpiepsen zu müssen, das dann über die Rücknahme oder Korrektur des Builds diskutiert. Aber nicht alle Entwickler sollten die Möglichkeit haben, jedes Feature Flag zurückzusetzen. Was ist mit Feature Flags, die ein für einen Kunden wichtiges Feature ausschließen? Das Entfernen dieser Flagge kann für das Unternehmen sehr schädlich sein.

Definieren, dokumentieren und kommunizieren Sie das Verantwortungsmodell

Damit Feature Flags gut funktionieren, muss klar sein, wer die einzelnen Flaggen implementiert, einführt und pflegt.

Hier sind ein paar gängige Modelle:

• In den meisten Fällen ist das Entwicklungsteam für die Implementierung und Wartung zuständig, während das Produktteam für die Kommunikation und die Kontrolle der Einführung verantwortlich ist.
• Wenn Feature Flags als Stromkreisunterbrecher fungieren, können DevOps oder SRE stattdessen sowohl für die Wartung als auch für die Kommunikation zuständig sein.

Entwickeln Sie ein klares Verantwortungsmodell für jede Art von Flag - und dokumentieren Sie es an einem zugänglichen Ort, um Ineffizienz und Verwirrung zu vermeiden.

Verständnis der Feature Flags-Typen

Was sind nun einige Arten von Feature Flags? Martin Fowlers großartiger Blogbeitrag "Feature Toggles (aka Feature Flags)" schlüsselt die vier wichtigsten Arten von Feature Flags auf (Release Toggle, Ops Toggle, Permission Toggle Experiment Toggle). Das Buch von Asa Schachar, Ship Confidently with Progessive Delivery and Experimentieren, befasst sich eingehender mit bestimmten Typen (Permission, Operational, Configuration-based, Product Rebranding, Large-Scale Refactors usw.) und erläutert langfristige und kurzfristige Governance-Strategien.

Dies sind hilfreiche Ressourcen, aber Ihr Unternehmen muss vielleicht nicht jede Art von Flagge verwenden.

Wir bei Optimizely haben diese Ressourcen genutzt, als wir den Bedarf unseres Unternehmens an Feature Flags evaluiert haben, und wir haben die von uns verwendeten Flaggen in sechs verschiedene Typen unterteilt. Wir haben diese sechs verschiedenen Flag-Typen auf der Grundlage der Idee entwickelt, dass jeder Typ einen eigenen Governance-Prozess erfordert.

Feature-Rollouts

Feature-Rollouts sind Flaggen, die neue, kundenorientierte Funktionen kennzeichnen. Der gekennzeichnete Code soll dauerhaft sein, so dass wir davon ausgehen, dass die Flaggen entfernt werden, sobald das Feature vollständig in unsere Produktionsumgebung ausgerollt ist. Von all unseren Flag-Typen haben Feature-Rollouts und Fehlerbehebungen die geringste Zugriffskontrolle; alle Entwickler haben Sichtbarkeit und Kontrolle über sie.

Fehlerbehebung

Fehlerkorrekturen sind kompliziertere Codeänderungen, die wir langsam einführen möchten. Entwickler verwenden auch Bug Fix Feature Flags, um schnellere Fehlerbehebungen und Tests in der Produktion hinter der Flagge zu testen. Bug Fix Feature Flags sollen immer entfernt werden, sobald der Fehler behoben ist. Diese haben die höchste Sichtbarkeit, da wir darauf achten müssen, dass wir unsere Fehler korrekt beheben und sie nicht verschlimmern. Alle Entwickler haben Sichtbarkeit und Kontrolle über diese Flaggen.

Operativ und Circuit Breaker

Operative Flaggen kontrollieren jeden operativen Aspekt des Systemverhaltens. Das Circuit Breaker-Flag ist ein manueller Abschaltschalter, der bestimmte Funktionen deaktiviert. Beides sind langfristige Flags und wir gehen davon aus, dass sie noch eine Weile in unserer Codebasis bleiben werden. Diese Flags haben in der Regel ein höheres Maß an Zugriffskontrolle, da sie ein Verhalten unseres Systems steuern, das möglicherweise sensibel ist. Die Funktionalität dieser Flags ist Eigentum der jeweiligen Teams und erfordert eine klare Dokumentation darüber, wie sich die Flags auf die Systeme auswirken, in denen sie implementiert sind.

Berechtigung

Permission Flags legen fest, welche Kundengruppen Zugang zu bestimmten Funktionen haben. Sie steuern unsere Funktionsstufen, die durch die Preisgestaltung und das Paket für Optimizely bestimmt werden. Die Berechtigungsflags haben die höchste Zugriffskontrolle, da nur Mitglieder unseres Monetarisierungsteams diese ändern dürfen. Bei Optimizely werden diese Kontrollen von unserem Entwicklungsteam implementiert, aber der eigentliche Kontrollfluss wird von einem Geschäftsteam verwaltet.

Experiment

Experiment Feature Flags sind unsere A/B/n-Flags, die es uns ermöglichen, datengesteuerte Entscheidungen über unsere Arbeit mit Features zu treffen und eine Hypothese zu testen. Wenn eine Hypothese richtig ist und wir unser Experiment in ein dauerhaftes Feature umwandeln möchten, werden diese zu Feature-Rollouts und folgen unserem Feature-Rollout-Prozess.

Wie Sie sehen, sind Feature Flags nicht nur ein Werkzeug für Progressive Delivery und sofortiges Rollback für die Bereitstellung von Features, sondern sie können eine ganz neue, schnellere und sicherere Art der Softwarebereitstellung ermöglichen. Mit großer Macht kommt jedoch auch große Verantwortung, und es ist wichtig, dass Sie die verschiedenen Arten von Flags und deren Handhabung klar definieren.

In den nächsten sechs Wochen werde ich näher darauf eingehen, wie wir bei Optimizely jeden dieser Feature Flag-Typen verwalten, von Anwendungsfällen über Zugriffskontrollen bis hin zur Kommunikation, damit Sie unsere Erfolgsmethoden für den Aufbau Ihres eigenen Feature Flag-Typs und Governance-Modells nutzen können.

Dies ist der erste Blog einer 7-teiligen Serie, die sich mit den verschiedenen Feature Flags bei Optimizely und den Entwicklungsteams, die sie implementieren, befassen wird. Wir sehen uns beim nächsten Mal, wenn wir den Feature-Rollout Feature Flag-Typ genauer unter die Lupe nehmen.

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

Wie haben Sie die Verwaltung von Feature Flags in Ihrem Unternehmen gehandhabt? Ich würde gerne von Ihren Erfahrungen hören! Twitter, LinkedIn