Feature Toggle — základy, typy přepínačů a aplikace
Feature Toggle je mechanismus přepínání funkcionality aplikace za běhu, který umožňuje vývojářům spravovat dostupnost funkcí bez změny kódu a opětovného nasazení. Na rozdíl od podmíněného překladu (ifdef) toggle pracuje na úrovni runtime a může se dynamicky měnit. Podle údajů Martina Fowlera (2024) jsou feature toggles klíčovým prvkem trunk-based development a nepřetržitého doručování. Feature toggle poskytuje týmům flexibilitu při správě vydání a experimentů.
Hlavní body
- Feature Toggle — dynamický přepínač, který řídí chování aplikace prostřednictvím konfigurace
- Hlavní typy: business toggles, release toggles, experiment toggles a infrastructure toggles
- Feature Toggle vs Flag — toggle se častěji vztahuje k jednoduchým binárním přepínačům, flag — k plnohodnotným platformám
- Integrace s CI/CD umožňuje automatickou kontrolu a testování toggles v každé fázi pipeline
- Hlavní problém — hromadění stale toggles, které je třeba pravidelně auditovat a odstraňovat
Co je Feature Toggle
Feature Toggle (přepínač funkcionality) — je technika, při které je kód nové funkce zabalen do podmíněné konstrukce, která kontroluje hodnotu konfiguračního parametru. Pokud je parametr true — nová funkcionalita je aktivní, pokud false — provádí se starý kód. Klíčový rozdíl oproti feature flag je v tom, že toggle je binární přepínač fungující na principu „zapnuto/vypnuto”, bez složitých pravidel targetování a distribuce provozu.
Definice a princip fungování
Feature toggle je implementován jako běžná if-konstrukce kolem nové funkcionality. Hodnota toggle je uložena v konfiguraci aplikace — proměnných prostředí, JSON souboru nebo databázi. Při spuštění aplikace načte konfiguraci a použije ji k rozhodování o viditelnosti funkcí. V nejjednodušším případě vyžaduje změna hodnoty toggle restart aplikace, ale v produkčních systémech toggles obvykle podporují hot reload prostřednictvím externího konfiguračního serveru nebo API.
Příklad jednoduchého toggle
Podívejme se na implementaci feature toggle v JavaScript (Node.js). Přepínač je uložen v JSON konfiguraci a načítá se při spuštění serveru. Middleware kontroluje hodnotu toggle před tím, než přesměruje požadavek na nový nebo starý handler. Taková implementace umožňuje přidávat novou funkcionalitu do hlavní větve kódu, aniž by narušila fungování aktuální verze API.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});Typy feature toggles
Pete Hodgson z ThoughtWorks rozlišuje tři hlavní typy feature toggles, klasifikované podle doby života a účelu použití. Správné určení typu toggle pomáhá vybrat vhodný mechanismus ukládání a proces správy. Podívejme se na každý typ v kontextu mobilního vývoje.
Business a Release toggles
Business toggles — nejdéle žijící přepínače. Spravují obchodní pravidla dostupná pouze určitým kategoriím uživatelů (prémiové funkce, regionální vlastnosti). Takové toggles mohou žít roky a obvykle mají složitější logiku než binární zapnutí/vypnutí. Release toggles — dočasné přepínače pro skrytí nedokončené funkcionality. Jejich životní cyklus je od několika dnů do několika týdnů. Po dokončení funkcionality je release toggle odstraněn z kódu. Tyto toggles jsou základem trunk-based development, umožňující vývojářům commitovat do hlavní větve bez čekání na dokončení celé funkcionality.
Experiment a Infrastructure toggles
Experiment toggles se používají pro A/B testy a postupné zavádění. Na rozdíl od release toggles, experiment toggles podporují procentuální distribuci uživatelů a integraci s analytickými systémy. Mohou žít déle než release toggles (až několik měsíců), ale po dokončení experimentu musí být odstraněny. Infrastructure toggles — přepínače pro správu infrastrukturních změn: migrace databází, přechod na nového API providera, změna algoritmů cachování. Tyto toggles vyžadují zvláštní pozornost při testování, protože jejich přepnutí ovlivňuje stabilitu celé služby.
| Typ toggle | Doba trvání | Publikum | Příklad |
|---|---|---|---|
| Business | Měsíce-roky | Podle rolí/regionů | Prémiové funkce |
| Release | Dny-týdny | Vývojáři/QA | Nedokončená obrazovka |
| Experiment | Týdny-měsíce | % uživatelů | A/B test rozhraní |
| Infrastructure | Dny-týdny | Interní | Migrace DB |
Feature Toggle vs Feature Flag
Ačkoli se termíny „feature toggle” a „feature flag” často používají jako zaměnitelné, existují mezi nimi koncepční rozdíly. Pochopení těchto rozdílů pomáhá vybrat správný nástroj pro konkrétní úkol a vyhnout se zmatkům v týmu. Podívejme se na klíčové rozdíly a oblasti použití každého přístupu.
Rozdíly v přístupu
Feature toggle — je především technický mechanismus: binární přepínač vložený do kódu aplikace. Toggle je spravován prostřednictvím konfigurace a nevyžaduje externí infrastrukturu. Feature flag — je širší koncept zahrnující platformu pro správu: UI pro konfiguraci, SDK pro integraci, monitorování používání, analytiku a audit. Flagy podporují složitá pravidla targetování (podle regionu, verze, zařízení), A/B experimenty a automatické odstraňování. Lze říci, že feature flag je evolucí feature toggle: tým začíná s jednoduchými konfiguračními přepínači a s růstem přechází na specializovanou platformu.
Kdy je toggle dostatečný
Pro malé týmy a projekty s jednou službou nebo monolitickými aplikacemi jsou jednoduché konfigurační toggles zcela dostačující. Pokud máte 5–10 vývojářů a 1–2 aktivní toggles současně — externí platforma bude nadbytečná. Platformy feature flag (LaunchDarkly, Unleash) se stávají nezbytnými, když počet aktivních flagů přesáhne 20–30, v týmu je 20+ vývojářů nebo je vyžadována přesná správa přístupu k funkcím pro různé segmenty uživatelů. Pro mobilní aplikace, kde aktualizace klienta trvá dny, poskytují platformy feature flag další výhodu — možnost měnit chování aplikace bez vydání nové verze.
Nástroje pro správu
Výběr nástroje pro správu feature toggles závisí na velikosti týmu, technologickém stacku a bezpečnostních požadavcích. Podívejme se na možnosti od jednoduchých konfiguračních souborů až po průmyslové platformy pro správu, včetně open-source alternativ.
Integrace do CI/CD
Feature toggles by měly být prvotřídními občany CI/CD pipeline. Ve fázi sestavení pipeline kontroluje, zda byly všechny release toggles plánované k odstranění v aktuálním sprintu skutečně odstraněny z kódu. Ve fázi testování se spouštějí maticové testy s různými kombinacemi toggles. Ve fázi nasazení systém automaticky synchronizuje konfiguraci toggles s produkčním prostředím. Integrace s PagerDuty nebo Opsgenie umožňuje vytvářet výstrahy při detekci stale toggles nebo při překročení povoleného počtu aktivních toggles.
Populární řešení
Pro jednoduché scénáře stačí JSON konfigurace v Gitu s code review na změny. Pokročilejší možností — Togglz (Java) nebo Gofeature (Go) — knihovny přidávající minimální UI pro správu toggles. Pro produkční systémy se doporučují Unleash (open-source) s SDK pro všechny jazyky a podporou aktivačních strategií, nebo Flagsmith s vestavěným A/B testováním. LaunchDarkly zůstává standardem pro enterprise projekty s vysokými požadavky na audit a shodu. Pro mobilní aplikace všechna řešení poskytují nativní SDK s cachováním a offline režimem.
Technický dluh a odstranění
Feature toggles jsou oboustranný nástroj. Bez disciplíny správy se mění v technický dluh, který zpomaluje vývoj a zvyšuje složitost kódu. Podle výzkumu CodeScene (2024) obsahuje 35–50 % kódových základen stale toggles — přepínače, které zůstávají v kódu po dokončení zavádění. Podívejme se na strategie prevence a odstranění takového dluhu.
Odstranění toggles
Proces odstranění feature toggle se skládá ze čtyř kroků. První: ujistěte se, že je toggle zapnutý pro 100 % publika nebo vypnutý pro 0 % (v závislosti na tom, která větev kódu má zůstat). Druhý: odstraňte všechny podmíněné kontroly toggle z kódu a ponechte pouze větev, která má být produkčním chováním. Třetí: odstraňte definici toggle z úložného systému (konfigurace, DB nebo platforma). Čtvrtý: spusťte testy pro potvrzení, že odstranění neporušilo funkcionalitu. Každý toggle by měl mít vlastníka a plánované datum odstranění, stanovené při vytvoření přepínače.
Automatizace auditu
Ruční audit toggles je neefektivní při rozsahu nad 50 přepínačů. Automatizace je založena na třech principech: CI kontrola (přítomnost stale toggles blokuje merge), monitorování (dashboard se stářím každého toggle a jeho stavem), výstrahy (upozornění vlastníkovi, pokud se toggle nezměnil po N dní). Nástroje statické analýzy kódu (SonarQube, ESLint plugin) mohou detekovat toggles, které jsou v kódu vždy zapnuté nebo vždy vypnuté — jasný znak stale toggle. Konečná kontrola — code review, při kterém musí recenzent zajistit, že nový toggle je skutečně potřebný a stará větev kódu bude odstraněna.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}Často kladené otázky
Čím se liší feature toggle od feature flag?
Termíny jsou často zaměnitelné, ale technicky je feature toggle binární přepínač v kódu (podmínka if kontrolující konfiguraci). Feature flag je širší koncept zahrnující platformu pro správu s UI, SDK, analytikou a složitými pravidly targetování. Toggle nevyžaduje externí infrastrukturu, flag — obvykle ano.
Jak často je třeba odstraňovat staré toggles?
Release toggles by měly být odstraněny do 1–2 týdnů po dokončení zavádění. Experiment toggles — ihned po dokončení A/B testu. Business toggles vyžadují pravidelný audit (jednou za čtvrtletí). Doporučuje se nastavit CI kontrolu, která blokuje merge, pokud je v PR přidán nový toggle bez úkolu na odstranění v task trackeru.
Lze použít toggles pro mobilní aplikace?
Ano, feature toggles se aktivně používají v mobilním vývoji. Hlavním nástrojem je Firebase Remote Config, který umožňuje dynamicky spravovat přepínače bez vydání nové verze aplikace. Alternativy: LaunchDarkly SDK pro iOS/Android, Unleash SDK, vlastní toggle server s REST API. Je důležité implementovat cachování hodnot pro práci v offline režimu.
Jak testovat kód s feature toggles?
Hlavní metoda — maticové testování: spuštění všech testů se zapnutým a vypnutým toggle. Pro N toggles vyžaduje úplné maticové testování 2^n spuštění, proto se v praxi vybírají kritické kombinace. Unit testy by měly mockovat hodnotu toggle. Integrační testy kontrolují konkrétní scénáře. V CI se přidává krok spouštějící testy s náhodnou kombinací toggles pro odhalení neočekávaných interakcí.
Jaká jsou rizika feature toggles?
Hlavní rizika: 1) stale toggles — kód s oběma větvemi (zapnuto/vypnuto) se stává složitým a obtížně udržovatelným; 2) kombinatorická složitost testování — každý toggle zdvojnásobuje počet stavů; 3) dead code — stará větev zůstává v kódu po trvalém zapnutí toggle; 4) bezpečnost — přepínače řídící přístup vytvářejí zranitelnosti při nesprávné konfiguraci. Všechna rizika jsou zvládnutelná s disciplínou a automatizací.
Shrnutí
- Feature Toggle — binární přepínač funkcionality spravovaný prostřednictvím konfigurace aplikace
- Hlavní typy: business (měsíce-roky), release (dny-týdny), experiment (týdny-měsíce), infrastructure (dny-týdny)
- Feature Toggle vs Flag — toggle je jednodušší (if + konfigurace), flag zahrnuje plnohodnotnou platformu pro správu
- CI/CD integrace je povinná: kontrola stale toggles, maticové testy, synchronizace konfigurace
- Stale toggles — hlavní riziko: 35–50 % kódových základen obsahuje nepoužívané přepínače
- Odstranění toggle vyžaduje proces: potvrďte stav, odstraňte kód, odstraňte konfiguraci, spusťte testy
- Automatizace auditu prostřednictvím CI, dashboardů a statické analýzy kódu zabraňuje hromadění technického dluhu
Vyvineme mobilní aplikaci na klíč
IT Sectr vytváří aplikace pro iOS a Android pro startupy a podniky od roku 2017. Poradíme vám a navrhneme nejlepší řešení.
Přečtěte si také