What is a “feature flag”?

by

A ‘feature flag’ (or Feature Toggle) is the ability to turn features (sub-sections) of your application on/off at easily:

  • perhaps via a re-deploy, or
  • some internal page where pages/features can be toggled live.

I guess the example there was that it’s handy to have the control to reduce the feature-set somewhat if you need to, say, reduce db queries if the load is too high.

There are heaps of other reasons you would want to use this though – one of the main being enabling Continuous Delivery: pushing things into production/live yet having the feature disabled/toggled until it’s completed. We often use what we call a ‘dev cookie’ to show uncompleted features to just the dev team. This way we can test partially completed work in production (oh yeh! is there better integration?) over multiple releases/deployments before we ‘untoggle’ (completed) it and it becomes visible to the public.

Here’s a simple package that helps you do this in ASP.NET MVC land: https://github.com/cottsak/DevCookie (full disclosure: I’m the author)

Fowler also has a much longer article than the one linked above with a lot more details.

This post (on Fowler’s site also) explains the various types of toggle strategies. DevCookie supports the mainline/trunk-based strategy and is called a “Release Toggle” in the article.

Adil’s answer highlights that there are many terms and reasons why you might want some of this infrastructure. Keep in mind you may only need some of these things. For example, I may only want to enable a simple, and agile deployment/delivery workflow and so a simple infrastructure will suffice. If you then choose you want to move into full #leanstartup experimentation with A/B, cohort testing and things like controlled roll-out, you should consider an analytics tool (e.g. Heap) which facilitates those data-driven development methodologies as a distinct solution. A toggle infrastructure that does all of the above will lead to bloat and unnecessary complexity.

If you made it this far, then you might like to check out some of my other thoughts on Mainline Development, feature toggling, and other silly ideas like TEST, QA, SIT, STAND, CROUCH.

More Related Contents:

  1. Logout: GET or POST?
  2. What’s the difference between “Layers” and “Tiers”?
  3. Component based game engine design [closed]
  4. Domain Driven Design: Domain Service, Application Service [closed]
  5. Why do stacks typically grow downwards?
  6. What is N-Tier architecture?
  7. Servicestack – architecture & reusing POCOs for everything
  8. what is a store buffer?
  9. When are you truly forced to use UUID as part of the design?
  10. On 32-bit CPUs, is an ‘integer’ type more efficient than a ‘short’ type?
  11. What am I not understanding about REST?
  12. Microservices – best practices to retrieve the related data to specific user from the other micro services with the minimal memory/time loss
  13. Best way to store Badge criteria?
  14. How do you organize your small reusable cffunctions?
  15. dma vs interrupt-driven i/o
  16. Difference between a “coroutine” and a “thread”?
  17. How to list supported target architectures in clang?
  18. What is opinionated software?
  19. How to detect target architecture using CMake?
  20. CMake Multiarchitecture Compilation
  21. DDD, Anti Corruption layer, how-to?
  22. Where should I store photos? File system or the database? [duplicate]
  23. What’s the difference between REST & RESTful
  24. When to Redis? When to MongoDB? [closed]
  25. How to write a scalable TCP/IP based server
  26. How to version control a record in a database [closed]
  27. How Scalable is SQLite? [closed]
  28. WebRTC – scalable live stream broadcasting / multicasting
  29. Increasing PHP memory_limit. At what point does it become insane?
  30. Structuring projects & dependencies of large winforms applications in C#

Leave a Comment