Documentation

Using Flags to Launch New Features

Learn how to use feature flags to build and launch new functionality with advice for the development process and iteratively expanding the size of the audience that has access to the new functionality.

Building great software requires feedback, early and often. Some features may take weeks or months to build, but you don't have to wait until everything is completely done to get feedback from your team or users. New features can be shipped to production quickly and safely behind a feature flag without disrupting anyone else, and then enabled individually for specific users as the feature matures.

This short guide shows how to add feature flags to your app, give early access to a few users, incrementally roll out to more users, and then fully ship it!

What is a feature flag?

A feature flag is a conditional that allows you to change the behavior of your app without changing the code. Here's an example:

def shipping_cost
  if Flipper.enabled? :shipping_calculator, user
    shipping_provider.calculate(weight, postal_code)
  else
    price * 0.1
  end
end

Here our method to calculate shipping cost has two branches of logic. We delegate to Flipper to decide if the new or original behavior should be used, and as you'll see shortly, Flipper gives that simple conditional super powers.

Add feature flags to your app

Before we begin, check out the Getting Started guide to install Flipper into your app, or use our Flipper Rails Demo as a starting point.

Adding feature flags to your app is as simple as adding conditionals anywhere you want to toggle access. So when adding a new feature that has visual components, simply wrap it with Flipper.enabled? to show or hide it.

app/views/dashboard/show.html.erb

<% if Flipper.enabled? :new_feature, current_user %>
  <%= link_to "New Feature", new_feature_path %>
<% end %>

Notice we pass in the current_user, which returns an instance of our User model will allow us to enable this feature for specific users later. This argument can be any actor that you want, be it a user, organization, or anything else with a unique identifier (flipper_id).

If the new feature has its own controller or model logic, you'll want to also add a feature flag there to ensure some unsuspecting user can't stumble upon it. Add a before_action to render our default 404 page if the feature is not enabled.

app/controllers/new_feature_controller.rb

class NewFeatureController < ApplicationController
  before_action :ensure_enabled

  def index
    render plain: "Work in Progress"
  end

  private

  def ensure_enabled
    render :not_found unless Flipper.enabled?(:new_feature, current_user)
  end
end

That's it! This new feature can be committed and even deployed to production. All features are disabled until you enable them, so nobody would see the new button we added or be able to access our new controller.

Enable the feature for yourself

You as the developer are likely the first person that will want access to this feature, so let's enable it for just you.

You can enable it from Flipper Cloud or your local console:

$ rails console

Flipper.enable_actor :new_feature, User.find_by(username: "me")

Now when you visit your app, the new feature will be visible for just you!

Read more: Enabling features for an actor

Enable the feature for a group

Once the feature is ready for more users, register a group that returns true if an actor is part of that group. This can be based on a value in the database or any other logic that you use to identify segments.

Here, we define an employees group that checks if they have an email address matching a specific domain:

config/initializers/flipper.rb

Flipper.register(:employees) do |actor|
  actor.email.ends_with?("@mycompany.com") && actor.verified?
end

You can enable it from Flipper Cloud or your local console:

$ rails console

Flipper.enable_group :new_feature, :employees

Now you can get feedback from your team before sharing the feature with your users.

Read more: Enabling features for a group

Enable the feature for a percentage of users

Congrats, the feature is now ready to share with users! This is a huge milestone, and hopefully you feel confident since you and your team have been able to thoroughly test the feature in production.

If your app has a lot of users, you can slowly roll out features to a small percentage of them at a time and make sure there are no issues at scale before letting more in.

From Flipper Cloud or your local console, you can enable for a percentage of actors:

$ rails console

Flipper.enable_percentage_of_actors :new_feature, 1

# Wait and verify
Flipper.enable_percentage_of_actors :new_feature, 5

# Wait some more
Flipper.enable_percentage_of_actors :new_feature, 20

# …

The feature will start to show up for a percentage of users (based on a consistent hashing algorithm), letting more and more people in as you increase the percentage.

Read more: Enabling features for a percentage of actors

Ship it!

When you're confident that your feature is ready for everyone, you can fully enable it from Flipper Cloud or your local console:

$ rails console

Flipper.enable :new_feature

Wrapping Up

Congrats on launching a new feature with feature flags! Doesn't it feel great to be completely in control of your code without having to redeploy?!?

Now that your feature is fully shipped, consider if you want to remove the feature flags or not. It's often helpful to leave them in case you need to disable the feature, take it down for maintenance, block bad actors, or later want to sunset it. Feature checks in Flipper are blazing fast, so there's not a performance reason to remove them.

On the other hand, a feature flag might include a code path that is now unused, in which case it may be worth removing the dead code to reduce technical debt. It's up to your specific scenario whether you want to remove the feature checks.