Ask HN: Feature Flags?

https://news.ycombinator.com/item?id=3028814

by smcguinness • 15 years ago

7 3 15 years ago

news.ycombinator.com

Our product is growing in features faster and faster, especially now that we have a larger team. We'd like to do incremental releases and after seeing the FB talk on feature flags we are intrigued by the potential.

Do you use them and recommend their use? If so how do you implement them? When do you determine when to remove the code handling the feature flag? Do you do server side and front-end?

darkxanthos• 15 years ago

I work for Cheezburger Network. We use them a lot via lots of if(FeatureFlag.IsEnabled("foo")){ /* Show the feature! */ }. They're easy to see if you can remove the conditional. You just check if the feature is enabled in production and if it is and it's been there awhile delete the flag. And yes we do feature flags in both Javascript and C# side.

plasma• 15 years ago

At work we use to use feature flags a fair bit, but switched to using branches instead for development.

For our testing environment, we can access individual branches as subdomains to a testing environment.

This lets the in-progress code be separate from the mainline trunk, while also letting other people easily check out a new feature in a testing environment.

Only once or twice have we used 'feature flags' for trunk code; basically when the feature was ready to go, but may not wish to be activated until the last minute etc.

I can definitely see the advantage though of having feature flags for very high volume environments like Facebook to 'soft launch' projects (eg, to just staff) before making it live.

It's important though for code maintenance that you remove the feature flags after a while (once a project has settled in and won't be turned off), otherwise it can start to become a maintenance problem.

zmillman• 15 years ago

Our site (http://gre.magoosh.com) serves up content for a variety of exams, each of which is accessible from a single subdomain. Since content is developed for the exams somewhat independently, we have to be able to roll out releases at different speeds per exam, so we needed a solution a bit more complex than just feature flags -- here's the solution I built:

We keep a table of feature releases, each with a reference to the exam, a slug to identify the feature and an number from 0 to 100 indicating their status in the release cycle (100 = disabled, 75 = alpha, 50 = private beta, 25 = public beta, 0 = full release, etc.). Then each user is also assigned an integer which indicates the point in the release cycle at which they get to see features (0 by default). When we want to give them access to a feature, we just adjust their release access accordingly. All this is controlled through the admin interface.

We then use a helper (in views and server-side), feature_active_for?(feature_slug, user) which returns true the exam has the feature enabled and if the release status is less than or equal to the user's release access, so we can do stuff like:

if feature_active_for?(:lesson_videos, current_user)

# use video template

else

# use plain text template

end

This has worked really well so far, giving the non-technical content producers and customer support the ability to manage releases as they test content. However, the biggest advantage is that we can now give customers access to features before their public release to build goodwill after support requests and gather feedback. (we've been giving out a fraction of the refunds that we did before the release control)

I haven't actually removed any of the feature flags yet (we can reuse the release process for each other exam that we develop content for) but I'll probably remove one when it if becomes an integral part of the product across all of our exams. It would actually be pretty easy to just add to the helper to intercept release status checks and ease up on database requests.

This is probably all a bit more complicated than what you'll need, but I hope it helps.

Ask HN: Feature Flags?

Related Stories