Softwareentwicklung: Wann Feature Flags sinnvoll sind - und wann nicht

Feature Flags schalten bestimmte Code-Teile nach Bedarf ein und aus. Das klingt erstmal nützlich, kann aber auch gefährlich sein.

Artikel von Rajiv Prabhakar veröffentlicht am 3. April 2021, 12:00 Uhr

Es ist mit Feature Flags ein bisschen wie im Bahnverkehr: Wenn man vergisst, die Weiche wieder zurückzustellen, kann ein Unglück passieren. (Bild: Pixabay)

Dieser Artikel ist eine Übersetzung. Das Original des Softwareentwicklers und Bloggers Rajiv Prabhakar ist hier zu finden.

In den vergangenen Jahren habe ich in mehreren Teams gearbeitet, die bei Feature Flags sehr unterschiedliche Strategien verfolgt haben. Ich habe die Vor- und Nachteile all dieser Strategien gesehen und mit der Zeit festgestellt, dass ich weder eine extrem ablehnende noch eine extrem befürwortende Haltung besonders gut finde. Es gibt eine Menge Nuancen bei diesem Thema, und ich denke, es lohnt sich, die verschiedenen Szenarien, in denen Feature Flags sinnvoll sind oder nicht, genauer zu betrachten.

Sinnvolle Anwendungen für Feature Flags

Es gibt einige wichtige Szenarien, in denen Feature Flags sehr sinnvoll sind. Zum einen für A/B-Tests, bei denen unterschiedliche Aktionen unterschiedlichen Nutzern zufällig zugewiesen werden. Ich habe gesehen, wie diese Strategie bei Amazon sehr gut eingesetzt wird, indem neue Funktionen durch ein Feature Flag gesteuert werden, das eigentlich von einem internen A/B-Testing-Framework kontrolliert wird. Das Framework wählt einige Amazon-Kunden nach dem Zufallsprinzip für die neue Funktion aus und überwacht dann ihr Verhalten, um die geschäftlichen Auswirkungen abzuschätzen.

Ich war zunächst skeptisch; allerdings überzeugte mich, wie einfach das Framework zu bedienen war und welche wertvollen Erkenntnisse es über die Vor- oder Nachteile bestimmter Funktionen lieferte. Entscheidungen, die sonst auf einem vagen Gefühl gründeten, was gerade funktionieren könnte, basierten nun auf echten Daten. Um neue Funktionen dynamisch umzuschalten, braucht es eben Feature Flags.

Ein weiterer guter Anwendungsfall für Feature Flags ist, wenn Sie an einem sehr komplexen Projekt arbeiten, bei dem viele verschiedene Teilaufgaben in verschiedenen Teilen des Systems erledigt werden müssen - Teilaufgaben, die zu zahlreich und invasiv für einen einzigen Pull Request sind.

In solchen Fällen ist der Versuch, alle Änderungen in Nebenzweigen zu halten und eine gleichzeitige Zusammenführung und Bereitstellung zu koordinieren, nahezu aussichtslos. Es ist übersichtlicher, alle disruptiven Änderungen hinter ein Master Flag zu bekommen, alle Sub-Commits schrittweise zusammenzuführen und bereitzustellen und das Flag umzustellen, sobald alle Teile an der richtigen Stelle sind.

Auch sind Feature Flags sinnvoll, wenn Sie keine Kontrolle über Ihre Softwareverteilung haben. Denken Sie zum Beispiel an die Facebook-Android-App, die Code von Hunderten verschiedenen Teams enthält und ihn als eine einzige Binärdatei bereitstellt. In solchen Szenarien sind Rollbacks manchmal unmöglich - aus praktischen, politischen, bürokratischen oder sogar Marketing-Gründen. Feature Flags ermöglichen es dann, neue Funktionen zu aktivieren oder das Risiko bestimmter Änderungen zu verringern, ohne dass ein Rollback gemacht werden muss oder neue Binärdateien bereitgestellt werden müssen.

Bei Reddit hat jemand über einen ähnlichen Anwendungsfall für Feature Flags geschrieben: Wenn nämlich aus Marketing-Gründen ein bestimmtes Einführungsdatum festgelegt wird, der Code aber früher bereitgestellt werden soll, um die Stabilität zu gewährleisten. Hier hilft ein dynamisches Feature Flag, das sich automatisch zu einem bestimmten Zeitpunkt aktiviert.