Architecture people tend to speak in trivial examples. Swapping out an algorithm with a backwards compatible one? Good for you! It doesn't matter how you do it because it's the most trivial example one could think of. (A more realistic example would be new functionality that touches large parts of the code base, or compliance with a new API that the payment processor switches that has more data on every payment as it crosses our systems.)<p>I never understood why some people are scared of branching. It seems to work pretty well for Linux development. Is your project really that much more complex? As long as you merge continously from upstream, you're golden. What's the problem you're trying to solve, exactly?<p>I _do_ have some reservations against #ifdef-sprinkled code. And it's not an unlikely scenario that your feature toggles turn into something very similar, if conditions change and maybe they're not that temporary anymore.
I find the `scientist` gem by GitHub [1] a very nice way to approach the problem of testing alternative implementations.<p>Basically `scientist` always runs both the original code and the new code.<p><pre><code> def allows?(user)
science "widget-permissions" do |e|
e.use { model.check_user(user).valid? } # old way
e.try { user.can?(:read, model) } # new way
end # returns the control value
end
</code></pre>
It returns the result given by the original code, but it also compares both results and store statistics about when the two codes produce different results. This allows you to run experiments directly in the deployed branch without any service disruption.<p>[1] <a href="https://github.com/github/scientist" rel="nofollow">https://github.com/github/scientist</a>
A more powerful version of these things are called dynamic variables, and they're worth some study beyond feature selection and testing: Otherwise you just get global variables with funny names.<p>Many languages have some dynamic variables (this, self), and few languages have first-class support for them (notably CL, Perl). While dynamic variables are tricky to emulate fully, as long as you have the ability to catch exceptions and closures, a very fair simulation can be made:<p><pre><code> (function(){
var o={};
D=function(k){return o[k]}
dlet=function(b,f){
var r,s={};function oops(){for(var k in s)o[k]=s[k]};
for(var k in b)s[k]=o[k],o[k]=b[k];
try{r=f()}catch(e){oops();throw e;}; oops();return r;
};
})();
</code></pre>
Besides feature variables that are globally accessible, one useful thing you can do with dynamic variables is set up <i>error handlers</i>. Consider the situation where you are saving a big file to the disk and run out of space. If you:<p><pre><code> save_stuff(); if(oops)throw 'out of space'; save_more_stuff();
</code></pre>
then your slow saving operation needs to be retried from the start, however if you use a dynamic variable to look up the handler, you can:<p><pre><code> save_stuff(); if(oops)D('out of space')(next); else next();
function next(){ save_more_stuff(); }
</code></pre>
The user can then use their fancy multitasking environment to clean up some space, and we can continue our operation. I generally recommend this form of error handling anyway.<p>Another useful thing is for context: Imagine you have a user interface choice between an HTTP response and a command line interface. One way to do this is to have two applications, and another way is DI (dependancy injection: pass the "response" object around), however <i>another</i> way is using dynamic variables:<p><pre><code> D("output")(...);
</code></pre>
This has the benefit of not requiring an extra argument to all of your functions.<p>This happens more than you might think: Many people when confronted with all their dynamic variables put them into some kind of "master object" (current logged in user, output handler, database settings, etc), however dynamic variables<p>When you do this, a lot of features become very easy to set:<p>• Capturing output (simply mock a new "output" var)<p>• Testing logic: dlet({db:test_settings},r)===dlet({db:live_settings},r)<p>• Impersonate users (if the right credentials are available)<p>And so on.
At IMVU we had feature toggles rolled into the A/B Experiment system. It proved to be a vital part of Continuous Deployment.<p>Basically: Wrap every new feature in an Experiment Toggle. Deploy to production (once ready for 'non sandbox' testing). Turn on for test users, test. If good, start the rollout to experimental users. If after weeks the numbers worked out, turn it on for everyone...<p>...but if at any point unexpectedly bad things happened, just flip the feature toggle switch. Most of the time if "bad things" were happening in a relatively new feature, this would stop the panic and let analysis of the root cause of the problem happen without the pressure of everything being on fire.
One point to be aware of with feature toggles: if you're using them as a substitute for branching and merging in your VCS, you're deploying code into production that you know for a fact to be buggy, insufficiently tested, and incorrect. If your feature toggles themselves have bugs, or don't properly isolate your new code, you could easily run into problems up to and including data corruption. You may be switching your controllers on and off, but are you also toggling your static assets such as HTML, CSS and JavaScript?<p>People are often scared of feature branches because of large, tricky merge conflicts. However, large, tricky merge conflicts warn you (noisily) of problems such as these before your code gets into production. Problems with feature toggles, on the other hand, don't show up until after your code gets into production, by which time it may well be too late.
Overall feature toggles are an interesting idea. I'm not quite as adverse to long lived branches as some seem to be, especially with CI systems that can automatically detect merge conflicts when they first occur and run automated tests on the merged code base.<p>However, this part seems strange to me:<p>> The team particularly appreciate that this will allow them to test their new algorithm without needing a separate testing environment.<p>Even with feature toggles, I would never want to test a new feature for the first time in my production environment. Sure, the feature isn't on for everyone. But it still can have a performance defect that brings the overall system to its knees or a functionality defect that corrupts the data store for everyone.
Oi vey.<p>Coming from the good old C I am frankly baffled how some triviality like this one can be wrapped into so many fancy words and a full article. This is like hearing that taking your shoes off when entering home is a good idea. Do you know why? Let's start with an example. Picture this - it's raining outside, water soaks the earth and some of it may get on the soles of your shoes... you get the idea. It's a subject hardly worth a passing mention if any. "Feature toggles". Bah. Makes you wonder what will happen when they discover function pointers or, god forbid, the config files. Now that will likely be worthy of at least a book.
An interesting way to implement feature toggles is with your existing A/B test system. Basically, create an "experiment" for each new feature. Set the initial "treatment" size to something like 10%. Once the feature has been validated in production, set the treatment size to 100%.
A few months ago there was a great blog post by the Instagram team on their particularly advanced flavor of this for their continuous integration. Highly recommend: <a href="https://engineering.instagram.com/posts/496049610561948/flexible-feature-control-at-instagram/" rel="nofollow">https://engineering.instagram.com/posts/496049610561948/flex...</a>
I really like the idea of feature toggles but i'm scared of quickly having a lot of technical debt because of them.<p>I was looking at using something like <a href="https://launchdarkly.com" rel="nofollow">https://launchdarkly.com</a> but the pricing is very expensive even at fairly small scale.
This all thing reminds me why I love so much so called Enterprise Developers and Martin Fowler with Thoughtworks and their articles (no offense, thanks to Martin for the idea of refactoring, but such things are wrong). Seriously, they take simple idea reducible to more general principles which is not a very big deal and start build ad-hoc ideology and terminology around it: Hm-m, some abstraction around feature flags config? I think we should call it "toggle router". Then people start to create frameworks (not libraries) for this and after all technical recruiters will end-up searching for people with particular "toggle router experience".
Feature toggles are useful but should be used with great care, especially in complex codebases. There are challenges to using them. If you aren't careful or don't have very good test coverage you can break unknown sections of code.<p>The other pain is removing them, again if not done carefully or with very good test coverage you can unknowingly break things.
I am pretty disapointed by the limited use cases pictured in the article. I pinged the author without success.<p>Check at bottom of ff4.org page 10 others.<p>E.g : Deliver your product with toggles off on each node of your cluster and when all are ready : toggle on - no more inconsistency during release - no rollback as you simply toggle off if not working.....
There was a nice talk about feature toggles at RubyConf 2015: <a href="https://www.youtube.com/watch?v=rBBLMmr9e-k" rel="nofollow">https://www.youtube.com/watch?v=rBBLMmr9e-k</a>
It's interesting to see this here now, because ~10 hours ago, when it came up in my feedly stream, I tried to submit it and only got the message that it's already submitted. I searched here for it but could not find it, though.