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

71–80 of 143 posts

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

#71

Post by nicoburns »

yojo wrote: post #53
Minor49er wrote: post #43

Yes. 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…

This exactly. Feature flags are necessary for rollouts, but they also quickly become technical debt. Multiple outages happened at my last company when the feature flag service went down and old flags defaulted to “off”. It got to the point that the supporting team restricted flag-based rollouts to 95%. If you wanted it on for everyone, you had to remove the flag. Not sure if I fully agree with that design, but as an…

Sounds like you have too many services if you have one just for feature flags! At my company we bundle feature flagging into the main auth service, if you can login then you can access your feature flags.

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

#72

Post by karmakaze »

My recent experience working with feature flags:

- enable percentage rollout only after validating for specific test accounts/ids

- when using percentage rollout, also have a 'killswitch' flag that can negate belonging to the enabled group

- if you don't need to test specific accounts/ids first, you can use only a 'killswitch' rollout flag starting at 100% and decreasing. enabling still possible to remove particular id's from feature enabled group

- best experience was making a helper that everything goes through rather than query feature flag name directly. This lets you test things like what happens in CI/CD if I hard-code that return value to fully enabled. This gives you test coverage using the flag for all the tests that don't mention it at all. The helper can also do any combination of required flags/killswitches for something to be meaningfully active.

- and for expired flags, have a recurring nag mechanism, e.g. Slack post by team/channel owner

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

#75

Post by jdavis703 »

ford wrote: post #58

A different question - how do teams that don't use feature flags accomplish the things feature flags enable? Namely: 1) Validating you can handle production-scale 2) Ensuring integrations/environment-related issues don't happen when you deploy 3) Alpha/Beta groups of users 4) Quick reversions when something does not work as expected Similar to other commenters I can't imagine not using feature flags. Some of these mi…

It’s managed through Git workflow. At one place we had three branches: master, alpha and release.

Master was in-progress features. By the time alpha was cut you were expected to be code complete because that was also the end of the sprint.

Alpha then went to staging servers. Bug fixes would land in master and be cherry-picked in to alpha. Eventually alpha gets promoted to release.

Emergency fixes are cherry picked directly to release.

It’s clunky and stressful, but that’s we did it at one startup I worked about 10 years ago. Everywhere uses flags.

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

#76

Post by dhagz »

Yeah, my team doesn't do anything terribly complex with them, but when I'm developing services I always throw in a command-line flag to toggle debug mode - ups the log level and serves pprof data using Go's net/http/pprof module. So it's not a user-facing feature, but we haven't run into that need yet.

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

#77

Post by didip »

Feature flag is inevitable for all large software projects.

1. To hide not-yet-ready features that have production dependencies.

2. To route special users to a different code path.

3. To test new ML code on a fraction of users.

4. After a refactor to a different language or a micro service, you may need feature flag to route requests.

I could go on and on, it's simply mandatory.

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

#79

Post by alexfromapex »

Yes, the main problem I have with actual "feature" flags is they increase complexity because you have to test multiple variants of features together with integration and unit tests. I like the idea of wrapping a whole release in a release flag instead because you have a set of released features that should all work together.

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

#80

Post by obstacle1 »

spookthesunset wrote: post #39
drclau wrote: post #32

Worked for a bigtech well known name, large and extremely important project, literally the core of a service serving an enormous number of users, and feature flags were mandatory, no exceptions. I can't imagine working without feature flags. Being able to enable new features in particular deployment rings (canary, dogfood, various production rings or regions), or per users / user groups, enabling gradually (percentag…

That is the one problem we’ve found with feature flags. It’s very easy to forget to gut the “old” parts when they are turned off. In many cases I’ve seen two or three year-old feature flags whose stale end still remains because the developer and / or team that did the branch never cleaned up. It isn’t usually malicious or lazy… it’s just how things would pan out. Then we’d be nervous removing the old stuff cause who…

That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags. Flags should be associated with an expiry date, and company comms tooling should be consistently yelling in some public channel when expired flags still exist in the codebase.
Post reply on HN