High Scalability mentions feature flags here:
5 things toxic to scalability, “5. Lack of Feature Flags”
What exactly are feature flags?
High Scalability mentions feature flags here: 5 things toxic to scalability , 5. Lack
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
High Scalability mentions feature flags here:
5 things toxic to scalability, “5. Lack of Feature Flags”
What exactly are feature flags?
A ‘feature flag’ (or Feature Toggle) is the ability to turn features (sub-sections) of your application on/off at easily:
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.