Feature Flagとは
Martin Fowler氏はFeature Flagを以下のように紹介しています。
Feature Toggles (often also refered to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.
Feature Toggles (aka Feature Flags)
つまり、Feature Flagを導入することで新機能をユーザに段階的に公開できます。
以下はatlassianのFeature Flagの紹介図です。
また、Feature Flagは様々な呼び方で呼ばれていますが本記事ではFeature Flagで統一します。(posthogがFeature Flagと呼んでいるので。)
...個人的には「Feature Flag（フィーチャーフラグ）」をよく使うけど，これ以降は本記事に合わせて「Feature Toggle（フィーチャートグル）」を使う． Feature Flag（フィーチャーフラグ） Feature Toggle（フィーチャートグル） Feature Switch（フィーチャースイッチ） Feature Flipper（フィーチャーフリッパー） Feature Bit（フィーチャービット）
フィーチャーフラグにはタイプ（リリース・実験・運用・許可）がある！ より
Feature Flagが解決する課題
Feature Flagを導入することで以下の4つの課題を解決できます
- (機能)リリースと(コード)デプロイの分離
- 単一PRの粒度・レビュー負荷を低減
- コンフリクト発生数の最小化
- PRマージのリードタイム(=変更のリードタイム)を短縮によるプロダクトデリバリー効率の向上
各課題について詳細を説明します。
(機能)リリースと(コード)デプロイの分離
複数人・複数チームで開発していて、リリース前にmain branch(以降トピックブランチ)にマージする方式だと
- 単一のPRの粒度が大きくなる
- ビッグバンマージ
- コンフリクトが発生しやすい
- ロールバック時のリバートが大変
- コミット履歴が汚れる
これはビッグバンリリース対策でFeature Toggleを導入したら、開発チームが「デプロイできる状態」をより深く考えるようになった から引用しました。
この問題に対して、Feature Flagを導入することで
(コード)デプロイ = (機能)リリース
から
(コード)デプロイ → (機能)リリース
に変わります。
これが (機能)リリースと(コード)デプロイの分離 です。
単一PRの粒度・レビュー負荷を低減
feature flagを導入することで、mainブランチから分岐したfeature branchをflagをオフにした状態でトピックブランチにマージできます。
これにより単一PRの変更サイズが小さくなり、レビュー負荷を低減出来ます。
https://engineer.retty.me/entry/2022/04/15/120000
コンフリクト発生数を低減
長期間立ち続けるfeature branchが発生しにくくなるため、mainブランチとの乖離が減り、コンフリクトの発生数を低減出来ます。
さらに、開発人数が増加したことで並行開発が加速し、リファクタと機能実装の同時進行というケースも増加します。こうしたケースでは、リファクタの対応を機能実装の方に取り込むことが漏れてしまったり、取り込もうとしてもコンフリクトの対処に時間が取られてしまいます。こうしたブランチ運用に起因する課題に対しては、Feature Flagを導入し解決を目指しました。
https://agilejourney.uzabase.com/entry/2023/07/31/103000 より
PRマージのリードタイム(=変更のリードタイム)短縮によるプロダクトデリバリー効率の向上
これも単一PRの粒度・レビュー負荷を低減 の副作用ですが、レビュー負荷が低減されるため、PRマージのリードタイムが短縮されます。
これにより機能リリースのサイクルが速くなり、プロダクトデリバリー効率が向上します。
uzabaseの事例
Feature Flagの種類
Feature Flagはdynamism(変化)とlongevity(寿命)の2軸で4つに分類できます。
- リリース・トグル：一時的なフラグで、不完全で潜在的なコードをプロダクションに配布し、オン・オフを切り替えられる。
- 実験トグル：一般的に多変量A/Bテストに使用され、結果を収集するのに十分な時間だけそのままにしておく短期間のトグル。
- Opsトグル：パフォーマンスへの影響が不明確なリリースの場合、このトグルによってシステム管理者は迅速にロールバックすることができるが、キルスイッチとして長期的にトグルが残ることもある。
- パーミッショントグル：プレミアム」機能、アルファまたはベータ機能、あるいは内部機能など、特定のユーザーのための機能を管理します。これらのトグルは非常に長寿命になる可能性がある。
自分のチーム・プロダクトでは各feature flagをどの粒度でどれくらいの期間使うのかを相談した上でどの種類のfeature flagを使うのかを決めましょう。
Feature Flag（機能トグル、機能フラグ、フィーチャー・トグルとも呼ばれます）とは、簡単にいえば、コード内にフラグを設置し、ある機能のOn / Offを簡単に切り替えるための手法です。この手法を詳しく説明している記事を参照すると、トグルは「トグルが存続する期間（longevity）」と「トグルの決定がどの程度動的か（dynamism）」という2軸によって、4つのタイプに分類（以下図参照）されます。 この概念を参照しつつ、私たちはRelease Toggles（リリース・トグル）*2を利用する基本方針を採用しました。リリース・トグルの生存期間は一時的であるのが一般的で、1〜2週間以内にとどめることが推奨されています。また、トグルの決定は静的でリリース時に決定する、という仕様も推奨のとおりです。