Wofür? Ein‑/Ausschalten von Code Vereinfacht trunk‑based Development und damit Continuous Integration/Delivery Unfertige Features können jederzeit integriert und getestet werden
Release Toggles Integration von Code unabhängig vom Release Toggles sollten bald nach dem Release entfernt werden Toggle Änderung per Deploy ausreichend
Experiment Toggles Vereinfacht datengetriebene Entwicklung, z. B. mittels A/B Tests Toggle Änderung per Deploy ausreichend Toggle verbleibt für längere Zeit im Code
Ops Toggles Kann genutzt werden, um z. B. unwichtige Teile einer Applikation bei großer Last auszuschalten Agieren wie manuelle Circuit Breaker Toggle Änderung per Request notwendig, um schnell reagieren zu können (ohne Deploy) Toggle verbleibt für sehr lange Zeit im Code
Permissioning Toggles Beispiele: Ausrollen von Features für Alpha und Beta Nutzer Begrenzung von Features für Nutzergruppen, z. B. Premium und Free Nutzer Toggle Wert Änderung per Request/User notwendig
Management von Toggles Unterschiedliche Varianten von Toggles sollten auch an unterschiedlichen Orten vorgehalten werden Mögliche Dimesionen sind Statische vs. dynamische Toggles Kurzlebige vs. langlebige Toggles
Toggle an der Außenkante: Einstieg in neue/geänderte Funktion in UI umschalten An dieser Stelle sind die meisten Informationen verfügbar: z. B. Nutzer, Request Gut für "per Request" Toggles Restlicher Code ist größtenteils befreit von Feature Toggle Logik Funktionen sind evtl. öffentlich verfügbar, jedoch muss dafür die genaue URL erraten werden < % = i f F e a t u r e S y s t e m [ : r e c o m m e n d a t i o n s ] . e n a b l e d ? % > < % = r e n d e r ' r e c o m m e n d a t i o n s _ s e c t i o n ' % > < % e n d % >
Toggle tief im Code Eher technischer Natur, z. B. Wechsel interner Logik via Branch by Abstraction i f F e a t u r e S y s t e m [ : f a s t e r _ s e a r c h ] . e n a b l e d ? N e w S e a r c h . n e w ( o p t i o n s ) e l s e S e a r c h . n e w ( o p t i o n s ) e n d
flipper: feature flipping for ANYTHING Gates: Boolean, Groups, Actors, % of Actors, and % of Time Adapters: Mongo, Redis, Cassandra, Active Record... Instrumentation: ActiveSupport::Notifications, Statsd and Metriks Optimization: Memoization middleware and Cache adapters Web‑Interface: Point and click... API: HTTP API interface
flipper Beispiel r e q u i r e ' f l i p p e r ' # p i c k a n a d a p t e r r e q u i r e ' f l i p p e r / a d a p t e r s / m e m o r y ' a d a p t e r = F l i p p e r : : A d a p t e r s : : M e m o r y . n e w # g e t a h a n d y d s l i n s t a n c e f l i p p e r = F l i p p e r . n e w ( a d a p t e r ) # c h e c k i f t h a t f e a t u r e i s e n a b l e d i f f l i p p e r [ : s e a r c h ] . e n a b l e d ? p u t s ' S e a r c h a w a y ! ' e l s e p u t s ' N o s e a r c h f o r y o u ! ' e n d
rollout Beispiel # F e a t u r e F l i p p e r i s a n A c t i v e R e c o r d a d a p t e r c l a s s F e a t u r e S y s t e m = R o l l o u t . n e w ( F e a t u r e F l i p p e r ) F e a t u r e S y s t e m . d e f i n e _ g r o u p ( : s t a f f ) d o | u s e r | ! R a i l s . e n v . p r o d u c t i o n ? | | u s e r & & u s e r . e m a i l . t o _ s . e n d _ w i t h ? ( ' @ s t u d i t e m p s . d e ' ) e n d D E V _ A C C O U N T _ I D S = [ 4 2 , 2 3 ] . f r e e z e F e a t u r e S y s t e m . d e f i n e _ g r o u p ( : d e v s ) d o | u s e r | ! R a i l s . e n v . p r o d u c t i o n ? | | u s e r & & u s e r . i d . i n ? ( D E V _ A C C O U N T _ I D S ) e n d F e a t u r e S y s t e m . a c t i v a t e _ g r o u p ( : r e c o m m e n d a t i o n s , : s t a f f ) F e a t u r e S y s t e m . a c t i v a t e _ g r o u p ( : f a s t e r _ s e a r c h , : d e v s )
Toggle Konfiguration Statische, kurzlebige Toggles sind vorzuziehen Code ist verständlicher Führen in allen Umgebungen zu gleichen Auswirkungen Persistierung Konfigurationsdatei, z. B. YAML Datenbank Eigener (Micro‑)Service Cookie Aktuelle Toggle‑Werte sollten einfach einsehbar sein, z. B. im HTML Quellcode oder HTTP Header
Vorteile Ermöglicht CI und CD Kein Merging von langlebigen Branches Schrittweiser Release von Features, z. B. zuerst an Beta Tester oder eine kleine Nutzergruppe (Canary Releases) Code‑Reviews: durch kontinuierliche Integration können die Code‑Chunks kleiner sein Testen von abhängigen Features durch Einschalten der jeweiligen Toggles Einfache Integration von globalen Änderungen, wie z. B. neues CSS für unterschiedliche Features
Nachteile Komplexität wird gesteigert: Jeder Toggle ist technische Schuld, die beglichen werden muss Weitere globale Abhängigkeit im Code Unfertiger, ungetesteter, inkompatibler Code wird ausgeliefert und könnte damit auch bei den Nutzern landen Alle Code‑Zweige müssen getestet werden. Theoretisch müssten alle Kombinationen auch gestestet werden, aber nur selten überschneiden sich durch Feature Toggles abgetrennte Code‑Zweige Langlebige Toggles sind Code und erhöhen dementsprechend den Wartungsaufwand
Best Practices Anzahl an Toggles klein halten und nach Feature Release aufräumen Am Besten Toggles an sich vermeiden, wenn das neue Feature auch inkrementell ausgeliefert werden kann Toggles regelmäßig bewerten und bei Bedarf entfernen Bewusst die Kosten langlebiger Toggles wahrnehmen
Quellen Feature Toggles, https://martinfowler.com/articles/feature‑ toggles.html Branch By Abstraction, https://martinfowler.com/bliki/BranchByAbstraction.html Continuous Lifecycle 2016 ‑ Integrierst du schon oder branchst du noch? (Steffen Schluff/Sebastian Damm), https://vimeo.com/192103429 Feature Toggles are one of the worst kinds of Technical Debt, https://swreflections.blogspot.de/2014/08/feature‑toggles‑are‑ one‑of‑worst‑kinds.html Trunk Based Development, https://trunkbaseddevelopment.com/ Flipper, https://github.com/jnunemaker/flipper Rollout, https://github.com/FetLife/rollout