Feature Toggles
martinfowler.com
Feature Toggles
1–10 of 50 posts
Re: Feature Toggles
#2Overall 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.
However, this part seems strange to me:
> The team particularly appreciate that this will allow them to test their new algorithm without needing a separate testing environment.
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.
Re: Feature Toggles
#3At IMVU we had feature toggles rolled into the A/B Experiment system. It proved to be a vital part of Continuous Deployment.
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...
...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.
Re: Feature Toggles
#4I really like the idea of feature toggles but i'm scared of quickly having a lot of technical debt because of them.
I was looking at using something like https://launchdarkly.com but the pricing is very expensive even at fairly small scale.
Re: Feature Toggles
#5An 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%.
Re: Feature Toggles
#6It'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.
Re: Feature Toggles
#7I really like the idea of feature toggles but i'm scared of quickly having a lot of technical debt because of them. I was looking at using something like https://launchdarkly.com but the pricing is very expensive even at fairly small scale.
Co-founder of LaunchDarkly here-- we're dropping our startup package to $9 / month in the next week. Come check us out.
Re: Feature Toggles
#8Overall 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. However, this part seems strange to me: > The team particularly appreciate that this will allow them to test their new algorithm without needing a separate tes…
I find it amusing when CI tooling is used like this, to allow people to keep changes isolated in separate branches with less pain from delaying the integration.
It's more Continuous Isolation than Continuous Integration.
There are ways to test features for performance/accuracy in the production environment with reduced risk. One approach I've used successfully is branch by abstraction with verification.
http://www.alwaysagileconsulting.com/articles/application-pa...
Essentially you first extract a common interface for the component you are replacing. Then you release both versions and send (all or a percentage of) input events to both the old and the new implementation. You discard the response from the new implementation and continue using the old codepath for responding to users / performing calculations, but importantly - you compare the old and new results and alert/log if they differ.
This allows you to gain confidence in a new implementation's behaviour in the production environment and integrate your code with the rest of the system with significantly reduced risk. When you're happy you can flip over to the new implementation and delete the old.
There are also various other techniques for reducing the risk of datastore corruption that you mention. I've written about some of them here http://benjiweber.co.uk/blog/2015/03/21/minimising-the-risk-...
Most of these risks are actually smaller with more frequent and smaller releases of functionality into production. Releasing more regularly also encourages you to think about how to properly mitigate these risks.
Re: Feature Toggles
#9Overall 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. However, this part seems strange to me: > The team particularly appreciate that this will allow them to test their new algorithm without needing a separate tes…
There is a substantial section of the article about modifying their high level tests to test both branches and keeping the toggle off in production whilst turning it on for some exploratory testing.
Re: Feature Toggles
#10A 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: https://engineering.instagram.com/posts/496049610561948/flex...