Kontext
Feature Flag Runner vznikl z praktické potřeby kolem rolloutování změn za feature flagy. Feature flag jako jednoduchý boolean přepínač je užitečný, ale u rizikovějších změn často nestačí.
Když zavádíme nový kód, nechceme vědět jen to, jestli je flag zapnutý nebo vypnutý. Potřebujeme vidět i to, jestli se nová cesta skutečně spustila, jak často se spouští, v jakém kontextu, jak dlouho běží, kolik chyb v ní vzniká, jaký má výsledek, pokud nějaký vrací — a v některých případech i to, jestli se její výstup liší od původního chování.
Problém
Bez společného vzoru bylo jednoduché skončit jen u boolean podmínky nad feature flagem. Všechno ostatní byla práce navíc, na kterou se při implementaci snadno zapomnělo nebo se odložila na později.
Jenže „později“ často znamenalo až ve chvíli, kdy už změna běžela a bylo potřeba řešit konkrétní problém. Observabilita pak nevznikala jako přirozená součást rolloutování, ale jako dodatečná oprava něčeho, co mělo být vidět od začátku.
Přístup
Vytvořil jsem runner, který obalil staré a nové chování do jednoho společného vzoru. Místo toho, aby si každý kus kódu řešil feature flag, logování a měření po svém, runner dostal původní cestu, novou cestu a konfiguraci toho, co se má spustit, zalogovat, změřit nebo porovnat.
Díky tomu šlo použít různé režimy podle rizika změny. Někdy stačilo jen přepnout na nové chování. Jindy dávalo smysl pustit novou cestu na pozadí vedle původní, měřit její výkon, sledovat chyby nebo porovnat výsledky, aniž by se tím hned měnilo chování pro uživatele.
Feature flag se tím posunul z jednoduché podmínky na místo, kde byl rovnou připravený bezpečnější rollout a základní observabilita.
Výsledek
Hodnota runneru byla v tom, že sjednocoval způsob, jakým se změny za feature flagy spouštěly a měřily. Bezpečnější cesta se stala jednodušší cestou.