Slide 1

Slide 1 text

Feature Flagの活⽤術

Slide 2

Slide 2 text

はじめに ・実運用におけるFeature Flagの活用についてお話します! ・Feature Flagとは何か? ・Feature Flagのメリット ・Feature Flagの利用事例 1~3 ・Feature Flagの失敗事例 1~2

Slide 3

Slide 3 text

Feature Flagとは ・機能の有効化・無効化をソースコードの修正や再デプロイ不要でできるようにする仕組 み(要するに、if文で表示・非表示を切り替えできる) 関数の実行時に true / falseが決まっている(例:環境変数、実行環境など)

Slide 4

Slide 4 text

Feature Flagのメリット 継続的デリバリの実現 ・機能をOFFの状態でリリースして、必要なタイミングでONにする ・→ リリース時期を待つことなくリリース可能に リリース時における不確実性の低減 ・ビックバンリリースの回避 ・一部のユーザーのみに公開できる ・A/Bテストの簡略化

Slide 5

Slide 5 text

開発中の新機能を隠す ・段階的にリリース(Feature FlagがOFFの状態なので顧客は利用できない) ・最低限、サイドメニューのリンクを隠すだけでもOK ・事前に複数顧客に触って欲しい場合などはこっちの方がいいかも ・絶対に利用されたくない場合は、ルーティングごと隠してアクセス無効に Feature Flagの活用事例①

Slide 6

Slide 6 text

一部の顧客でのテスト検証 ・課題を解決し得る機能かどうかを検証するために、一部の顧客のみに限定公開して一 定期間使ってもらう(結果次第ではボツ機能にすることも検討) Feature Flagの活用事例②

Slide 7

Slide 7 text

データベース移行時にも Feature Flagを活用できる! 背景 ・開発初期はHerokuのPostgreSQL (DB1) を使用していたが、 AWS RDS (DB2) へ移行 Feature Flag を活用した段階的な移行 1. Feature Flagを使い、DB1 ⇔ DB2 を動的に切り替え可能にする 2. リポジトリを統一し、どちらの DBにも対応できる設計 3. テーブルごとにFeature Flagを作成し、影響範囲を最小限に抑える 段階的リリースでリスクを軽減 1. 最初はHeroku の DB1 を使用 2. 一部のテーブルを AWS RDS (DB2) に切り替えて動作確認 3. 問題なければ、他のテーブルも順次 DB2に移行 4. Feature Flagを削除し、完全移行完了! 番外編:Feature Flagの活用事例③

Slide 8

Slide 8 text

Feature Flagの設定漏れ ・リリース後、本来は全ユーザーが利用できるはずの機能が、Feature Flagの設定ミス により一部のユーザーに対して非表示のままになっていた💦 → 最後いつ・誰が設定変更するかの考慮が漏れていた → 泥臭い方法ですが、Feature Flag設定時に記録を残して、いつ・誰が編集すべきか を明記していました(例:事前にタスクを切っておく、コメントアウト) Feature Flagの失敗例①

Slide 9

Slide 9 text

RTのテストケース作成時に... 既存機能に対して、Feature Flagで一部ユーザーに限定公開している場合、RTのテス トケース作成時の工数が肥大化する(Feature Flagがon/offの場合など) → ユーザーが利用している以上QAする必要がある! → ただ、リソースが足りない場合は事前の期待値コントロールをした上で、offの場合は QA項目から除外するのもあり(ただし機能による) Feature Flagの失敗例②

Slide 10

Slide 10 text

まとめ Feature Flagを用いることで様々なメリットあり ・段階的にリリースをすることで、大規模な障害を避けられる ・全体リリース前に一部の顧客からFBをもらえる 一方でデメリットもあり ・事前に運用を決めておかないと設定漏れやリソースの圧迫が起こる → 機能ごとにチームで合意をとった上でFeature Flagを使用する体制が好ましい