Feature Toggle — basisprincipes, schakeltypen en toepassing
Feature Toggle is een mechanisme om de functionaliteit van een applicatie tijdens runtime te schakelen, waardoor ontwikkelaars de beschikbaarheid van functies kunnen beheren zonder code te wijzigen of opnieuw te implementeren. In tegenstelling tot conditionele compilatie (ifdef) werkt toggle op runtime-niveau en kan dynamisch worden gewijzigd. Volgens Martin Fowler (2024) zijn feature toggles een sleutelelement van trunk-based development en continue levering. Feature toggle geeft teams flexibiliteit bij het beheren van releases en experimenten.
Belangrijkste punten
- Feature Toggle — een dynamische schakelaar die het gedrag van de applicatie via configuratie regelt
- Hoofdtypen: business toggles, release toggles, experiment toggles en infrastructure toggles
- Feature Toggle vs Flag — toggle verwijst vaker naar eenvoudige binaire schakelaars, flag naar volwaardige platforms
- Integratie met CI/CD maakt automatische controle en testen van toggles in elke fase van de pipeline mogelijk
- Hoofdprobleem — ophoping van stale toggles die regelmatig geaudit en verwijderd moeten worden
Wat is Feature Toggle
Feature Toggle (functieschakelaar) — is een techniek waarbij de code van een nieuwe functie wordt ingepakt in een conditionele constructie die de waarde van een configuratieparameter controleert. Als de parameter true is — is de nieuwe functionaliteit actief, als false — wordt de oude code uitgevoerd. Het belangrijkste verschil met feature flag is dat toggle een binaire schakelaar is die werkt volgens het principe „aan/uit”, zonder complexe doelgroep- en verkeersdistributieregels.
Definitie en werkingsprincipe
Feature toggle wordt geïmplementeerd als een gewone if-constructie rond de nieuwe functionaliteit. De waarde van de toggle wordt opgeslagen in de applicatieconfiguratie — omgevingsvariabelen, JSON-bestand of database. Bij het opstarten laadt de applicatie de configuratie en gebruikt deze om beslissingen te nemen over de zichtbaarheid van functies. In het eenvoudigste geval vereist het wijzigen van de toggle-waarde een herstart van de applicatie, maar in productiesystemen ondersteunen toggles meestal hot reload via een externe configuratieserver of API.
Voorbeeld van een eenvoudige toggle
Laten we de implementatie van feature toggle in JavaScript (Node.js) bekijken. De schakelaar wordt opgeslagen in een JSON-configuratie en geladen bij het opstarten van de server. Middleware controleert de toggle-waarde voordat het verzoek naar de nieuwe of oude handler wordt gestuurd. Een dergelijke implementatie maakt het mogelijk nieuwe functionaliteit aan de hoofdtak van de code toe te voegen zonder de werking van de huidige API-versie te verstoren.
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);
});Typen feature toggles
Pete Hodgson van ThoughtWorks onderscheidt drie hoofdtypen feature toggles, ingedeeld naar levensduur en gebruiksdoel. Het juist bepalen van het toggle-type helpt bij het kiezen van het juiste opslagmechanisme en beheerproces. Laten we elk type bekijken in de context van mobiele ontwikkeling.
Business en Release toggles
Business toggles — de langstlevende schakelaars. Ze beheren bedrijfsregels die alleen beschikbaar zijn voor bepaalde categorieën gebruikers (premiumfuncties, regionale kenmerken). Dergelijke toggles kunnen jaren meegaan en hebben meestal een complexere logica dan binair aan/uit. Release toggles — tijdelijke schakelaars om onvoltooide functionaliteit te verbergen. Hun levenscyclus varieert van enkele dagen tot enkele weken. Na voltooiing van de functionaliteit wordt de release toggle uit de code verwijderd. Deze toggles vormen de basis van trunk-based development, waardoor ontwikkelaars in de hoofdtak kunnen committen zonder te wachten op de voltooiing van de gehele functionaliteit.
Experiment en Infrastructure toggles
Experiment toggles worden gebruikt voor A/B-tests en gefaseerde uitrol. In tegenstelling tot release toggles ondersteunen experiment toggles procentuele gebruikersdistributie en integratie met analysesystemen. Ze kunnen langer meegaan dan release toggles (tot enkele maanden), maar moeten na afloop van het experiment worden verwijderd. Infrastructure toggles — schakelaars voor het beheren van infrastructuurwijzigingen: databasemigratie, overstap naar een nieuwe API-provider, wijziging van cache-algoritmen. Deze toggles vereisen speciale aandacht bij het testen, omdat het omschakelen ervan de stabiliteit van de hele dienst beïnvloedt.
| Toggle-type | Duur | Doelgroep | Voorbeeld |
|---|---|---|---|
| Business | Maanden-jaren | Per rol/regio | Premiumfuncties |
| Release | Dagen-weken | Ontwikkelaars/QA | Onvoltooid scherm |
| Experiment | Weken-maanden | % gebruikers | A/B-test interface |
| Infrastructure | Dagen-weken | Intern | DB-migratie |
Feature Toggle vs Feature Flag
Hoewel de termen „feature toggle” en „feature flag” vaak door elkaar worden gebruikt, zijn er conceptuele verschillen tussen beide. Het begrijpen van deze verschillen helpt bij het kiezen van het juiste instrument voor een specifieke taak en het voorkomen van verwarring in het team. Laten we de belangrijkste verschillen en toepassingsgebieden van elke benadering bekijken.
Verschillen in benadering
Feature toggle — is in de eerste plaats een technisch mechanisme: een binaire schakelaar ingebouwd in de applicatiecode. Toggle wordt beheerd via configuratie en vereist geen externe infrastructuur. Feature flag — is een breder concept dat een beheerplatform omvat: UI voor configuratie, SDK voor integratie, gebruiksmonitoring, analyse en audit. Flags ondersteunen complexe doelgroepregels (per regio, versie, apparaat), A/B-experimenten en automatische verwijdering. Men kan zeggen dat feature flag de evolutie is van feature toggle: het team begint met eenvoudige configuratieschakelaars en stapt naarmate het groeit over naar een gespecialiseerd platform.
Wanneer is toggle voldoende
Voor kleine teams en projecten met één dienst of monoliet zijn eenvoudige configuratietoggles volledig voldoende. Als u 5–10 ontwikkelaars en 1–2 gelijktijdig actieve toggles heeft — is een extern platform overbodig. Feature flag-platforms (LaunchDarkly, Unleash) worden noodzakelijk wanneer het aantal actieve flags 20–30 overschrijdt, het team 20+ ontwikkelaars telt, of nauwkeurig toegangsbeheer tot functies voor verschillende gebruikerssegmenten vereist is. Voor mobiele applicaties, waar het bijwerken van de client dagen duurt, bieden feature flag-platforms een extra voordeel — de mogelijkheid om het gedrag van de applicatie te wijzigen zonder een nieuwe versie uit te brengen.
Beheerinstrumenten
De keuze van een instrument voor het beheren van feature toggles hangt af van de teamgrootte, de technologiestack en de beveiligingseisen. Laten we de opties bekijken van eenvoudige configuratiebestanden tot industriële beheerplatforms, inclusief open-source alternatieven.
Integratie in CI/CD
Feature toggles moeten eersteklas burgers van de CI/CD-pipeline zijn. In de build-fase controleert de pipeline of alle release toggles die gepland staan voor verwijdering in de huidige sprint daadwerkelijk uit de code zijn verwijderd. In de testfase worden matrixtests met verschillende toggle-combinaties uitgevoerd. In de deploy-fase synchroniseert het systeem automatisch de toggle-configuratie met de productieomgeving. Integratie met PagerDuty of Opsgenie maakt het mogelijk waarschuwingen te creëren bij detectie van stale toggles of bij overschrijding van het toegestane aantal actieve toggles.
Populaire oplossingen
Voor eenvoudige scenario's is JSON-configuratie in Git met code-review op wijzigingen voldoende. Een meer geavanceerde optie — Togglz (Java) of Gofeature (Go) — bibliotheken die een minimale UI toevoegen voor het beheren van toggles. Voor productiesystemen worden Unleash (open-source) met SDK voor alle talen en ondersteuning voor activatiestrategieën, of Flagsmith met ingebouwd A/B-testen aanbevolen. LaunchDarkly blijft de standaard voor enterprise-projecten met hoge audit- en compliance-eisen. Voor mobiele applicaties bieden alle oplossingen native SDK met caching en offline-modus.
Technische schuld en verwijdering
Feature toggles zijn een tweesnijdend zwaard. Zonder beheerdiscipline veranderen ze in technische schuld die de ontwikkeling vertraagt en de codecomplexiteit verhoogt. Volgens onderzoek van CodeScene (2024) bevat 35–50% van de codebases stale toggles — schakelaars die in de code blijven na voltooiing van de uitrol. Laten we strategieën bekijken voor het voorkomen en verwijderen van dergelijke schuld.
Verwijderen van toggles
Het proces van het verwijderen van een feature toggle bestaat uit vier stappen. Eerste: zorg ervoor dat de toggle is ingeschakeld voor 100% van het publiek of uitgeschakeld voor 0% (afhankelijk van welke codetak moet blijven). Tweede: verwijder alle conditionele toggle-controles uit de code en laat alleen de tak over die het productiegedrag moet zijn. Derde: verwijder de toggle-definitie uit het opslagsysteem (config, DB of platform). Vierde: voer tests uit om te bevestigen dat het verwijderen de functionaliteit niet heeft gebroken. Elke toggle moet een eigenaar en een geplande verwijderdatum hebben, vastgesteld bij het aanmaken van de schakelaar.
Automatisering van audit
Handmatige audit van toggles is inefficiënt bij een schaal van meer dan 50 schakelaars. Automatisering is gebaseerd op drie principes: CI-controle (aanwezigheid van stale toggles blokkeert merge), monitoring (dashboard met de leeftijd van elke toggle en zijn status), waarschuwingen (melding aan de eigenaar als de toggle N dagen niet is gewijzigd). Tools voor statische code-analyse (SonarQube, ESLint plugin) kunnen toggles detecteren die altijd aan of altijd uit staan in de code — een duidelijk teken van een stale toggle. De definitieve controle — code-review, waarbij de reviewer ervan moet verzekeren dat de nieuwe toggle echt nodig is en de oude codetak zal worden verwijderd.
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
}Veelgestelde vragen
Waarin verschilt feature toggle van feature flag?
De termen worden vaak door elkaar gebruikt, maar technisch is feature toggle een binaire schakelaar in de code (if-voorwaarde die de configuratie controleert). Feature flag is een breder concept dat een beheerplatform omvat met UI, SDK, analyse en complexe doelgroepregels. Toggle vereist geen externe infrastructuur, flag meestal wel.
Hoe vaak moeten oude toggles worden verwijderd?
Release toggles moeten binnen 1–2 weken na voltooiing van de uitrol worden verwijderd. Experiment toggles — onmiddellijk na voltooiing van de A/B-test. Business toggles vereisen regelmatige audit (per kwartaal). Het wordt aanbevolen een CI-controle in te stellen die merge blokkeert als een nieuwe toggle wordt toegevoegd in een PR zonder verwijderingstaak in de task tracker.
Kunnen toggles worden gebruikt voor mobiele applicaties?
Ja, feature toggles worden actief gebruikt in mobiele ontwikkeling. Het belangrijkste instrument — Firebase Remote Config, waarmee schakelaars dynamisch kunnen worden beheerd zonder een nieuwe versie van de applicatie uit te brengen. Alternatieven: LaunchDarkly SDK voor iOS/Android, Unleash SDK, een eigen toggle-server met REST API. Het is belangrijk caching van waarden te implementeren voor werking in offline-modus.
Hoe test ik code met feature toggles?
De belangrijkste methode — matrix-testen: het uitvoeren van alle tests met ingeschakelde en uitgeschakelde toggle. Voor N toggles vereist volledig matrix-testen 2^n uitvoeringen, daarom worden in de praktijk kritische combinaties gekozen. Unittests moeten de toggle-waarde mocken. Integratietests controleren specifieke scenario's. In CI wordt een stap toegevoegd die tests uitvoert met een willekeurige combinatie van toggles om onverwachte interacties te detecteren.
Wat zijn de risico's van feature toggles?
Belangrijkste risico's: 1) stale toggles — code met beide takken (aan/uit) wordt complex en moeilijk te onderhouden; 2) combinatorische complexiteit van testen — elke toggle verdubbelt het aantal toestanden; 3) dead code — de oude tak blijft in de code nadat de toggle permanent is ingeschakeld; 4) beveiliging — schakelaars die toegang beheren creëren kwetsbaarheden bij onjuiste configuratie. Alle risico's zijn beheersbaar met discipline en automatisering.
Samenvatting
- Feature Toggle — binaire functieschakelaar beheerd via applicatieconfiguratie
- Hoofdtypen: business (maanden-jaren), release (dagen-weken), experiment (weken-maanden), infrastructure (dagen-weken)
- Feature Toggle vs Flag — toggle is eenvoudiger (if + config), flag omvat een volledig beheerplatform
- CI/CD-integratie is verplicht: controle op stale toggles, matrixtests, synchronisatie van configuratie
- Stale toggles — het grootste risico: 35–50% van de codebases bevat ongebruikte schakelaars
- Verwijderen van toggle vereist een proces: bevestig status, verwijder code, verwijder config, voer tests uit
- Automatisering van audit via CI, dashboards en statische code-analyse voorkomt ophoping van technische schuld
We ontwikkelen een mobiele applicatie turnkey
IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.
Lees ook