Ask HN: Do you commit feature flags to Git? If you do: - What feature flag tool do you use? - Do you like the experience? (Could the experience be better? How?) If you don’t: - Do you want to? (What’s stopping you?) - or do you not want to? (What puts you off?) |
$ cat default/setting/html/avatar_link_to_person_when_approved
0
$ cat config/setting/html/avatar_link_to_person_when_approved
1
if (GetConfig('setting/html/avatar_link_to_person_when_approved')) {
# do some stuff
}
The "feature flag tool" I use is a procedure called GetConfig() which is ~250 lines of code with comments and logic for overlays.
Please let me know if you have any questions about this method.
Blocks of code around the intended feature flag find the feature flag boolean and do whatever they are supposed to do. If a feature flag is not found it defaults to false/off. Later on after features are rolled out and have become the default, an engineer removes the FF code, related tests, and DB row.
I don't see how a tool/SaaS could be any better for this scenario. There is a DB dependency but honestly if the DB isn't available then shit is on fire in a very bad way and I don't care about feature flags in that moment.
Other options could be ENV variables loaded at app startup, this can get unwieldly though if you have a lot of them and requires an engineer to be involved. Putting feature flags in an external system seems like purposely introducing more failure modes to your app.
Just wondering what is your process in an incident when you want to know what changed in the system? e.g. so you can correlate observed error rate changes with a the enabling or disabling of a flag.
It doesn’t really matter how you manage changes to feature flags, but using version control gives you a couple of nice benefits:
* gives developers the opportunity to describe their change
* let’s you roll back a problematic patch
* blame and bisect problematic patches
Ideally, you should also be able to see your feature flag changes in prod much faster than it takes to cut a release. You need this in order to be able to quickly roll back bad features.
> What feature flag tool do you use?
See https://engineering.fb.com/2017/08/31/web/rapid-release-at-m...
We used a simple approach without any extra tools: the feature flags were constants that controlled whether certain code blocks were active in dev, test, or prod environments.
This enabled us to merge and test work in progress branches regularly before they shipped in the production app. It also made code reviews more frequent and easier.
Eventually once something is fully rolled out we might go back and change the default state but since Salt is always going to manage most of that it’s not a high priority.