Bullet Train: Open-source feature flagging
bullet-train.io
bullet-train.io
Almost exact same domain name even. Yikes.
Hopefully that helps!
I'll happily accept a "no you're crazy".
Roll out feature to test client, slowly roll out feature to each client.
Something to wrong? It’s incredibly fast to update the flags.
For a company that has hundreds of engineers, with daily continuous deployment, it helps to have certain in-development features gated behind flags. When it comes time to deploy these new features, they can gradually be rolled out to users. If the feature starts triggering exceptions, it's very easy to scale back.
Once the beta feature becomes stable, often the feature is removed (along with all logic in the source code guarding this feature).
Similarly, for A/B testing, the feature flagging and logic is removed once a test is deemed to have either passed or failed the A/B experiment.
Like anything else in software, feature flagging can incur technical debt if not properly maintained.
For example, you're developing a new version of the checkout page for your company from scratch (it can be a store selling physical goods, or a subscription service, or anything that requires payment). It means that for a while it will not have feature parity with your existing checkout page.
So first you implement feature parity with, say, German payment options (credit cards and Sofort). Then you set up a feature flag saying "for 5% of German customers display the new checkout", and monitor it. Then you bump it up to 10%, then to 50%.
Meanwhile you're working on accepting payments via Swish in the new checkout in Sweden. Once it's ready, you add a feature flag saying "for 5% Swedish customers display the new checkout" (and in parallel, you're probably already displaying the new checkout to 50% German customers).
And so on.
In their core feature flags are not really more than a glorified if statement, but:
- you want to view them, and handle them in a single place so that you can adjust the various parameters or quickly shut down a feature if it misbehaves
- this single place has to be scalable enough that it survives an influx of customers potentially triggering dozens of feature flags across your software
In a nutshell, it allows developers to deploy new features but hide them based on a flag. Once it is ready to be released (example: product gave an ok, big announcement happened etc), then this feature just needs to be enabled through this flag. Now, this flag can be an environment variable, but for apps you will probably need a service, which the app always fetch the latest feature configs.
We use it here (although using Flaggio https://github.com/victorkt/flaggio) and it is super useful for continuous delivery. And you can as well control features based on groups (example: show just for beta users) or hide features if some bug was discovered.
But they only seem to work if the interface doesn't change. From the example you gave:
function reticulateSplines(){
if( featureIsEnabled("use-new-SR-algorithm") ){
return enhancedSplineReticulation();
}else{
return oldFashionedSplineReticulation();
}
}
How do you use feature flags when the features aren't just trivial changes to methodology, but affect multiple parts of the system?
But how do you deal with multiple feature flags implemented on the same piece of the system?
How do you create discrete components when you have three or more features intersecting on that component?
And presumably there's a proliferation of test cases, too (because you'd need to test that everything works with all combinations of features A,B,C,D implemented)?
How much of this gets cleaned up afterwards? When the feature is fully rolled out, how do you resist the pressure to move on to another feature and leave the flags implemented rather than clean it all up and remove the old code?
a good feature flag service should also allow you to do % rollout to try to de-risk the release of a new feature, some times even auto-closing the feature if some specific metric passes a certain threshold (e.g. dau dropped 10%, number of errors increased x%, etc)
No affiliation, just a happy customer.
[0] - https://github.com/checkr/flagr/issues/139#issuecomment-4028...
But do you now need to test all possible permutations of the flags combinations? If so, how to determine these permutations? Can imagine you test all possibilities every time??
So we put highest risk changes under feature flags/configuration values. If certain things do not work as expected in testing - we disable them with configuration without creating a new build artifact. It is also a common occurrence that another team has to validate numerical results Coming from a certain feature for a while before it is enabled in production.
There are a few options for people when it comes to feature flags. Some options, like Azure, are features of larger platforms, others come at feature flagging from more of an A/B testing angle.
In terms of Bullet Train:
- We focus on feature flags. We're not going to build out features that are not core to that offering. We're not going to build an analytics platform for running AB tests as we think using a dedicated analytics solution makes a lot more sense. - Our flags can be booleans, strings, ints or floats and can be overridden on a per environment basis. - We offer flags based on dynamic user segments, percentage splits/rollouts and are about to release multivariate flags with ABN testing capability. - We have lightweight, low dependency SDKs for the majority of languages and frameworks that don't get in your way. - You can run our platform yourself, with us, or we can help you run it on-premise. Our architecture is straightforward and can be up and running in a couple of minutes via docker-compose. - All our dashboard and API code, as well as our SDKs, is open source and BSD-3 licensed.
At the end of the day it depends on what you are looking for, and what tooling you are currently using.
from my perspective the most important thing would be privacy and ideally no sdk, but I acknowledge that I might be bias...
Can we please stop these patterns?