|
|
|
|
|
|
by mattmanser
2120 days ago
|
|
|
If you mean global feature flags, use the config file built into virtually every single webframework and and an if statement. It's really not complicated. Some webframeworks require an app restart for config file changes to be detected, or restart the app automatically when it detects changes to the file, so I've seen people use databases. But it tends to be an overcomplication and it's usually turned out to be a bit of a pita. It's only worth it if you're regulalrly turning the feature on and off. Many languages also support build flags, which strips the extra code out completely, but it's an obscure feature, unless you write libraries, that can confuse other programmers. |
|
|
There's a huge amount of value in being able to flip a flag value and have the app react without a restart. The most basic scenario: being able to separate deploy from release. Deploy code with each major code change turned off; ensure the deploy's gone well, then turn the changes on one at a time (or whenever the feature is meant to go live). Not only does it make problem diagnosis much easier, but it means you don't need to rollback if one of them is buggy - just turn it off again.
But these are only feature flags in the simplest sense. Modern feature flag systems also allow targeting rules, which allow the flag to evaluate differently based on contextual attributes (e.g. something about the user). They also stream these rules to a simple local rule engine within the code so that evaluation isn't blocked on I/O. Then there's access control, experiments, multivariate flags...