+ All Categories
Home > Software > Feature toggling

Feature toggling

Date post: 22-Mar-2017
Category:
Upload: t-alexander-lystad
View: 168 times
Download: 0 times
Share this document with a friend
51
Feature toggling (feature toggles, feature flags, feature switches, feature bits, feature flippers, …) T. Alexander Lystad Chief QA Architect, VES Dev
Transcript

Feature toggling(feature toggles, feature flags, feature switches, feature bits, feature flippers, …)

T. Alexander LystadChief QA Architect, VES Dev

Definition of a feature toggleMechanism for easily enabling or disabling certain system behavior

All developers have used feature togglesvar r = someOldFunction();//var r = someNewFunction();

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

Toggle Context● Conditions at evaluation time

○ Current time○ Current request/task○ Current user

UI Examples

VIGO

Visma.net Payroll

eAccounting

eAccounting

5 use cases

Separating release and deployment● Deploy software/builds/versions● Release features

Use case #1Continuous Integration and Continuous Delivery of

incomplete features

Continuous Integration

Code should not live outside of the main branch (for long)

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

Some features will take longer to implement● Local copy● Feature branch● Feature toggle

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

Branch by Abstraction

Branch by Abstraction

Branch by Abstraction

Branch by Abstraction

But, wait● What if we want to switch to the new

implementation for all clients at the same time?

Feature Toggle

Use case #2Gradual release: Internal testing, canary releasing

and dark launching

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

Use case #3Timed release

● To coordinate with marketing material, events, etc● To coordinate with laws and regulations● To release a feature simultaneously across services

Examples

HRM

HRM

Use case #4A/B testing and other forms of experimentation

A/B testingA B

A/B testingA B

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

Use case #5Circuit breakers

Dialing it down or turning it off● High risk features

○ e.g. functionality, performance

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

LaunchDarklyFeature toggling as a service

Custom implementation?Feature toggle library?

External service?

featureflags.io


Recommended