TL;DR
コードを変えずにシステムの振る舞いを切り替えるための仕組み。複数のコードパスを 1 つの成果物に入れてデプロイし、どれを使うかを実行時に選ぶ。フィーチャートグル、機能フラグとも呼ばれる。
なぜ必要か
未完成の機能もメインのブランチにマージして本番にデプロイできるので、長く生きるブランチを避けられる。Pete Hodgson の記事によると、これによってトランクベース開発を実践でき、機能のリリースとコードのデプロイを切り離せる。
仕組み
Pete Hodgson は、フラグを寿命の長さと判断の動的さで 4 種類に分けている。
- リリーストグル: 未完成の機能を、有効にしない状態で本番に出す。寿命は短く、判断は静的である。
- 実験トグル: A/B テストのために、ユーザをグループに分けてグループごとに同じコードパスを通す。判断は非常に動的である。
- 運用トグル: システムの運用面の振る舞いを切り替える。高負荷時に重要でない機能を止めるキルスイッチのように、長く残るものもある。
- 権限トグル: 有料機能やベータ機能など、ユーザごとに使える機能を変える。何年も残ることがあり、リクエストごとに判断する。
例
- GO Feature Flag は、Go でフィーチャーフラグを管理するためのライブラリである。
注意点
フラグは条件分岐や抽象化を増やし、テストの負担も大きくする。Pete Hodgson は、フラグを維持費のかかる在庫とみなし、不要になったら積極的に消すよう勧めている。リリーストグルを作るときに削除のタスクをバックログに入れる、有効期限を決める、有効なフラグの数に上限を設けるといった方法がある。