CI/CD レッスン4
フィーチャーフラグ
コードのデプロイと機能の公開を切り離すフィーチャーフラグの仕組みと活用パターンを学ぶ
デプロイと公開を分離する
「コードを本番環境に配置すること(デプロイ)」と「ユーザーがその機能を使えるようになること(公開/リリース)」は、 本来別の概念です。フィーチャーフラグは、 この2つを切り離し、コードはデプロイ済みでも、フラグをオンにするまで機能を隠しておける仕組みです。
基本的な使い方
// ① feature-flags.ts: フラグの状態を取得する
function isFeatureEnabled(flagName: string, userId: string): boolean {
const flags = getFlagsFromConfig(); // 設定サービスやDBから取得
return flags[flagName]?.enabledForUser(userId) ?? false;
}
// ② checkout.ts: 新しい決済フローをフラグで制御する
function renderCheckoutPage(user) {
if (isFeatureEnabled("new-checkout-flow", user.id)) {
return renderNewCheckoutFlow(user);
}
return renderLegacyCheckoutFlow(user);
}新しい決済フローのコードは既に本番にデプロイされていますが、 フラグがオフのユーザーには旧フローが表示され続けます。 問題があればフラグをオフに戻すだけで、再デプロイなしに即座に切り戻せます。
代表的な活用パターン
段階的ロールアウト
カナリアリリースと組み合わせ、対象ユーザーの割合を少しずつ増やしていく。
A/Bテスト
ユーザーを2グループに分け、それぞれ異なる実装を見せて指標を比較する。
キルスイッチ
負荷が高い機能や外部APIとの連携を、障害時に即座に無効化できるようにしておく。
未完成機能の先行マージ
長期ブランチを避け、未完成の機能もフラグで隠しつつmainへ統合し続けられる。
運用上の注意点
フラグの負債化に注意
フィーチャーフラグは便利な反面、条件分岐が増えるとコードの複雑度が上がります。 機能が完全に定着し不要になったフラグは、放置せずコードから削除することが重要です。
- • フラグには有効期限や担当者を紐づけ、棚卸しの仕組みを作る
- • フラグの組み合わせ数が増えすぎるとテストパターンが爆発するため、数を絞る
- • フラグの状態変更自体もログに残し、いつ誰が切り替えたか追跡できるようにする
ポイント
- • フィーチャーフラグはデプロイと機能公開のタイミングを切り離す仕組み
- • 問題発生時はフラグをオフにするだけで再デプロイなしに切り戻せる
- • 段階的ロールアウト・A/Bテスト・キルスイッチなど多様な活用ができる
- • 不要になったフラグは削除し、複雑度の負債を残さない
確認クイズ
1 / 3フィーチャーフラグが実現する本質的な仕組みはどれか？