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

61–70 of 143 posts

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

#61

Post by swah »

I have been doing something similar in my React Native apps - major features are enabled in a env.js variable:

    {
       EnableBackgroundSync: true,
       EnableDebugLog: false,
       ...
     }
This also ends up helping find different parts of code that are related in live in multiple modules (eww, I know)...

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

#62

Post by malthauser »

Haha. Yes!

I've now worked at 3 different companies that built feature flags both internally and as a core part of their external product offering. I'm currently at Flagsmith (open source too).

Here are some of the more popular front-end feature flag use cases:

1. Gradual Roll Out: Build a feature and release it to 5% of your users, then increase as you see that it isn't "breaking anything". You might even do this AFTER a successful A/B Test concludes. 2. Test in Production: Build a feature and release it to only your internal team (or QA Team) to see how it works in a real production setting. 3. Feature Gating: Managing access to specific features based on a targeting condition. I've seen people do this for BETA features with key customers pretty often.

Most common reason people don't use them: 1. They are concerned about feature flag creep. Managing them if they aren't deprecated can be a problem worth thinking through ahead of time. 2. They worry about giving access to important parts of their product in production. Thinking about your environment set-up and access control is smart.

Hope this helps!

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

#63

Post by yojo »

bschne wrote: post #40
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…

> A downside is that although normally you'd want to remove old feature flags that become obsolete, this hasn't been done very often. I figure this should be somewhat automatable since the relevant bits of code have references to the exact flag's identifier. Was it not done b/c nobody was incentivized in any way to spend any kind of time on cleanup? edit: OK that might be a bit naive on the organizational side. Force…

A typical pattern I saw was a team adds a new flag, then gradually rolls it out. Once done the removal is added to the backlog. “High priority” bug fixes and feature work gradually moves the ticket down in the system. Two months later a reorg happens, the team no longer exists, and the work is lost.

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

#64

Post by hosh »

bschne wrote: post #40
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…

> A downside is that although normally you'd want to remove old feature flags that become obsolete, this hasn't been done very often. I figure this should be somewhat automatable since the relevant bits of code have references to the exact flag's identifier. Was it not done b/c nobody was incentivized in any way to spend any kind of time on cleanup? edit: OK that might be a bit naive on the organizational side. Force…

In the case of my team, although we recognize we should clean it up, we’re usually prioritizing pushing out more features. That tendency leads to a lot of old feature flags.

In a startup, being able to get features out is more important than cleaning up old flags. If we don’t achieve product fit before we run out of runway, then the whole thing can get shut down. If we don’t achieve customer validation, same thing.

Usually, at some point, someone will suggest a rewrite. That pretty much never goes well.

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

#65

Post by notreallyserio »

bredren wrote: post #50
notreallyserio wrote: post #21

Earlier quoted context omitted.

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,…

We don't really use feature flags, this migration code is just our way to get closer. But it would be possible to write a migration that handles the feature flag swaps, assuming it's a value in a database or something that works somewhat like a database (redis, storage bucket, k8s configmap, etc.) That's how I would do it anyway.

The migration content is all committed to a central repository (we're using a monorepo) and they can basically run "migrate all" to get them. There's also a script that creates a basic environment from scratch, but it comes with only minimal test data, and not nearly enough for load testing.

The dev would need to watch for updates to the main branch to know if something there requires their attention, which may not be totally scalable. We're miniscule and pre-launch so it's not a big deal for us yet.

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

#66

Post by dpark »

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.

> our problem comes with DB migrations

What kind of problems do you run into? And how is your DB deployed/updated/migrated/whatever?

I’ve found it necessary to either always update the DB before the code/binaries or to expose DB version to the code so that it can automatically turn off features if the DB schema isn’t updated yet. Which of these options makes sense depends on how you deploy. If you can rigidly enforce that the DB always updates before binaries, that’s a simpler model (but your DB queries need to be backwards/forwards compatible, depending on whether they are in code or in stored procedures).

The other thing that’s been hugely successful is to have a comprehensive test suite that can be exercised in intermediate states. e.g. New DB with old binaries. Absent a strong test suite, it’s always human judgement when it’s safe to roll out.

I’ve also found success with taking certain actions out of the deployment entirely. e.g. Adding indexes to large tables gets done independent of deployments, because if things go south we don’t want to be trying to resolve the indexing issue in the middle of a deployment. It’s easier to do this in isolation from other changes.

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

#67

Post by dpark »

bredren wrote: post #50
notreallyserio wrote: post #21

Earlier quoted context omitted.

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,…

Build a service/loop/CI/cron job/whatever to pull feature flag state from prod and check into your relevant branch(es). Make the dev deployment apply this state by default.

You’ll get a lot of extra value out of this if you have an automated test pass that exercises the bulk of the product. You get bonus points if you can integrate individual feature flags back to your branch(es) independently, because it will let you easily identify which flag has broken automation.

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

#68

Post by zbuf »

Yes, it mostly decouples "launch" of a feature from accidental side effects of it.

I find that reduces the peak/emergency workload; important for small numbers of developers.

Also aids in developing the whole codebase cohesively -- instead of "don't touch the core to add the new feature". Or trying to wrangle separate branches that have a dependency.

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

#70

Post by jpthurman »

Feature flags became essential when we began to open our offering as various configurations with varying features that align with business packaging. We use them as an easy way to toggle features per environment and end-user-configuration. Certain features are turned on/off for our Cloud version vs. OSS vs. Self-host. It's conceptually easy to understand across the team and easy to control.
Post reply on HN