Power to the toggles
...how feature flags liberate your development workflow
A story in three parts
🎚
🚦
II. Encyclopedia
III. Enable your self
I. The Goal
What's next
Software engineering is like gambling
Many small bets over one big bet to increase chances
Imagine canceling
your small bets early.
Part I
The Goal
Customer value
Often unclear upfront with many unknowns
Innovation has many uncertainties
Embrace failure and open communication
Ways of working
Short iterations with small-ish deliverables
Feedback serves as guidance and reduces cost of failure
Continous learning and reflections
Ways of engineering
Decrease the cost of a release to zero
Optimise for speed not for predicability
Reduce the necessity to coordinate
Integrate early yielding no fear to release
Part II
Encyclopedia
Manually (by one or more) < automatic
Limited frequencies < every change
How to release
From Continous Integration > developer machine
Targeted rollouts: by user group, percentage based buckets, stage or cloud region
Reverting is a lot more difficult than turning a feature off again.
Deploying often, means smaller changes,
means less breakage
Why toggle?
A boolean or a variation
Not hard coded, magic button or query parameters
Configured externally, value is not part of your source code
What is a toggle
Part III
Enable yourself
In action
💨 ...in realtime 🏎
Before
After
A case study
Flop or flip a switch
Hasty late night rollbacks
Good
Bad
Always all users affected
Many environments for testing
Merge seldom and big deploys
Controlled and targeted rollouts
Blue-green (two envs) deployment
Small changes deployed every day
Early feedback and hypothesis validation
Incremental development workflow
Product implications
Early user involvement and testing
Too pragmatic UX - non cohesive product
Too many toggles - no clean up
Threats
Unclear status - what is toggled what's not
Code or didn't happen
<ToggleFeature flag="featureFlagName">
<Link to="url/to/new/feature" />
</ToggleFeature><ToggleFeature flag="featureFlagName">
{({ isFeatureEnabled }) => (
<button disabled={!isFeatureEnabled} onClick={this.handleClick}>
Try out feature
</button>
)}
</ToggleFeature>function ComponentWithFeatureToggle(props) {
const isFeatureEnabled = useFeatureToggle('myFeatureToggle');
return (
<h3>{props.title}<h3>
<p>
The feature is {isFeatureEnabled ? 'enabled' : 'disabled'}
</p>
);
}
Roll out API changes without deploys
GraphQL directive `@toggle(flag: string)`
What's next?
Traffic shaping based on rules
Declarative in SDL
type Author {
id: Int!
fullName: String @deprecated(reason: "Use \`firstName\` and \`lastName\`.")
firstName: String
lastName: String
posts: [Post]
}
type Post {
id: Int!
title: String
author: Author
votes: Int @toggle(flag: "votesOfPost")
}The `toggle` directive would to the rest in an e.g. Apollo Server
❗️ Thanks ❗️