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 ❗️

Made with Slides.com