alt Hacker NewsTo me there two type of feature flag. For tech and not for tech.
If you have good CI/CD practices, an ENV for the environment has what feature is simplest. No new dependencies, change code commit deploy.
Non-tech folks need something else that allows them to switch it on and then off. For a variety of reasons.
Replies
We had a weird constellation of these things at a previous job of mine. In addition to our env variables, we had a config table for more business-side stuff (ie percent of margin to include in bids and quotes for work on the platform) that our business team would upload new values to on our admin GUI with a CSV file, and eventually we jammed into that same table a config check that would enable features just for certain users by email. I was very happy when we eventually moved to Launchdarkly and tossed out the hacky stuff.
This seems a bit reductive. What if you want to do a progressive rollout of the feature? What if it has a problem, and you want to disable it without needing to redeploy across multiple regions? What if you want to A/B test it?
Ex-LaunchDarkly engineer here.
Feature management goes well beyond an env var. Sure an env var change is fine on it's own, but a change of the feature flag (essentially a release) requires a deployment.
Feature management separates these two. You can deploy without releasing. Because the code is there, but dormant behind an if that can change at runtime, you can actually target users, segments, or even do progressive rollout, and so much more. What this also means is you can test your changes in production without causing prod to go down. Best of all, a release doesn't mean a bad deployment.
It's not just about non-tech folks. It separates deploy and release in the SDLC, and that opens up a whole new world.