Feature Toggling Strategies

From CitconWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Attendees: @robpark, Johnny S, Andy, Jason, Lex

  • How do you deal with conditionals
    • Implement at the interface level
    • If you see conditionals littered throughout your code, you're likely missing a layer of abstraction
  • Why toggle?
    • To be able turn a feature on/off
  • Strategies
    • per user
    • algorithmically - needs to be consistent for a given user though
  • clean up?
    • what if the user can turn it on?
    • installed software vs webapp
  • testing
  • metrics
  • use feature flags; they're good
  • don't have too many
    • is that 80? 5?
  • use if not all of your users can be exposed to the feature
  • they may not be binary; they could be enumerations
  • a good measure may be "if you sales people can call it out, then it's big enough to need a toggle"
  • feature flags may follow the same rules as using many branches effectively
  • although if you should avoid getting to the point of needing to manage dependencies across feature flags
  • are you now version-less? no semver?
    • or versioning is at least decoupled from deployment
    • "for this release we'll just turn on these 10 flags"
    • the "current version" is the current "default" set of flags
  • what shouldn't be behind a feature flag?
    • bug fixes