Feature toggling
-
Upload
t-alexander-lystad -
Category
Software
-
view
168 -
download
0
Transcript of Feature toggling
Feature toggling(feature toggles, feature flags, feature switches, feature bits, feature flippers, …)
T. Alexander LystadChief QA Architect, VES Dev
Toggle Pointsvar r;var newFeatureIsEnabled = false;if (newFeatureIsEnabled) {
r = someNewFunction();} else {
r = someOldFunction();}
Toggle Pointsvar r;var newFeatureIsEnabled = false;if (newFeatureIsEnabled) {
r = someNewFunction();} else {
r = someOldFunction();}
● Configuration (on/off) stored in the application code
● Can only be toggled (enabled/disabled) during development
Toggle Configuration● Properties
○ State■ On■ Off
○ Time■ From■ To
○ User/Organization/Customer/Company■ Role■ Percentage■ Location■ Id■ …
○ ...
Toggle Configuration● Storage
○ (Application code)○ Configuration file○ Application database○ Separate service
● Toggling○ (At development time)○ (At build time)○ (At deployment time)○ (At start-up time)○ At run-time
Continuous Integration
Code should not live outside of the main branch (for long)
Continuous Delivery
Code should not live outside of Production (for long)
Continuous Integration
Code should not live outside of the main branch (for long)
e.g. max 1 day
Continuous Delivery
Code should not live outside of Production (for long)
e.g. max 3 days
Some features will take longer to implement● Local copy● Feature branch● Feature toggle● Incrementally on main branch (easier for new functionality)
Some features will take longer to implement● Local copy● Feature branch● Feature toggle● Incrementally on main branch (easier for new functionality)● Branch by abstraction (technique for larger-scale changes)● Branch by abstraction + feature toggle
Internal testing in Production● In order to achieve a fully automated delivery pipeline, manual QA must be
moved outside of the delivery pipeline○ Before pipeline
■ Cross-functional discussion■ Code review■ Show me session
○ After pipeline■ Testing in Production = Enabling features in Production for internal users
Canary Releasing● of an application (Canary Deployment)
○ Subset of infrastructure as canaries○ Incremental upgrade
● of a feature (Canary Release)
○ Subset of users as canaries○ Incremental toggle
● Monitoring
Dark Launching● Large scale real-life testing● Enabling and exercising a feature in
Production without showing it the user
● To test with realistic data and load● Different from internal testing● Different from canary releasing● Used for rolling out Facebook chat in
2008● Does not require feature toggles, but
is often used with canary release which does
● To coordinate with marketing material, events, etc● To coordinate with laws and regulations● To release a feature simultaneously across services
Examples
A/B testing is a science in its own right● There are specialized A/B testing tools out there● Traditional A/B testing is one of multiple possible ways to approach the multi-
armed bandit problem
Best practices● Feature Toggles have a cost
○ More complex code, more testing, maintenance overhead
● Feature Toggles should be regarded as an investment, use when ROI>0● Implement carefully to minimize complexity and technical debt● Have a good overview over which feature toggles exist, for what purpose,
what state they are in and why● Have a process for removing unnecessary feature toggles
○ Most of them should be temporary