Literature

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.”

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.”

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

• “Also known as Feature Bits and Feature Flags, here is a list of some of the frameworks you can find in the wild for your favorite language.”

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, and branching 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.”

James Stanier – Engineering a successful product launch

• “Extensive use of feature flags can save all manner of headaches. Continually releasing code behind a flag means that large features don’t end up in branches of the codebase that remain unmerged for long periods of time, needing painful rebasing before they go into master. Instead, shipping code behind a flag means you can merge small increments of functionality as you go, without the user ever knowing.
  Feature flags are great.”

Grischa Ekart – Feature Toggles Revisited

• “Proper implementation of feature toggles based on a categorisation of their longevity and dynamism helps dealing with their operational complexity according to Pete Hodgson, consultant at ThoughtWorks. In his post he expands Martin Fowler’s FeatureToggle pattern and proposes the release, ops, experiment and permission toggle categories and implementation strategies. In large projects, the difficulty to continually deliver releases calls for feature toggles.”

Alexandre Touchard – Feature Toggles (Feature Switches or Feature Flags) vs Feature Branches

• “People tend to like feature branches. They provide flexibility to decide what to release and when. All there is to do is to merge features that will be released into the main branch and deploy to production. The problem with this approach is the delay. Integration is delayed until the merge. We cannot know whether all those separately developed features work well together until the merge is done and all the unit, functional, integration and manual tests are run. On top of that, there is the problem caused with the pain of merge itself. Days, weeks or even months of work are suddenly merged into the main branch and from there to all not-yet-to-be-released branches. The idea of Continuous Integration is to detect problems as soon as possible. Minimum delay until problems are found.”