FeatureFlagとは？
- 新機能の公開や変更を簡単に制御できるようにする
- コード内にフラグを埋め込むことで、機能のオン/オフができる
FeatureFlagのメリット
- コードのマージ・デプロイタイミングと、公開（リリース）タイミングを分けることができ、公開時の作業を減らすことができる
- 機能リリースタイミングに依存せずに開発チームは任意のタイミングでコードをデプロイすることが可能
- デプロイの独立性が高まることで、開発チームは迅速に短いスパンでコード変更をメインブランチにマージしたり、本番環境にデプロイしたりしやすくなります。
- ロールバックが即時でできる
- A/Bテスト可能
- ユーザーの半分は新機能を有効化し、残りは無効化にします。そして本番環境で特定のメトリクス（アプリの使用率、コンバージョン率など）やユーザーフィードバックを収集します。それらを分析して、新機能を完全にリリースするか、改善するか、削除するかなど、実データに基づいた精度の高い意思決定をすることができます。
- 段階的リリース可能
- チーム間の調整コストが下がる
- Android, iOS, Web, BackendがFlagによる共通認識ができる
- 開発中の機能をマージすることができる
-
コンフリクト対策
-
ビックバンリリースによる障害対策
胃が痛いビッグバンリリースはもう嫌なので、デプロイを日常にする - Qiita -
旧機能に問題がないことを確認しながら開発ができる
-
FeatureFlagのデメリット
- フラグが増えすぎるとカオス
- 古いフラグの消し忘れ
- Flagの不整合(Backend側とUIの不整合)
- テストケースの増加
気をつけること
- 全解放されたFeatureFlagは除去しよう
- 機能の調整をして複雑性をなくそう
導入へ
- 目玉機能など、長期間かけて行う修正はFeatureFlagを導入しても良いのでは？
- ロールバックを行う可能性がある重要な機能とか
- A/Bテストやっていこう
参考