11–20 of 143 posts
The team uses them. Outside of looking for bugs I still have not been convinced that it is useful to check if blue versus green button has useful conversion rates.
That's A/B testing, not feature flags. Check https://news.ycombinator.com/item?id=30115276 for a description of how feature flags are used.
I know you said frontend, but we use them for both FE and BE. They work fine, but our problem comes with DB migrations. We just haven't found a good way to deal with DB changes and flags.
Never modify a column Never drop a column or table
Our feature flags are nice to work with in that you can just add them in code. If the flag doesn't exist in the DB, it is created with a default value. This makes them pretty painless to work with for us.
You can activate feature flags one server at a time as well to roll things out gradually if you want.
We have a simple web ui in our admin site where you can see them, what they are set to, when last updated etc. A good idea which we haven't done yet, is to log who changed it each time, and why as well.
Being able to find flags that haven't changed in a long time is useful to identify ones you can clean up.
Yep. Some features are complex and cannot be completed in one sprint. On the other hand, we have constantly changing front-end code and leaving code in a branch too long might make it drift and might get broken in a lower-layer change because constantly syncing gets annoying. The other case is when the front-end is ready but the back-end is not or there is a public announcement that is scheduled for a later date.
This let us slowly roll out new features to a subset of users in case there are any issues.
Using feature flags also requires testing the default (not enabled state), ensuring you have a robust realtime configuration manager to control the knobs, and metrics for everything - not just how many requests/customers are opted-in, but also the progress & state of the configuration change.
It does no good to first enable a feature at 1% if only 1% of your servers have received the updated configuration - that's only .01% impact. It also tells you when your rollback is complete - you want to be sure when you disable something that there's not some stuck server with the feature still enabled...
We mostly use frontend feature flags for this, so we'd only show the link in the menu or the specific component if the feature flag is turned on.