I worked at the biggest retailer in the world and we used them a ton. They got even more useful once we built the concept of a versioned flag that would allow us to be true or false, depending on the app version we were on. That kind of flexibility is a must.
Ask HN: Does your team use feature flags?
41–50 of 143 posts
Re: Ask HN: Does your team use feature flags?
#42I used them in multiple projects and i'm constantly discussing the benefits with other teams.
Implemented correctly (don't forget to remove them!), they are awesome.
Re: Ask HN: Does your team use feature flags?
#43Yes. I've worked at a few places that have used them similarly. Some do call them "feature flags", others call them "permissions". As others are noting in the comments here, they are great to perform partial rollouts of new features, or to selectively grant users (both for a client or just for our own in house purposes) the ability to see how a feature will run in a real world scenario.
One company created a category of feature flags that they give customers the ability to opt into themselves from their settings page if they want. This lets users selectively try out new features if they want. It's helpful to gauge interest and to get feedback before rolling out to everyone too. Though, that's a relatively small portion of the flags that are generally created
One problem that is typically encountered is setting up and executing a plan to remove the feature flags when they're no longer needed. Once you roll a new feature out to everyone (assuming there isn't someone who doesn't want the change), you should remove the flag and any code that's checking for it to keep things clean.
Re: Ask HN: Does your team use feature flags?
#44Earlier quoted context omitted.
It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.
For iOS maybe, but for websites couldn’t you just revert the commit?
For websites, the value is that feature flags should be much faster than the revert/deploy cycle.
At $PRIOR_JOB, a revert/deploy or rollback takes tens of minutes of the main application.
Re: Ask HN: Does your team use feature flags?
#45Not anymore. We do still have the ability. Some teams have found that it introduced an overhead (moving part, point of failure) and long lived staleness into certain parts of the codebase, which is actually reflective of our teams' priorities. Feature flags bring an overhead that teams should be aware of an acknowledge the management required, before introducing it into a tech stack.
Yes, they increase fragmentation.
They have their place, but they certainly have a cost as well.
Re: Ask HN: Does your team use feature flags?
#46Earlier quoted context omitted.
It's risk mitigation. Feature flagging everything is a pointless waste of time until suddenly you have to roll something back in production and it's not feature flagged. The value of feature flags increases with the greater the cost of a mistake making it to production. For iOS builds particularly, that might have a 1-2 day review delay before you can get a new build approved, they're invaluable.
For iOS maybe, but for websites couldn’t you just revert the commit?
Depends on how long the time is between commit and live-in-production, and on how severe the impact is. And also on the number of developers committing changes to the same codebase/app.
If it takes you >20 minutes from when you commit to when it's live in production, and an incident arises due to the change where data loss/corruption increases in "blast radius" more by having the breakage in production longer, then a feature flag might be a great way to give you an immediate "kill it" switch.
One possible alternative that could give an immediate "kill it" switch is to deploy the last-known-good build, but that only works IF other non-revertable changes haven't shipped since your change (like non-reversible schema migrations), and also IF your time-to-deploy-existing-build is sufficiently fast (it's pretty rare that you actually have instant deploys in live production apps).
If you're in the situation where you have multiple developers committing unrelated changes to the same codebase, and non-reversible changes are a possibility, and your CI/deployment time is sufficiently-long (>5minutes, maybe?), then yeah, feature flags are probably a better fit than "just revert the commit".
For one-man projects with a slow rate of change and a fast CI/CD pipeline, sure, feature flags are overkill.
Re: Ask HN: Does your team use feature flags?
#47Yes. The ability to turn features on and off, especially on demand is an important part of the applications and services my team is responsible for. We have a few different levels where features can be enabled or disabled ranging from configuration injected into applications, configuration stores to lookup settings giving us the ability to expose/hide features.
To support per user or group settings we have a `canary` role that can be set to allow access to new features that have been integrated but not available to the general users. The nice thing about having something tied to roles is that the changes can take effect immediately without the need for redeploying, or reinitializing applications in our footprint. Also, the role based model can be made as fine or coarse grained suited to the app's and user's being served.
We tend to avoid encoding feature flags into URLs because users can bookmark them, revisit via history or navigate from old emails, messages, etc. and we'd rather not expose these flags or have them memorialized anywhere.
Re: Ask HN: Does your team use feature flags?
#48yes. Critical for rolling out features by country or region. Some teams even use them for i18n translations.
Re: Ask HN: Does your team use feature flags?
#49I 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.
[deleted]
Re: Ask HN: Does your team use feature flags?
#50I 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.
This isn't a perfect solution but we "solved" this by allowing services to know if migrations have been run. We store the migration data in a shared database and every service that depends on a specific migration, directly or indirectly, is configured to verify that migration has been run before health checks will pass. The system is designed to support automatic migrations and deployments, but I don't trust it enoug…
How do you sync the state of production feature flag toggles, and FF config for developer environment or for standing up a new developer environment?
For example, a new full-stack SWE is onboarding and has an env representing production, populated with test data.
That engineer wants to run the product as it currently exists on production including the state of feature flags.
How does this developer update this state, or remain notified if a FF state changes that affects something they are working on?