この記事は ソフトウェアテストの小ネタ Advent Calendar 2024 14日目 の記事です。
はじめに
みなさんこんにちわ！ @afracs です！
今回はフィーチャーフラグを使ってQAコントロールがしやすくなった話を書こうと思います。
フィーチャーフラグの詳細については、検索すればいろいろな有識者の方の記事がヒットするので、詳しく知りたい方はそちらでご確認ください。
ここでは、フィーチャーフラグを使い始めたことで、弊社の環境がどう変わっていったのか？という話を書いていきたいと思います。
使う前と後でどう変わったの？
今までは、ブランチにマージされたらすぐにリリース対象になってしまうため、急いでQAしなければいけない世界線でした。
ですが、フィーチャーフラグを導入した後は、安全にリリースを行える環境になりました。
メリット1：QAコントロールがしやすい
弊社の場合、元々リリース頻度が高かったためQA頻度も多かったのですが、ここ1年くらい急速に開発ボリュームが増えていきており、さすがに対応しきれなくなってきてました。。。
検証に時間のかかる機能や検証規模が大きものについては、一旦検証のために検証用ブランチにマージするのですが、リリース物件からはリバートする、という運用で回していました。
さすがにずっとその方法だと厳しいので、まずは一部のプロダクトにフィーチャーフラグを導入し、お試し運用を開始しました。
その結果、
- リリースブランチへの出し入れがなくなった
- フィーチャーフラグ付きの機能については、周りのリリースを気にせずにQAが可能
- 並行してさまざまな機能のQAが可能
- 即時出したいものとの共存OK
- 複数フラグを同時にON、組み合わせてONなどの形で調整可能
- リリースタイミングごとに機能ON/OFFしてのQAが容易
と、いろいろな恩恵がありました。
メリット2：リリース調整がしやすい
機能実装やQAの進捗次第でリリース予定が前後してしまう場合、先にQA完了しているフィーチャーフラグ付きの機能をリリースする（リリース順番を入れ替える）ということが容易となりました。
ただしデメリットもある
三方良しとはなかなかうまくいかないもので、、、
フィーチャーフラグを導入した場合のデメリットも存在します。
デメリット1：フラグの数が多すぎると管理が大変
メリットでもあるのですが、フラグの数が多すぎると、どの組み合わせでQAを進めないといけないのか？といったテスト戦略をしっかり考える必要が出てきます。
例えば、フラグが2つくらいであれば、1つずつONにして、2つONにした時もちゃんと正しく動くよね、という確認が取れればOKです。
でも、それが10個とかになったらどうでしょう？
- リリースの順番
- QAの順番
- どのフィーチャーフラグの組み合わせまでテストするのか？
といった計画を立てて緻密に管理していかなければならなくなります。
デメリット2：フラグのお掃除が大変
これは主に実装担当者側の苦労になるのですが、本質的に必要なものではない（実現したい機能上必要なものではない）ため、使い終わったフィーチャーフラグを削除していく必要があります。
このリファクタリング作業が意外と大変で、全員がよく触る機能に入れいたりするとフラグ削除のコードマージの際に、神経を使います。
また、面倒だからといってそのまま放置しすぎるとスパゲッティになりがち、、、など、、、、、
弊社内のチームでもこのあたりは悩見どころですし、世の中でも同様に悩みの種になっているようです。。。
最後に
メリット・デメリット双方ありますが、今の弊社としては「フィーチャーフラグを導入してよかった！」という状態なので、このメリットを最大限活用しつつ、今後はデメリットの軽減を模索していけたらなぁと考えています。
フィーチャーフラグをまだ導入してなくて、QAやリリースが大変なチームの皆様は利用を一考してみてはどうでしょうか？
本記事が何かのお役に立てたのならば幸いです。
最後までお読みいただきありがとうございました。