Why would I use this instead of the feature flagging capabilities provided by Azure for example?
Bullet Train: Open-source feature flagging
21–30 of 37 posts
Re: Bullet Train: Open-source feature flagging
#22Why would I use this instead of the feature flagging capabilities provided by Azure for example?
Hi - thanks for the question! I'm one of the founders.
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.
Re: Bullet Train: Open-source feature flagging
#23Earlier quoted context omitted.
Still unclear! "Feature" means a software feature? For example "I've implemented the feature of sorting customer records by date of birth" ? I don't really understand why anyone would need a service to manage software features, so maybe feature means something else.
We have an overview of why you might like to use a feature flagging platform here: https://docs.bullet-train.io/overview Hopefully that helps!
This sounds like it could easily and quickly lead to really poor bug reproducibility, documentation, and discovery especially if the issue is in action-at-a-distance anti-patterns. Am I just being a curmudgeon or is this a reality?
I'll happily accept a "no you're crazy".
Re: Bullet Train: Open-source feature flagging
#24The example showing "high_spenders" and conditions like "money_spent >= 100", feels unsettling, and reeks of user-tracking and discrimination.
Can we please stop these patterns?
Re: Bullet Train: Open-source feature flagging
#25The example showing "high_spenders" and conditions like "money_spent >= 100", feels unsettling, and reeks of user-tracking and discrimination. Can we please stop these patterns?
This seems like a really odd take. Why would any business not want to identify high value customers?
Re: Bullet Train: Open-source feature flagging
#26The example showing "high_spenders" and conditions like "money_spent >= 100", feels unsettling, and reeks of user-tracking and discrimination. Can we please stop these patterns?
This seems like a really odd take. Why would any business not want to identify high value customers?
Ah, but you're looking from the perspective of the business, not the customer.
Re: Bullet Train: Open-source feature flagging
#27Earlier quoted context omitted.
We have an overview of why you might like to use a feature flagging platform here: https://docs.bullet-train.io/overview Hopefully that helps!
This sounds like it could easily and quickly lead to really poor bug reproducibility, documentation, and discovery especially if the issue is in action-at-a-distance anti-patterns. Am I just being a curmudgeon or is this a reality? I'll happily accept a "no you're crazy".
This is used extensively. X customer wants to test y feature, but z customer is the middle of a large test and refuses to see c feature.
Roll out feature to test client, slowly roll out feature to each client.
Something to wrong? It’s incredibly fast to update the flags.
Re: Bullet Train: Open-source feature flagging
#28I wish there were more examples how to use feature flags. How would you test a feature flag e.g. Halloween discount. As this probably involves both front-end and back-end code. The only way I can think off how this can be tested is by making a special new user with this feature flag. But do you now need to test all possible permutations of the flags combinations? If so, how to determine these permutations? Can imagin…
I have an example from a different area. We are developing a batch process that runs multiple stages over multiple hours on a huge cluster producing some kind of numerical results. We also can not deploy to production on a whim, due to regulation. It is impossible to test all developer changes on a full process.
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.
Re: Bullet Train: Open-source feature flagging
#29Earlier quoted context omitted.
We have an overview of why you might like to use a feature flagging platform here: https://docs.bullet-train.io/overview Hopefully that helps!
This sounds like it could easily and quickly lead to really poor bug reproducibility, documentation, and discovery especially if the issue is in action-at-a-distance anti-patterns. Am I just being a curmudgeon or is this a reality? I'll happily accept a "no you're crazy".
For smaller projects and teams, something like feature flagging can probably be avoided unless A/B testing is required.
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.
Re: Bullet Train: Open-source feature flagging
#30If you are interested in this space and don't want to purchase a commercial product, check out Flagr [0] which you can deploy and run yourself. It has clients for Go, Python, Ruby and JavaScript. I have only used the basic flagging, but it also supports A/B testing as well.
No affiliation, just a happy customer.