Featureフラグについて調べた
こちらの資料が主に参考になった speakerdeck.com
RevComm社がサービスの安定性と信頼性を高めるためにFeature Flagを導入し、実践した過程と結果をまとめたもの
Feature Flagとは、ソースコードの修正や再デプロイなしに機能の有効化・無効化を制御する手法
単純な解釈だとソースコード上に新機能を利用するかどうかのフラグが出現するイメージ
if( useNewAlgorithm ){ return enhancedSplineReticulation(); }else{ return oldFashionedSplineReticulation(); }
このスライドで知ったのは、Martin Fowler氏がFeatureフラグ（Feature Toggle）についての記事を書いており、その中でFeatureフラグを生存期間と変更頻度という2つの軸で分類していること
生存期間は、Featureフラグをいつまで使うのか？という観点
Feature Flagの中には、数年という単位で利用されるものもあれば、数日といった短い期間で役目を終えるものもあるらしい
変更頻度は、どの程度の頻度でFeatureフラグを変更する必要があるのか？という観点
デプロイのたびに変わるものもあれば、実行中に再設定が必要なもの、リクエストごとに変更するものなど、さまざまあると
氏によると、この２軸を組み合わせることで、Feature Flagは下記の4種類に分類される
- Release Toggles: 未完成のコードもリリースできるようにするために利用される。 トランクベース開発などで用いられ、リリースの制御を目的とする。
- Experiment Toggles: A/Bテストを実施する際に利用される。 リクエストごとにランタイムで特定のコードを実行する。
- Ops Toggles: システムの運用面の振る舞いを制御するために利用される。 機能のパフォーマンスが不明確な場合や、必要に応じて迅速に機能を無効化したい場合などに用いられる。
- Permission Toggles: 特定のユーザーに対してのみ、恒久的に製品体験を変更するために利用される。 例えば、プレミアムユーザーだけに特定の機能を有効化するといった場合に用いられる。
これを参考に、最適な実装方針を決定する必要がある
Featureフラグという名前ではなかったが、私はA/Bテストの目的でFeatureフラグを使った経験があった（Experiment Toggles）
この時の感想としては、プランナーからA/Bテストしたいからとフラグの追加要求はあるものの、削除要求はなかったためフラグが残り、かなり運用が大変だった思い出がある
導入するのは良いが、不要になった定期的に削除する仕組み作りが必要であると思う
その仕組みに関しては、こちらのスライドが参考になった
OpenFeatureと自動生成を活用したフィーチャーフラグの宣言的集約管理 - Speaker Deck
フラグの利用が一定期間通過したら落ちるテストを自動生成してCIで落とす仕組み
ここまでやらないとうまくいかない気がしている
