feature toggle アーキテクチャとは？デプロイとリリースを切り離す

feature toggle アーキテクチャは、新機能を runtime スイッチで包むことで、コードをリリースせずにデプロイし、デプロイなしで機能をオン・オフできるようにします。

コードのデプロイと機能のリリースは、同じイベントである必要はありません。feature toggle アーキテクチャはそれらを分離します。新しいコードを flag の背後に暗い状態で出荷し、後から設定でオンにします。これにより trunk-based development、段階的なロールアウト、即時の kill switch が解放されますが、flag の管理と組み合わせ的なテストの負担が加わります。

デプロイとリリースを切り離す

コードはオフのスイッチの背後で本番に到達します。デプロイはユーザーにとって非イベントであり、リリースは flag を切り替えたときに起こります。コードを一切 rollback せずに、機能を即座にオフにすることもできます。

何を可能にするか

trunk-based development: 未完成の作業を flag の背後で merge する。
段階的なロールアウト: 1%、次に10%、そして全員へ有効化する。
即時の kill switch: 悪い機能をデプロイなしで無効化する。
A/B testing とユーザーセグメント別のターゲット有効化。

アーキテクチャとしての flag

toggle は単なる if 文ではありません。大規模では flag サービス、一貫した評価、そしてインベントリが必要です。管理がなければ、古い flag が積み重なり、dead code と紛らわしい挙動の原因になります。

テストの課題

各 flag は可能なコード経路を倍増させるため、flag の組み合わせは急速に増えます。CI はすべての組み合わせをテストできないため、チームは重要な flag のオン・オフの状態と、実際に一緒に出荷される組み合わせをテストし、その後 flag を速やかに片付けて爆発を抑えます。

パイプラインをどう変えるか

未完成の機能が flag の背後で merge されるため、パイプラインは常にリリース可能な trunk からビルドします。これにより統合が継続的に保たれ、長命なブランチを避けられます。その代償は flag の衛生をめぐる規律です。

trunk への高速なフィードバック

trunk-based のフローは、頻繁な merge と頻繁なパイプライン実行を意味します。ウォームで高速な runner（Latchkey など）は、その高い merge の頻度が build のキュー待ち時間でボトルネックにならないようにします。

重要なポイント

feature toggle アーキテクチャは、コードのデプロイと機能のリリースを分離する。
trunk-based development、段階的なロールアウト、即時の kill switch を可能にする。
flag はコード経路を倍増させるので、一緒に出荷されるものをテストし、古い flag は引退させる。