Feature Flags ersetzen keine gründlichen Tests

Die eben genannten sind gute Anwendungsfälle für Feature Flags. Ich habe aber auch Teams erlebt, die sich bei der Verwendung von Feature Flags verzettelt und viel zu weitgehende Vorgaben erlassen haben. Zum Beispiel, dass jede einzelne Codeänderung hinter einem Feature Flag stehen sollte, "nur für den Fall, dass wir einen Fehler gemacht haben".

Risikomanagement sollte für alle Teams vorrangig sein. Allerdings gibt es dafür bessere Wege als Feature Flags, insbesondere wenn das Team die Kontrolle über die Verteilung hat. Die überwiegende Mehrheit der Bugs sollte von automatisierten Test-Suites und/oder dem QA-Prozess abgefangen werden - und die Nachzügler mit schrittweisen Deployments, Warnungen im Produktionsbetrieb und Rollbacks.

Übrigens lautet die Empfehlung bei Firmen wie Google, beim Entdecken eines Problems zuerst einen Rollback durchzuführen und das Problem später zu untersuchen:

"Wir haben bei Google schon oft gesehen, dass ein eilig eingesetzter Roll-Forward-Fix entweder das ursprüngliche Problem nicht behebt oder alles noch schlimmer macht. Selbst wenn er das Problem behebt, kann es sein, dass dadurch andere latente Fehler im System aufgedeckt werden. Damit entfernt man sich immer weiter von einem bekannten, gut funktionierenden Zustand hin zu einer unbekannten Version ohne die üblichen strengen QA-Tests. Bei Google ist unsere Philosophie, dass Rollbacks normal sind. Wenn ein Fehler in einer neuen Version gefunden oder vermutet wird, macht das veröffentlichende Team zuerst einen Rollback und geht dem Problem erst danach auf den Grund."

Wenn es akute Probleme mit dem Code gibt, ist das Letzte, was Sie tun möchten, erst einmal lange nach der Ursache zu suchen und sich zu fragen, welcher Flag-Flip das Problem beheben wird. Zumal es keine Garantie dafür gibt, dass es diesen Flag-Flip, der das Problem löst, überhaupt gibt.

Feature Flags sind eine schlechte Alternative zu binären Rollbacks, und sie sind definitiv kein Ersatz für eine gute automatisierte Testsuite und einen robusten QA-Prozess. Wenn Sie sich auf Feature Flags verlassen, um Fehler im produktiven Betrieb zu beheben, sollten Sie kurz innehalten und die Arbeitsweise Ihres Teams überdenken. Denn Risiken zu scheuen, ist oft ein erstes Anzeichen dafür, dass es mit einer Software bergab geht.