Coding with Feature Flags: How-to Guide and Best Practices

{{#if config.showNewCart}}
{{> newCart}}
{{else}}
{{> cart}}
{{/if author}}
if(config.useMoneris) {
this.sendTransactionMoneris(...);
}
else {
this.sendTransactionPayPal(...);
}

Working with Feature Flags

Types of Feature Flags

  • Release toggles: More often than not these are on/off switches that are used to control whether a feature is enabled or not. They are short-lived and removed after the feature is released.
  • Operational toggles: Typically used to control flow on the back end. An example could be algorithm changes, upgrading or retiring old APIs, etc. These are also short-lived and ought to be removed after the task is complete.
  • Experimental Toggles: These are typically used for A/B or multivariate testing and are typically longer-lived flags that can be removed once we no longer need to collect user testing data.
  • Permission Toggles: This is commonly talked about and is used to control the product experience users have. I think doing this is actually a bad use case for feature flags and personally don’t recommend it. This sort of information would be coming from your user properties.

It is a good practice to keep feature flags are short-lived as possible. Keeping their number low is equally important.

  • Hard-coded constants: Slightly hacky but we’ve all created constants which could serve as default input. Then we later change the input and re-deploy. These are pretty static since they require a re-deploy.
  • Config files: These can come as JSON, template files, and could also be your environment config files. They’re convenient and also require a re-deploy.
  • Database configs: We can store application settings in a database. It is a pretty standard and convenient place to store your settings. These settings can often be updated easily in the database and often use an administration interface.
  • Open Source Libraries: Build specifically for feature flag management and can usually be updated on run-time. Installation and maintenance is often the biggest challenge with such libraries or even proprietary solutions.
  • Third-Party Service: SaaS model type of solution, is highly dynamic, and usually comes with SDKs, documentation, analytics and so on.

Coding with Feature Flags

function search() {
if(flagSdk.getFlag(NEW_ALGORITHM)) {
// new implementation
}
else {
// old implementation
}
}
function search(useNewAlgorithm) {
if(useNewAlgorithm) {
// new implementation
}
else {
// old implementation
}
}
... old search module
function search(...) {
// old implementation
}
... new search module
function search(...) {
// new implementation
}
... controller
let modSearch = useNewAlgorithm ? NewSearch : OldSearch;
modeSearch.search(…);
... controller
let factory = new MyFeatures(configsJson);
fff.getSearch().search(...);

Deciding When to Create a Feature Flags

  • Are flags being created for features that are too small? I’ve been asked once whether a flag should be used to fix a bug. While it’s possible to make bugs a lot worse, this is where I would draw the line.
  • Are there many flags because they’re not being cleaned up? It’s easy to get caught up with other work and never clean up after ourselves. This is especially true in cases where stakeholders have seen the feature and are happy with it. It is the developer’s responsibility to ensure they are cleaned up.
  • Are teams not coordinating about feature flags that they are using? If different teams are creating multiple feature flags for the same feature testing and releasing can be a pretty painful task.

Monitoring Feature Flag Usage and Clean Up

Proprietary Solution vs Feature Flag Platform

Some History About … Branching

CI is about exposing our changes as frequently as possible, so that we can get great feedback on our ideas, branching, any form of branching, is about isolating change. A branch is, by-design, intended to hide change in one part of the code from other developers. It is antithetical to CI…

— Farley

Final Thoughts …

  • Feature flags have been around for a long time because they are simple to use and developers felt productive when using them. We’ve introduced sophisticated tools and processes to improve velocity and quality. With this, we’ve also added complexity. It might be a time to simplify and bring the flags back.
  • Feature flags can work well for companies but in general it’s best to keep feature flags short-lived and small in number. Too many flags or long-lived flags add complexity and are deliberate tech debt. Cleaning up feature flags is important to keep a codebase sane.
  • Using feature flags can help companies to ship more often, minimize risk, increase productivity, and even help with targeting users and A/B test features. Evaluating a company’s branching strategy with feature flags can be very worth it, especially if you need to ship frequently.
  • Keep coupling with feature flags service to minimum, create a config abstraction layer and try to avoid having flags in your core.

References

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tim Hysniu

Tim Hysniu

Software Engineer, Technology Evangelist, Entrepreneur