Feature Toggles – Sinn und Unsinn in der heutigen Softwareentwicklung

Wilhelm von Wiesel
Wilhelm von Wiesel 2020-11-15T13:22:47

Als Entwickler in einem modernen Entwicklungsteam hat man es nicht leicht. Müsste man die Anforderungen an Softwareentwicklung unseres Zeitalters mit einem Wort beschreiben, dann wäre es wohl „Speed“. Und dabei meine ich nicht den Film mit Sandra Bullock und Keanu Reeves, in dem die einzige Aufgabe darin bestand, einen Bus mit über 50 mp/h an einem Flughafen auf und ab fahren zu lassen. Natürlich ist das ein schlechter Vergleich. Busfahrer und Softwareentwickler haben auf den ersten Blick recht wenig gemeinsam. Doch bei genauerer Betrachtung sieht man: Beide Berufsgruppen sind gehetzt, müssen einem Plan folgen und ihre „Haltestellen“ abfahren, damit alle Kunden glücklich sind.

In der Softwareentwicklung redet natürlich niemand über Haltestellen. Nichtsdestotrotz „fährt“ auch ein Entwickler genau nach Plan – der jedoch übervoll ist. Sprint Planung, Daily, Retro, Review, noch mal planen – das Ganze natürlich mit anderen Teams in einem übergreifenden Framework –, all diese zusätzlichen Tätigkeiten lassen die Zeit für die eigentliche Arbeit des Entwicklers deutlich schrumpfen. Doch am Ende eines Sprints wird ein Inkrement erwartet, was am besten zu 100% getestet dem Kunden in Hochglanz zur Verfügung gestellt werden soll.

Wer als Entwickler den „Luxus“ hat, sein Feature allein oder vielleicht nur in einem Team zu entwickeln, kann hier nun aufhören zu lesen. Wer glaubt sich in der oberen Beschreibung wiederzufinden, der möge gern weiterlesen.

Feature Toggles, was ist das eigentlich?

Vermutlich hat jeder bereits den Begriff „Feature Toggle“ gehört und in den meisten Fällen auch in einer einfachen Form verwendet. Denn am Ende ist es nichts anderes als die Möglichkeit, eine bestimmte Funktion von „außen“ ein- oder auszuschalten. Als Beispiel für die weitere Betrachtung stellen wir uns dazu einen Button auf einer Webseite vor, über den ein Kunde zu einer anderen Unterseite gelangen kann. Dieser Button wird nun einfach in einen if/else-Block gesetzt und über eine Konfigurationsvariable sichtbar oder unsichtbar gemacht. That‘s it, wir haben einen Feature Toggle 😊!

Leider bringt dieses Vorgehen jedoch nicht nur Vorteile mit sich, denn der Code wird dadurch schlechter wartbar. Für einen einfachen Test, der prüfen würde, ob da ein Button auf der Seite ist, müsste der Tester nun natürlich auch den Fall einkalkulieren, dass irgendwer den Button gerade über eine Konfiguration als nicht sichtbar gekennzeichnet hat. Feature Toggles dieser Art sollten also eher kurzlebig sein und müssen früher oder später aus dem Code wieder entfernt werden.

Feature Toggles, was bringt mir das in diesem Beispiel?

Bei einem einfachen Button vermutlich nicht besonders viel. Daher erweitern wir unser fiktives Beispiel um ein weiteres Teammitglied: den Designer. Dieser hat die Aufgabe den Button besonders „schön“ aussehen zu lassen, denn dafür interessiert sich der Entwickler im Normalfall nicht. Unser Button-Entwickler ist somit nicht mehr allein für eine Funktion verantwortlich sondern davon abhängig, dass ihm eine Zulieferung vom Designer gemacht wird, um sein Sprintziel zu erreichen. Leider ist dieser kurz vor der Abgabe erkrankt und nicht mehr ansprechbar – das Sprintziel ist gefährdet und die Codeänderungen dürften damit auch nicht in den Master Branch zurück – denn die Funktion ist ja noch nicht fertig. Wird hier nun ein Feature Toggle verwendet, um die Funktion auszuschalten, kann unser Entwickler seinen Teil der Arbeit abschließen, auch wenn der Kunde selbst natürlich nichts davon hat. Da der Code zur Laufzeit nicht angezogen wird, (da er sich ja im getoggelten Block befindet) muss unser Entwickler auch keine Angst haben, dass seine Codeänderung zu einer Beeinträchtigung der restlichen Anwendung führt. Dies ist einer der großen Vorteile von Feature Toggles. Hängen normalerweise neue Funktionen, also das „Releasen“, an einem Deployment, so lassen sich über die Verwendung von Feature Toggles diese beiden Dinge voneinander trennen, wodurch sich der eingangs beschriebene „Speed“ auch für Deployments in der Produktivumgebung durchsetzen lässt.

Lösen Feature Toggles nun alle Probleme?

Ganz klar – nein. Denn der Vorteil von schaltbaren Funktionen ist Fluch und Segen zugleich. In einer kleinen Anwendung ist es leicht, die Konfiguration der Toggles ohne Toggle Management zu pflegen. In größeren Umgebungen mit vielen Microservices bzw. Umgebungen mit verschiedenen Stages (Dev, QS, Live, …) und der Trennung von Betrieb und Entwicklung führt dieses Vorgehen ohne klare Strategie oder Konzept schnell zu Chaos. Denn woher weiß der Kollege vom Betrieb, welche Funktion in welcher Umgebung nun wie geschaltet sein soll? Genauso kann der Entwickler ohne seinen Productowner die Frage auch nur unzureichend beantworten. Wer die Vorteile von Feature Toggles in diesen Szenarien also nutzen will, kommt um den Einsatz eines Feature Toggle Management Systems (wie Switchover) nicht herum.

Fazit:

Pro für den Einsatz von Feature Toggles:

  • Trennung von Deployment und dem Veröffentlichen von Funktionen
  • Reduzierung der Abhängigkeiten und damit geringere Verzögerungen bei größeren Teams
  • Feature Branches können deutlich schneller in den Hauptbranch zurückgeführt werden
  • Rebasing innerhalb der Branches ist seltener nötig
  • Ein „echtes“ CI/CD wird erreicht
  • Ohne den Einsatz von Feature Toggle Management Systemen wird es schnell unübersichtlich

Contra für den Einsatz:

  • Komplexität und Wartbarkeit des Codes steigt
  • Feature Toggles sollten wieder aus dem Code entfernt werden
  • Testing muss um die UseCases der geschalteten Funktion erweitert werden

Feature Toggeling kann die Entwicklung beschleunigen und ein echter Mehrwert für die moderne Softwareentwicklung sein, solange die Spielregeln eingehalten werden.

Im nächsten Beitrag: Feature Toggeling und Test: Wie nutze ich Feature Toggles zum Test von neuen Funktonen mit „echten“ Kunden? Was sind prozentuale Rollouts und A/B-Tests?