Open Source Resources

While not all platforms are supported, there are a few open-source libraries that harness the power of feature flags.  Want to see how feature flags work? Check out this Feature Flag Demo by FF4J

Stack Overflow – Discussion regarding feature flags

  • “A ‘feature flag’ (or Feature Toggle) is the ability to turn features (sub-sections) of your application on/off at a moments notice. 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 tho – 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.”

Wiki – Introduction to Feature Toggles & Continuous Delivery

  • “A feature toggle, (also feature switch, feature flag, feature flipper, conditional feature, etc.) is a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches).  Continuous release and continuous deployment provide developers with rapid feedback about their coding. This requires the integration of their code changes as early as possible. Feature branches introduce a bypass to this process. Feature toggles bring developers back to the track, but the execution paths of their features are still “dead” if a toggle is “off”. But the effort is low to enable the new execution paths just by setting a toggle to “on”.”

Martin Fowler – Feature Toggle

  • “One of the most common arguments in favor of FeatureBranch is that it provides a mechanism for pending features that take longer than a single release cycle. Imagine you are releasing into production every two weeks, but need to build a feature that’s going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-implemented feature on your releases? We run into this issue quite a lot and feature toggles are a handy tool to deal with it.”

Mathias Meyer – Using Feature Flags to Ship Changes with Confidence

  • “A feature flag is a branching point that your code can utilize to determine whether or not a feature should be made available to one or more customers. The original approach was made popular by the fine folks at Flickr. They needed a means to disable features when something is broken in production, to reduce the load on the database or on other parts of the system.”

Beautiful Builds – Feature Toggle Framework List

Leonard Garvey – Better development with feature flags

  • “Feature flags are a tool which can be used by software developers to separate a feature from the rest of the code surrounding it. It’s a very simple concept with some very powerful consequences. With a feature flag you can deploy a feature which might not be quite ready for prime-time yet. Deploying early, and often is a good way to keep your team’s progress moving forward. There’s nothing that kills productivity faster than working on the same feature for a really long time without deploying it.”

Jim Bird – Feature toggles and technical debt

  • Feature flags or config flags aka feature toggles aka flippers are an important part of Devops practices like dark launching (releasing features immediately and incrementally), A/B testing, andbranching in code or branching by abstraction (so that development teams can all work together directly on the code mainline instead of creating separate feature branches).  Feature toggles can be simple Boolean switches or complex decision trees with multiple different paths. Martin Fowler differentiates between release toggles (which are used by development and ops to temporarily hide incomplete or risky features from all or part of the user base) and business toggles to control what features are available to different users (which may have a longer – even permanent – life). He suggests that these different kinds of flags should be managed separately, in different configuration files for example. But the basic idea is the same, to build conditional branches into mainline code in order to make logic available only to some users or to skip or hide logic at run-time, including code that isn’t complete (the case for branching by abstraction).

Ross Harmes @ Flickr – Flipping out

  • “Flickr is somewhat unique in that it uses a code repository with no branches; everything is checked into head, and head is pushed to production several times a day. This works well for bug fixes that we want to go out immediately, but presents a problem when we’re working on a new feature that takes several months to complete. How do we solve that problem? With flags and flippers! Flags allow us to restrict features to certain environments, while still using the same code base on all servers.”

João Miranda – How Etsy Deploys More Than 50 Times a Day

  • “Etsy’s development approach revolves around making many small, continuous changes. A direct consequence is the need to do many deployments a day. In the words of Daniel Schauenberg, at any given time every Etsy developer needs to know the answer to the question “how comfortable am I with deploying a change right now?”. To be comfortable at all times, Etsy adopted a range of tools and practices: mandatory IRC-based communication; developer virtual machines; continuous integration; one-click deployments; thorough application and system monitoring; no blame post-mortems and on-call policies for both dev and ops teams.”