I‘m in the process of setting up feature flags and curious of existing experiences.
Which systems worked, which didn’t, and how would you set one up if you were to do so today? Any software you can recommend?
Ask HN: Do you use a feature flag system? What does it look like?
1–10 of 12 posts
Re: Ask HN: Do you use a feature flag system? What does it look like?
#2Tried feature flags, but it ended up being a mess. Went back to dev/master branches with automated tests between them using standard GitHub workflows.
Re: Ask HN: Do you use a feature flag system? What does it look like?
#3If you’re interested in a good flag system that’s not LaunchDarkly or Split (which have gotten really expensive) Statsig has a really good offering. Their original thing was analytical feature flags for testing the impact of rollouts, but they basically offer the full suite that the others do.
Re: Ask HN: Do you use a feature flag system? What does it look like?
#4If you’re interested in a good flag system that’s not LaunchDarkly or Split (which have gotten really expensive) Statsig has a really good offering. Their original thing was analytical feature flags for testing the impact of rollouts, but they basically offer the full suite that the others do.
Thanks!
Re: Ask HN: Do you use a feature flag system? What does it look like?
#5Tried feature flags, but it ended up being a mess. Went back to dev/master branches with automated tests between them using standard GitHub workflows.
The mess is what I‘m concerned about—I don’t want to introduce new complexity if I can avoid it.
Re: Ask HN: Do you use a feature flag system? What does it look like?
#6Tried feature flags, but it ended up being a mess. Went back to dev/master branches with automated tests between them using standard GitHub workflows.
The mess is what I‘m concerned about—I don’t want to introduce new complexity if I can avoid it.
idk, feature flags for the entire application seem ok to me.
The issue is when we want to add feature flags for part of the users, or only on a part of the application flow. Then it will become a mess.
Where I work, those feature flags are used to deploy a feature for a single application "run time", i.e. a country, which has its own cloud and everything.
BTW have you read the article on feature flags on Fowler's website? Could help you form some opinions https://martinfowler.com/articles/feature-toggles.html
Re: Ask HN: Do you use a feature flag system? What does it look like?
#7If you are at an engineer-driven company a couple of utility functions "if ff_isset(ff_name)" one for backend and one for frontend might be all you need. You select the FF by setting a cookie. You can have a simple dashboard to set them and show the data.
Most companies seem to prefer launchdarkly or similar, but I have seen this setup work great at big international websites with loads of traffic.
Re: Ask HN: Do you use a feature flag system? What does it look like?
#8We just integrated launchdarkly recently and I like it, they provide multiple flag types that I haven't seen on other services, the main one being migration flags (can be either 2, 4, or 6 step migrations) that allow you to control the migration from one system to the other.
It's been pretty helpful for us moving our analytics queries from mongoDB to clickhouse.
Re: Ask HN: Do you use a feature flag system? What does it look like?
#9I’ve used launch darkly and I think it works fine. Pretty good for larger companies imo.
For my smaller projects I’ve used simple kv stores and user id lookups to handle it. Works fine.
Depends how advanced you want to go honestly. If you want to go bonkers use LD. If you want something simple like literally serve X user Y content you could set something up yourself in 30 minutes.
Re: Ask HN: Do you use a feature flag system? What does it look like?
#10Feature bits in shared memory and if accessed less frequently in redis is a staple solution. The system I used was managed by an internal group had a solid api, life cycle management, plus propagation of flags wuth defaults. It worked at serious scale. New code could be enabled and disabled independent of code. Removal of code and deletion of old code paths lagged by devs, but on the whole it served custs well.