どうも、拓田です。
「CI/CD」「フィーチャーフラグ」という言葉、大規模開発の文脈でよく出てきますよね。なんとなく「自動化」「テスト」みたいなイメージはあるけど、なぜブランチ戦略と一緒に語られるのかがピンとこない方も多いと思います。
今回は、CI/CDとフィーチャーフラグが「ブランチ戦略を補完する仕組み」であることを整理しました。
1. なぜ大規模開発で不可欠なのか
規模が大きくなると、こんな問題が出てきます。
・複数チームが同時並行で開発している
・ブランチが長生きするほどコンフリクトが増える
・手動テスト・手動デプロイでは対応が追いつかない
・一部の機能だけ特定ユーザーに先行公開したいケースも出てくる
これらをブランチ戦略だけで管理しようとすると必ず限界が来ます。CI/CDとフィーチャーフラグはブランチ戦略を補完する不可欠な仕組みです。
2. CI（継続的インテグレーション）
コードを main にマージするたびに自動でテストを実行する仕組みです。
featureブランチ → プルリクエスト
↓ 自動で発火
テスト実行・ビルド確認
↓
テストが通らないとマージできない
プルリクエスト時に表示される緑のチェックマーク・赤のバツがCIの結果です。
✅ 重要な誤解を解いておく
「GitHubが自動でチェックしてくれる」わけではありません。GitHub Actionsに処理を自分で定義することで動きます。 設定ファイル（.github/workflows/ci.yml）がリポジトリにあって初めて動く仕組みです。
3. CD（継続的デリバリー/デプロイ）
main にマージされたら自動でデプロイまで行う仕組みです。
mainにマージ
↓ GitHub Actionsで自動発火
ビルド → テスト → ステージング環境にデプロイ → 本番にデプロイ
規模が大きくなるほど手動デプロイはミスや遅延が増えるため、自動化が不可欠になります。
CIとCDの違い
| CI | CD | |
|---|---|---|
| タイミング | プルリクエスト・push時 | mainへのマージ後 |
| 目的 | テスト・ビルドの自動化 | デプロイの自動化 |
| 効果 | mainの品質を担保 | 人的ミスの排除・迅速なリリース |
4. GitHub Actionsとは
CI/CDを実現するためのGitHubの自動化ツールです。
管理場所
GitHubリポジトリの「Actions」タブで管理します。実行履歴の確認・成功失敗の結果確認・手動実行（workflow_dispatch）・キャッシュやランナーの管理ができます。
キャッシュ
ワークフローの実行を高速化するための仕組みです。
【キャッシュなし】
毎回のワークフロー実行ごとに
npm install や pip install を一からダウンロード
↓ 時間がかかる
【キャッシュあり】
初回だけダウンロードして保存
2回目以降はキャッシュから読み込む
↓ 高速化できる
ランナー
GitHub Actionsのワークフローを実際に実行するサーバーのことです。
| 種類 | 内容 |
|---|---|
| GitHub-hosted runner | GitHubが用意したサーバー。Ubuntu・Windows・Macが選べる。無料枠あり |
| Self-hosted runner | 自社サーバーやAWS上に用意する。セキュリティ要件が厳しい場合や無料枠を超える大規模実行に使う |
5. フィーチャーフラグとは
コードはマージ済みだが機能のON/OFFを切り替えられる仕組みです。
if (featureFlag.isEnabled("new_search")) {
// フラグがONの時だけ実行される（新機能）
showNewSearchUI();
} else {
// フラグがOFFの時に実行される（既存機能）
showOldSearchUI();
}
コードの読み方
-
"new_search"はフラグの識別名（関数名ではない） -
featureFlag.isEnabled("new_search")が外部設定を見に行ってON/OFFを判断して返す - ON → 新機能のコードを実行、OFF → 既存のコードを実行
フラグのON/OFFはどこで管理するか
コードの中ではなく外部の設定で管理します。
・環境変数
・データベース
・LaunchDarklyなどのフィーチャーフラグ管理サービス
再デプロイなしにフラグを切り替えられるのが大きなメリットです。
新機能を公開したい → 管理画面でフラグをONにするだけ
問題が起きた → 管理画面でフラグをOFFに戻すだけ
なぜブランチ戦略の補完になるのか
【フィーチャーフラグなし】
機能が完成するまでfeatureブランチを長期間維持
↓
ブランチが長生きするほどコンフリクトリスクが増大
【フィーチャーフラグあり】
未完成でもmainにマージ（フラグはOFF）
↓
完成したタイミングでフラグをONにする
↓
ブランチを長生きさせずに済む
6. CI/CDとフィーチャーフラグの組み合わせ
| 課題 | 解決手段 |
|---|---|
| 複数チームが同時にマージしてくる | CIで自動テストを徹底しmainの品質を担保 |
| 手動テスト・デプロイが追いつかない | CDで自動化し人的ミスを排除 |
| ブランチが長生きしてコンフリクトが増える | フィーチャーフラグでブランチを長生きさせない |
まとめ
- 🔍 CIはpushやプルリクエスト時に自動でテストを実行しmainの品質を担保する仕組み
- 🚀 CDはmainへのマージ後に自動でデプロイまで行う仕組み
- ⚙️ GitHub ActionsはCI/CDを実現するツール。GitHubが自動でやってくれるわけではなく自分で定義する必要がある
- 🚦 フィーチャーフラグはコードをマージ済みにしたまま機能のON/OFFを外部設定で制御する仕組み
- 🏗️ CI/CDとフィーチャーフラグはブランチ戦略だけでは管理しきれない大規模開発の複雑さを補完する不可欠な仕組み
ブランチ戦略・CI/CD・フィーチャーフラグは、それぞれ単体で語られることが多いですが、実際の大規模開発ではこの3つがセットで機能しています。どれか一つが欠けると開発スピードか品質のどちらかが犠牲になります。