61–70 of 111 posts
Depending on your infra, that can already make them toggleable without a redeployment: a restart of the apps/containers on the new envvars is enough.
Having them in a separate file would be useful if you need to be able to reload the flags upon receiving SIGUSR1 or something.
The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…
Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.
The combination of these two has been all we've ever needed. User segmentation, A/B testing, pilot soft launch etc are all easy.
Earlier quoted context omitted.
How do you push the files to all of your containers? I’ve done this in the past with app specific endpoints but never found a solution I liked with containers.
We keep a JSON blob in Google Secret Manager for our flags. The service running in the container will reload the secret anytime it changes
The single biggest value add of feature flags is that they de-risk deployment. They make it less frightening and difficult to turn features on and off, which means you'll do it more often. This means you can build more confidently and learn faster from what you build. That's worth a lot . I think there's a reasonable middle ground-point between having feature flags in a JSON file that you have to redeploy to change a…
Why aren't you just using environment variables for feature flags? Have people still not bought into the whole 12 factor config things?
There also seems to be feature flags in the sense of toggling on and off features. Then hard-coding makes less sense.
>Hardoced feature flags
Think the author obviously meant "hardcoded" here.
Anyways, recently, this has been really hard to sell teams on in my experience. At some point "feature flag" became equivalent to having an entire SaaS platform involved (even for systems where interacting with another SaaS platform makes little sense). I can't help but wonder if this problem is "caused" by the up-coming generation of developers' lived experience with everything always being "online" or having an external service for everything.
In my opinion, your feature flag "system" (at least in aggregate) needs to be layered. Almost to act as "release valves."
Some rules or practices I do:
* Environment variables (however you want to define or source them) can and should act as feature flags.
* Feature flag your feature flag systems. Use an environment variable (or other sourced metadata, even an HTTP header) to control where your program is reading from.
* The environment variables should take both take priority if they're defined AND act as a fallback in case of detected or known service disruption with more configurable feature flag systems (such as an internal DB or another SaaS platform).
* Log the hell out of feature flags, telemetry will keep things clean (how often flags are read, and how often they're changed).
* Categorize your feature flags. Is this a "behavioral" feature flag or functional (i.e., to help keep the system stable). Use whatever qualifiers make sense for your team and system.
* Remove "safety" flags for new features/releases after you have enough data to prove the release is stable.
* Remove unused "behavior" flags once a year.
My $0.02
Earlier quoted context omitted.
> using an (often expensive) feature flags as a service platform I have no idea why anyone would actually do that in real life. Feature flags are something so trivial that you can implement them from scratch in a few hours, tops — and that includes some management UI.
Add to that ideally feature flags should be removed after feature is released. Ideally also you shouldn’t have more than handful of feature flags. Permanent per customer configuration is not a feature flag. Also best would be not to have too many per customer configurations.
The primary purpose of feature flags is to provide a way to change system behavior dynamically, without needing a deploy.
Earlier quoted context omitted.
Seriously. This is one of those cases where rolling your own really does make sense. Flags in a DB table, flags in a json file, all super simple to build and maintain, and 100x faster and more reliable than making the critical paths of your application's request cycle depend on an external provider.
You know what I would find worse than telling my customers that they can't access the application they paid for and works because I farmed my auth out to a 3rd party that is having an outage? Telling them that my auth provider isn't out, but the thing I use to show them a blue button vs a red button is. Oof.