デプロイした瞬間に全員に影響が出る状態を避けたい
Railsアプリで新機能を出すとき、怖いのは「本番へ置いた瞬間に全員へ影響が出る」ことです。
- 社内だけで試したい
- 一部の顧客だけに先行公開したい
- 問題が見つかったときに公開範囲をすぐ戻したい
こうした場面で役に立つのが、Feature Flagです。
Feature Flagがあると、デプロイ と リリース を分けて考えられます。コードは本番に置いておき、ユーザーに見せるかどうかは後から制御する、という考え方です。
Railsでこの運用を始めるなら、私は flipper が扱いやすいと思っています。
この記事では、flipper の基本的な考え方、ActiveRecordで持つ意味、導入手順、運用時に気をつけたい点をまとめます。
Feature Flagとは何か
Feature Flagは、機能の公開範囲を切り替えるための仕組みです。
デプロイ = コードを本番に置く
リリース = ユーザーに機能を見せる
この2つを分離できると、本番運用はだいぶ落ち着きます。
- 社内だけで有効化する
- 特定の会社だけで有効化する
- 一部ユーザーへ段階的に公開する
- 問題が見つかったら公開範囲を戻す
ロールバックせずに公開範囲を調整できる点が大きいです。
flipperが扱いやすい理由
flipper の README には、Ruby and Rails向けのfeature flaggingとあります。
実際に良いと感じるのは、誰に見せるか をデータとして持てるところです。
たとえば「この会社には new_ui を出す」「管理者だけ beta_export を使える」といった状態を、if文の散在ではなく、フラグとして管理できます。
ActiveRecordアダプタを使うと、その状態はRailsアプリのDBに保存されます。つまり機能フラグが単なる実装テクニックではなく、運用データとして扱いやすくなります。
BtoBのRailsアプリでは、この感覚が特に大事だと思っています。顧客ごとの公開範囲が、そのまま業務判断になることが多いからです。
ActiveRecordで導入する
Gemfile
gem "flipper"
gem "flipper-active_record"
bundle install
マイグレーション
rails generate flipper:active_record
rails db:migrate
これで flipper_features と flipper_gates が作られます。
flipperの保存構造
flipper_features は機能フラグの一覧、flipper_gates は公開条件の本体です。
flipper には複数のゲートがあります。日常的に使いやすいのは次のあたりです。
| ゲート | 意味 |
|---|---|
boolean |
全体ON / OFF |
actor |
特定のユーザーや会社 |
group |
管理者などのグループ |
percentage_of_actors |
一部ユーザーへ段階公開 |
percentage_of_time |
一部リクエストだけ有効 |
業務アプリでまず使うのは boolean actor group あたりだと思います。
使い方の基本
全体ON / OFF
Flipper.enable(:new_ui)
Flipper.disable(:new_ui)
特定の会社だけON
company = Company.find(42)
Flipper.enable_actor(:new_ui, company)
flipper はActiveRecordオブジェクトを Company;42 のような識別子に変換して保存します。モデルをそのまま公開対象として扱えるのがわかりやすいです。
管理者グループだけON
Flipper.register(:admins) { |actor| actor.admin? }
Flipper.enable_group(:new_ui, :admins)
一部ユーザーへ段階公開
Flipper.enable_percentage_of_actors(:new_ui, 10)
いきなり全体公開せず、影響を少しずつ広げられます。
ActiveRecordで持つメリット
外部サービスや一時的なメモではなく、DBに保存されていると次の点が扱いやすくなります。
- マイグレーションやアプリの構成と合わせて管理できる
- バックアップ対象として一緒に考えられる
- どの機能を誰に出しているかをRails側で追いやすい
- 顧客ごとの公開状態を業務データとして扱いやすい
「設定ファイル」より「公開ルールのデータ」に近い感覚です。
運用で気をつけたいこと
機能フラグは便利ですが、増やし方を誤ると逆に見通しが悪くなります。
1. 使い終わったフラグを消さない
古いフラグが残ると、分岐だけが増えていきます。いつ消すか 誰が責任を持つか を最初に決めておく方が安全です。
2. 複雑な業務判定を全部フラグに寄せる
機能フラグは公開範囲の制御には向いています。一方、複雑な料金判定や契約ロジックまで押し込むと、責務がぼやけます。業務ルールと公開制御は分けて考えた方が整理しやすいです。
3. リリース判断が属人化する
誰が本番フラグを切り替えるのか、切り替え時に何を見るのかが曖昧だと運用事故になります。管理画面を使うにしても、最低限の運用ルールは必要です。
どんなRailsアプリで相性が良いか
flipper は次のような場面で特に相性が良いと思っています。
- 顧客ごとに公開範囲を分けたい
- 社内検証を経てから本公開したい
- リリース頻度を上げたい
- 再デプロイなしで公開範囲を調整したい
逆に、公開範囲の出し分けがほぼ要らないアプリなら、最初から大きく持ち込まなくてもよいこともあります。
まとめ
flipper は単なるif文のラッパーではなく、機能の公開範囲をデータとして持たせるための道具です。
RailsでActiveRecordアダプタを使うと、その判断をアプリの文脈に寄せたまま管理できます。デプロイとリリースを切り分けたいRailsアプリでは、早い段階で検討する価値がある選択肢です。