Feature Flags: Wann sie sinnvoll sind und wann nicht
When Feature Flags Do and Don't Make Sense
Feature Flags sind ein mächtiges Werkzeug, aber ihr Einsatz ist nicht immer sinnvoll. Rajiv Prab argumentiert, dass sie ideal für A/B-Tests, komplexe Epics und Situationen ohne Deploy-Kontrolle sind. Doch als universelle Absicherung gegen Bugs sind sie ungeeignet – Rollbacks und gute Tests sind besser. Zudem erzeugen zu viele Flags technische Schulden und Komplexität, die zu Fehlern führen können. Ein ausgewogener Blick auf Vor- und Nachteile.
Jedes Feature Flag verdoppelt sofort die Anzahl der Randfälle, die deine Programmierer verstehen müssen und die dein Code behandeln muss.
- paulryanrogers
Ich habe bei einem Unternehmen gearbeitet, das eine buchstäbliche Einstellungstabelle mit 5.000 (nicht standardmäßigen) Datensätzen hatte, und es gab hunderte mögliche Einstellungen.
Ich habe auch kondensierte Flags gesehen, bei denen der Flag-Datensatz eingebettet hatte, welche IDs aktiviert waren, mit einem massiven Überschreibungsrisiko, wann immer jemand irgendeine Einstellung anfasste.
Außerdem flag-averse Module, bei denen es so viel Magie gab, dass niemand jemals genau verstehen konnte, was passieren würde, bis sie einen echten oder ähnlich strukturierten Satz von Datensätzen luden. Und sie vertrauten ihren Ergebnissen nicht länger als etwa einen Monat, weil Änderungen häufig waren, da sich die Dinge weiterentwickeln mussten. Die Begründung für diesen Wahnsinn ist, dass zu viele Flags dazu führen, dass Leute Dinge übersehen, oder wir vergessen, das neue glänzende Feature nach der Rollout-Phase standardmäßig zu aktivieren.
Meiner Erfahrung nach gibt es ein Gleichgewicht zwischen der Vergabe eines Flags für jedes Feature und jeden Codepfad und dem Fall, dass nie etwas ein Flag bekommt. Natürlich bringen die Flags selbst Komplexität und Risiko mit sich. Und es gibt die Arbeit, sie zu entfernen, mit den Überbleibseln und der QA, die sich bei Regressionen ändert.
- stopping
Ich habe nie einen guten Weg gefunden, Feature Flags in meinen Workflow zu integrieren, ohne erheblichen mentalen Aufwand bei der Verwaltung von 12-stufigen Rollouts über ein Dutzend unabhängiger aktiver Flags zu verursachen. Die Änderungen, die ich tendenziell mache, sind weitreichende, nicht-triviale Refactorings von Basisbibliotheken mit hunderten oder möglicherweise tausenden Aufrufern. Solche Änderungen sind außergewöhnlich schwer zu flaggen (insbesondere API-Änderungen), und es ist dumm einfach für einen anderen Entwickler, bei der Auflösung eines Merge-Konflikts einen Fehler zu machen und eines meiner Flag-Gates zu verlieren.
Bis heute habe ich keine guten Richtlinien gefunden, um solche Änderungen zu flaggen, ohne auf weit verbreitete Dateiduplikation, Missbrauch von OOP oder ein Ad-hoc-Versionssystem zurückzugreifen. Es überrascht nicht, dass niemand in meiner Organisation bereit war, diese Art von Arbeit zu erledigen.
- classictraffic
Ich stimme der gesamten Prämisse zu, aber ich denke, das Kostenargument ist ein wenig übertrieben. Das Hinzufügen von "unnötigen" Feature Flags ist meiner Meinung nach keine große Sache; Feature Flags sind günstig hinzuzufügen und zu warten. Außerdem kann das Umschalten von Feature Flags manchmal schneller sein als ein Rollback, insbesondere wenn mehrere Systeme beteiligt sind.
Ich denke, die wahren Kosten sind, dass Feature Flags zu Code-Aufblähung und Lesbarkeitsproblemen führen können, da Ingenieure normalerweise nicht großartig darin sind, Feature Flags nach dem Rollout aufzuräumen. Ich denke, das ist ein leicht lösbares Problem, das jedoch keine Knappheitsmentalität erfordert wie "verwende einfach weniger Feature Flags / nur wenn nötig". LaunchDarkly macht es ziemlich einfach, die Nutzung von Feature Flags zu verfolgen und Leute daran zu erinnern, alte aufzuräumen.
- MaulingMonkey
Feature Flags sind großartig. Arbeitest du an einem Absturz / Speicherkorruption in einem optionalen Subsystem? Einfach das Subsystem deaktivieren, um Kollegen auf demselben Branch nicht zu blockieren, während du die Ursache eingrenzt.
Feature Flags sind schrecklich. Arbeitest du an einem Absturz / Speicherkorruption in einem optionalen Subsystem? Du hast es zuvor für deinen lokalen Build deaktiviert, und du wirst Stunden verlieren, ohne es reproduzieren zu können, obwohl die QA hervorragende Reproduktionsschritte liefert.
(Für meinen eigenen Gamedev-Hintergrund habe ich gelernt, Audio zu stummschalten, indem ich die Lautstärke auf 0 setze, anstatt das Audio-Subsystem zu deaktivieren.)
- conradludgate
Ich habe Feature Flags in unsere Komponente bei der Arbeit eingeführt.
Der Grund, warum Rollbacks für uns nicht ausreichen, ist, dass unser Dienst semi-zustandsbehaftet ist (Postgres-Verbindungen sind zustandsbehaftet, wir proxyen diese Verbindungen). Aus diesem Grund behalten wir immer alte Pods für 5 Tage, um Verbindungen abfließen zu lassen.
Ein Deploy+Rollback führt dazu, dass dreimal so viele Pods herumliegen, und wenn wir einen Fix-Patch deployen, sind es viermal so viele – und wenn wir den Fix nicht deployen, haben wir zwei Wochen an Änderungen für das nächste Release angesammelt.
Aus diesem Grund verwenden wir stattdessen das Feature Flag. Wir können es sehr schnell für riskante Änderungen ein- und ausschalten, und es ändert nichts an der Pod-Anzahl.