Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Does your team use feature flags?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 143 posts

Re: Ask HN: Does your team use feature flags?

#21

Post by notreallyserio »

quaffapint wrote: post #12

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.

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 enough yet. (It's easy to write a migration that works on a local database but consumes too many resources in production, so it's just a matter of having a proper preprod, that I haven't created yet.)

Re: Ask HN: Does your team use feature flags?

#22

Post by gostsamo »

tlongo wrote: post #16
gostsamo wrote: post #2

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.

Drifting branches seems to be the main argument pro feature flags. I wonder how teams avoid breaking parts sleeping behind feature flags, by the ongoing development of its surroundings.

If the flag is obtained from a configuration file, you have a testing configuration where the flag is toggled and you run the tests in your CI/CD pipeline. E.g. we have a development plan where everything is enabled and tested.

Re: Ask HN: Does your team use feature flags?

#23

Post by dogleash »

tlongo wrote: post #16
gostsamo wrote: post #2

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.

Drifting branches seems to be the main argument pro feature flags. I wonder how teams avoid breaking parts sleeping behind feature flags, by the ongoing development of its surroundings.

>I wonder how teams avoid breaking parts sleeping behind feature flags, by the ongoing development of its surroundings.

Just duplicate the testing jobs with the feature flag flipped. Configure new job to turn expected-failure test cases into expected-pass (or whatever analogous way you keep track of it).

Re: Ask HN: Does your team use feature flags?

#25

Post by candiddevmike »

No, we do monthly releases instead and make sure they're stable or fix them with a follow up bug fix if they're not. If a feature isn't ready yet, it doesn't get into the release (or develop branch).

I personally think feature flags are useful if you're deploying very frequently, but they just add confusion to software that's meant to be released/stable, especially for those developing it (what's with all the half done code and TODOs everywhere?)

Re: Ask HN: Does your team use feature flags?

#26

Post by iliaznk »

We do. We have one React app running on multiple instances that service different customers and not all customers need the same set of features. Some of features are only supposed to work on our staging instance until they're ready for production.

Re: Ask HN: Does your team use feature flags?

#28

Post by dabeeeenster »

Also biased! [0], we use them a lot, mainly on the front end. Most of the new features we are working on are gate-able via front end UI elements, and so we push out pretty much all our new features using our own platform.

We are also doing interesting stuff like controlling what features are in our Open Source Docker container via flags in the platform that are baked into our Docker images when they are built.

Once you start using and relying on flags, it's hard to go back, and helps with a bunch of 'good' engineering processes and patterns.

Another interesting aspect is that once you have gated a feature based on a flag, you can then AB test that feature, almost for free, as you have a way of bucketing users and showing or hiding the feature using most feature flag platforms.

[0] https://flagsmith.com/ & https://github.com/Flagsmith/flagsmith

Re: Ask HN: Does your team use feature flags?

#29

Post by eranation »

We do, not sure if we do it "right", but we do have flags (both in the backend and frontend) to enable features only on "dev" while they are being worked-in-progress, this allows us to not delay pushing to prod. We also have feature flags in our infrastructure-as-code actually (we use CDK, a typescript based infra-as-code framework)

Re: Ask HN: Does your team use feature flags?

#30

Post by deminature »

aerovistae wrote: post #24

Extensively. Nearly every single change to the codebase is flagged. Even switching copy is behind a flag sometimes if the copy is across multiple places. I find it excessive and irritating; it feels like cargo cult programming to me.

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.

Post reply on HN