Add feature flag support using Flipper #387

mrodriguez90 · 2023-07-06T17:50:24Z

Purpose

Add a Feature Flag system to the rails_api_base using Flipper

Summary

Adds Flipper
Adds the ActiveRecord adapter to store Flipper data
Adds Flipper-UI to manage feature flags using the interface provided by Flipper.
Includes the flipper id to the user model, this adds a flipper_id to the user model, this is what you use to enable a feature flag for a given user.
Adds an initializer for a route constraint that only allows AdminUser with a valid session to access the Flipper UI.
Updates to the Readme

Context

Ruby community

Task

Notion task

Follow-Ups

Add a cache layer to improve performance, see https://www.flippercloud.io/docs/optimization - Notion Task
Add audit history - Notion Task
Configure Flipper for testing - Notion Task

This is what an `AdminUser` with a valid session will see

sebastiancaraballo

LGTM. Left some non-blocking comments.

sebastiancaraballo · 2023-07-06T19:23:11Z

README.md

@@ -79,6 +80,9 @@ To illustrate, `bin/rails console` will run the console in the docker container
 - [ExceptionHunter](https://github.com/rootstrap/exception_hunter) for exception tracking
 - [Factory Bot](https://github.com/thoughtbot/factory_bot) for testing data
 - [Faker](https://github.com/stympy/faker) for generating test data
+- [flipper](https://github.com/jnunemaker/flipper) for feature flag support
+- [flipper-active_record](https://github.com/jnunemaker/flipper) for Flipper active_record support
+- [flipper-ui](https://github.com/jnunemaker/flipper) for UI-based feature flag management


I'm wondering if we should have a /docs directory to briefly explain how to access the visual Flipper interface or other relevant items about how / why to use Flipper. Same applies to new features.

sebastiancaraballo · 2023-07-06T19:26:33Z

app/models/user.rb

@@ -35,6 +35,7 @@ class User < ApplicationRecord
  devise :database_authenticatable, :registerable,
         :recoverable, :trackable, :validatable
  include DeviseTokenAuth::Concerns::User
+  include Flipper::Identifier


What is this for? Just asking.

I think it's to add the flipper_id method that identifies the "actor".

Should we include it in ApplicationRecord so that all of our records have the method defined? For example an app could have a model Product and we might only want to enable certain feature for some products.. just thinking out loud, would like to hear others' thoughts

I think that could be an option, the implementation shouldn't impact or be tightly coupled with the business logic

I'm not sure about including this in ApplicationRecord. Feature flags are typically required for only a limited number of models, like User, Organization, Product.

Can you check if this is true? Seems like Flipper already configures ActiveRecord::Base to include Flipper::Identifier.

If that's the case we can remove this line

@santib yes, nice catch, it looks like their getting started guide is out of date

sebastiancaraballo · 2023-07-06T19:28:37Z

config/initializers/flipper.rb

+class CanAccessFlipperUI
+  def self.matches?(request)
+    current_user = request.env['warden'].user
+    current_user.present? && current_user.is_a?(AdminUser)


I think this should be documented because we are imposing that the user should be of type AdminUser.

db/migrate/20230704182448_create_flipper_tables.rb

sebastiancaraballo · 2023-07-06T19:37:37Z

config/routes.rb

@@ -1,6 +1,9 @@
 Rails.application.routes.draw do
  devise_for :admin_users, ActiveAdmin::Devise.config
  ActiveAdmin.routes(self)
+  constraints CanAccessFlipperUI do
+    mount Flipper::UI.app(Flipper) => '/flipper'


Do we want this enabled by default? Again just thinking out loud.

config/routes.rb

diego-suarez

🌝 🏴

config/initializers/flipper.rb

Gemfile

config/initializers/flipper.rb

config/routes.rb

config/initializers/flipper.rb

blacksam07 · 2023-07-07T13:57:48Z

@mrodriguez90 @santib What is the purpose of including Flipper in rails_api_base? I know Flipper is an awesome tool, but not all projects will use this feature and will only have thrash gems with useless code

mrodriguez90 · 2023-07-07T14:19:37Z

@mrodriguez90 @santib What is the purpose of including Flipper in rails_api_base? I know Flipper is an awesome tool, but not all projects will use this feature and will only have thrash gems with useless code

@blacksam07 I think anyone could benefit from using a tool like this. From my POV, it's an excellent tool and a compelling reason to select the rails_api_base to start any project, particularly for the time you could save by having this tool already set up.

For people who don't require this tool, I think it's much simpler to remove the gem and a few lines of code, rather than investing the effort required to configure it for those who actually want it. The same idea applies to all the gems in the base.

I think it's very unlikely to find a base that covers everything you need and in the way you need it. I think people use the base that most closely matches their needs and then change it as needed.

santib · 2023-07-07T14:22:58Z

@mrodriguez90 @santib What is the purpose of including Flipper in rails_api_base? I know Flipper is an awesome tool, but not all projects will use this feature and will only have thrash gems with useless code

@blacksam07 So first of all, I agree that we need to be thoughtful about what we add to a base app 👍 On the other hand, I don't see "feature flags" (or flipper) as a feature. Actually, for me it's more like a Platform tool, and that's why I think it's a good idea to have it in ALL of our projects. Because for me it shouldn't be considered an optional thing, instead I'd like to promote a way of working by encouraging continuous integration and delivery flows with the usage of Feature Flags. There are different kinds of feature flags, the ones I'm specifically referring to, are the "release toggles".

they are intended as a tool for Engineers and Site Reliability Engineers to use to de-risk their changes. Feature flags are the shim that gets us to Continuous Delivery with our monorepo and without having to deploy the entire codebase on every change. Feature flags are created to ensure that we can safely rollout our work on our terms.

https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle

blacksam07 · 2023-07-07T15:12:13Z

@mrodriguez90 @santib thanks for your replies, I catch the both points, and I know that Flipper/Feature Flags is an awesome tool, and we can define as a great tool in our projects, my initial comment was because this is a Community repo not just for out internal projects and we need to be carefully with all new features/tools/config that we include here.

Also, this is a great job 👏

santib · 2023-07-07T20:18:48Z

README.md

+- [flipper](https://github.com/jnunemaker/flipper) for feature flag support
+- [flipper-active_record](https://github.com/jnunemaker/flipper) for Flipper active_record support
+- [flipper-ui](https://github.com/jnunemaker/flipper) for UI-based feature flag management


maybe in this place of the docs we can just say

- [Flipper](https://github.com/jnunemaker/flipper) for feature flag support

the activerecord and UI things can be implicit I guess?

config/routes.rb

santib

Maybe we can add a link in the admin panel, so that admins can easily navigate to the FFs page?

@santib

santib · 2023-07-07T20:32:12Z

Oh I just realized there are configs for the UI just in case we want to remove the cloud recommendation or change the texts, adding a link back to the admin or something.

Also, not sure if we need to add some mechanism to auto-create flags disabled by default. For example, if I, as a dev add a flag to the code, when I deploy the code I want the flag to automatically appear in the dashboard being disasbled. Right? Is that currently happening?

mrodriguez90 · 2023-07-10T15:02:42Z

Oh I just realized there are configs for the UI just in case we want to remove the cloud recommendation or change the texts, adding a link back to the admin or something.

Also, not sure if we need to add some mechanism to auto-create flags disabled by default. For example, if I, as a dev add a flag to the code, when I deploy the code I want the flag to automatically appear in the dashboard being disasbled. Right? Is that currently happening?

@santib I'll add a new task for the UI changes. All FFs are disabled by default

mrodriguez90 · 2023-07-10T15:04:30Z

config/initializers/active_admin.rb

+  config.namespace :admin do |admin|
+    admin.build_menu :default do |menu|
+      menu.add label: 'Feature Flags',
+               url: '/admin/feature-flags', html_options: { target: :blank }
+    end
+  end


this adds the feature flag menu item to the active_admin page

db/migrate/20230704182448_create_flipper_tables.rb

mrodriguez90 · 2023-07-10T15:06:01Z

spec/rails_helper.rb

@@ -24,6 +24,7 @@
 RSpec.configure do |config|
  config.render_views = true
  config.include Devise::Test::ControllerHelpers, type: :controller
+  config.include Devise::Test::IntegrationHelpers, type: :request


adds devise helpers like sign_in to requests tests

santib · 2023-07-10T15:51:32Z

@santib I'll add a new task for the UI changes. All FFs are disabled by default

@mrodriguez90 Just to clarify what I'm referring to, I think that it'd be good that FFs that are added in the codebase, appear in the Flipper UI automatically.

e.g.

As a developer I add the feature flag "chatbot-helper"
I deploy the feature flag
As an admin I should see a new feature flag "chatbot-helper" in the Flipper UI

Is that currently happening? Or do we need to "register" the Feature Flag so that it appears automatically in the UI?

mrodriguez90 · 2023-07-11T13:31:44Z

@santib I'll add a new task for the UI changes. All FFs are disabled by default

@mrodriguez90 Just to clarify what I'm referring to, I think that it'd be good that FFs that are added in the codebase, appear in the Flipper UI automatically.

e.g.

As a developer I add the feature flag "chatbot-helper"

I deploy the feature flag

As an admin I should see a new feature flag "chatbot-helper" in the Flipper UI

Is that currently happening? Or do we need to "register" the Feature Flag so that it appears automatically in the UI?

@santib Oh I see, if a developer adds a feature flag in the code it won't show up in the UI automatically, someone has to register the flag first.

This is how I imagine the dev experience:

As a developer, you register a feature flag locally, and you merge your changes into production.
As a developer you register the same feature flag in production, and your turn it on.

Since these feature flags are stored in the database, I don't think there is an easy way to automatically register them from the codebase.

santib · 2023-07-11T13:47:18Z

@santib I'll add a new task for the UI changes. All FFs are disabled by default

@mrodriguez90 Just to clarify what I'm referring to, I think that it'd be good that FFs that are added in the codebase, appear in the Flipper UI automatically.
e.g.

As a developer I add the feature flag "chatbot-helper"

I deploy the feature flag

As an admin I should see a new feature flag "chatbot-helper" in the Flipper UI

Is that currently happening? Or do we need to "register" the Feature Flag so that it appears automatically in the UI?

@santib Oh I see, if a developer adds a feature flag in the code it won't show up in the UI automatically, someone has to register the flag first.

This is how I imagine the dev experience:

As a developer, you register a feature flag locally, and you merge your changes into production.

As a developer you register the same feature flag in production, and your turn it on.

Since these feature flags are stored in the database, I don't think there is an easy way to automatically register them from the codebase.

@mrodriguez90 Maybe we can have them defined in a YML or a Ruby class, read it and create them. Maybe in a rake task that is automatically run on every release we can do something like

namespace :feature_flags do
  desc 'Initialize and turn off all the new feature flags so they are available in the UI'
  task initialize: [:environment, :default_tenant] do
    FeatureFlags::NAMES.each do |feature_flag|
      next if Flipper.exist?(feature_flag)

      Flipper.disable(feature_flag)
    end
  end
end

or for example Gitlab also defines feature flags in more places than just calls in the codebase. I think that is a good idea not only for having them in the UI but also to keep track of all existing flags BTW.

Maybe we can call leave it for another PR, but I think it'd be good to have a centralized place where we store the flags, and also use that for their initialization. That way we also prevent mistakes (e.g. typos) if a dev has to good to the UI and manually enter the flag name

mrodriguez90 · 2023-07-11T14:00:07Z

@santib I'll add a new task for the UI changes. All FFs are disabled by default

@mrodriguez90 Just to clarify what I'm referring to, I think that it'd be good that FFs that are added in the codebase, appear in the Flipper UI automatically.
e.g.

As a developer I add the feature flag "chatbot-helper"

I deploy the feature flag

As an admin I should see a new feature flag "chatbot-helper" in the Flipper UI

Is that currently happening? Or do we need to "register" the Feature Flag so that it appears automatically in the UI?

@santib Oh I see, if a developer adds a feature flag in the code it won't show up in the UI automatically, someone has to register the flag first.
This is how I imagine the dev experience:

As a developer, you register a feature flag locally, and you merge your changes into production.

As a developer you register the same feature flag in production, and your turn it on.

Since these feature flags are stored in the database, I don't think there is an easy way to automatically register them from the codebase.

@mrodriguez90 Maybe we can have them defined in a YML or a Ruby class, read it and create them. Maybe in a rake task that is automatically run on every release we can do something like
namespace :feature_flags do
  desc 'Initialize and turn off all the new feature flags so they are available in the UI'
  task initialize: [:environment, :default_tenant] do
    FeatureFlags::NAMES.each do |feature_flag|
      next if Flipper.exist?(feature_flag)

      Flipper.disable(feature_flag)
    end
  end
end
or for example Gitlab also defines feature flags in more places than just calls in the codebase. I think that is a good idea not only for having them in the UI but also to keep track of all existing flags BTW.

Maybe we can call leave it for another PR, but I think it'd be good to have a centralized place where we store the flags, and also use that for their initialization. That way we also prevent mistakes (e.g. typos) if a dev has to good to the UI and manually enter the flag name

I like this, I'll add a new task to do it in a follow-up PR

Add feature flag support using Flipper

d47951f

mrodriguez90 requested review from a team, megatux, femartinez, JuanfraM, santib, santiagovidal, enzofab91, lauperalti, guillermoap, PerezIgnacio, JulianPasquale, smerlo, sebastiancaraballo, jpascual1994, mwolman and TimoPeraza and removed request for a team July 6, 2023 19:12

mrodriguez90 marked this pull request as ready for review July 6, 2023 19:17

sebastiancaraballo approved these changes Jul 6, 2023

View reviewed changes

JulianPasquale reviewed Jul 6, 2023

View reviewed changes

config/routes.rb Outdated Show resolved Hide resolved

diego-suarez approved these changes Jul 6, 2023

View reviewed changes

config/initializers/flipper.rb Outdated Show resolved Hide resolved