デプロイとリリースは別物だ：GitHub Actionsとフィーチャーフラグで実現する「攻めのダークローンチ」極限バイブル
こんにちは。テックリードの私だ。
日々のリリース作業で、こんな悪夢を見たことはないか？
「金曜夕方のデプロイ直後、データベースのコネクションプールが枯渇。ロールバックしようにも、巨大なモノリスの巻き戻しには15分かかる。その間にもSaaSのダッシュボードではエラーレートが跳ね上がり、冷や汗が背中を伝う……」
もう、こんなギャンブルのようなデプロイはやめにしよう。
現代のハイパフォーマンチームにおいて、「コードを本番環境へデプロイすること（Deployment）」と「ユーザーに機能を公開すること（Release）」は完全に切り離されていなければならない。
今回は、GitHub ActionsとLaunchDarklyなどのフィーチャーフラグ管理ツールを極限まで統合し、「デプロイの恐怖をゼロにし、数秒で機能をON/OFFするダークローンチ基盤」を構築する実践的アプローチを伝授する。
—
1. 思想：なぜ「デプロイ」と「リリース」を分離すべきなのか
従来のCI/CDパイプラインは、`main`ブランチへのマージイコール本番リリースだった。これでは、どれだけテストを自動化しても、未知の本番環境でのバグ（特に負荷や外部連携に起因するもの）を防ぎきれない。
フィーチャーフラグ（機能トグル）を導入すると、ワークフローはこう変わる：
1. コードの静的解析とビルド（GitHub Actions）
2. 本番環境へのダークデプロイ（ユーザーには見えない状態でコードが常駐）
3. フラグ制御による段階的リリース（カナリア・ロールアウト）（API経由で即座にON/OFF）
4. 問題発生時のミリ秒単位でのキルスイッチ発動（コードを触らずにフラグをOFF）
このサイクルを回すことで、GitOpsの哲学とフィーチャーフラグ管理が融合し、開発スピードとシステムの堅牢性が同時に跳ね上がる。
—
2. 現場の生産性を爆上げするハック
本題に入る前に、このワークフローを日々の開発で回すための「隠し味」を共有しよう。
開発体験（DX）を高めるキーボード＆CLIショートカット
- GitHub CLI (`gh`) のエイリアス活用:
ワークフローのステータス確認や手動トリガー（`workflow_run`）をブラウザを開かずに叩く。
# 失敗したアクションのログを即座にターミナルに引きずり出す
gh run view –log-failed
- LaunchDarkly CLI (`ld-find-code-references`):
コードベース内の「死んだフラグ（長期間放置されたフラグ）」を検出し、CI上でビルドエラーにするか警告を出す。技術的負債の蓄積をCI層でブロックするのだ。
—
3. 実装：GitHub Actions × LaunchDarkly 連携パイプライン
それでは、実際に動くプロダクションレベルのYAML設定を解説する。
このワークフローは、以下の要件を満たす。
1. プルリクエスト作成時に、コード内で使用されているフィーチャーフラグの存在を検証。
2. `main`へのマージ時に本番環境へダークデプロイ。
3. デプロイ成功後、LaunchDarklyのAPIを叩いて自動的にターゲット環境のフラグ状態を同期・制御。
`.github/workflows/feature-flag-deploy.yml`
name: “Dark Launch & Feature Flag Sync Pipeline”
on:
push:
branches:
- main
pull_request:
branches:
- main
同時実行制御：同一ブランチへの連続プッシュは古いものを容赦なくキャンセルし、
リソースの無駄遣いと競合を防ぐ（DevOpsの基本布石）
concurrency:
group: ${{ github.workflow }}-${$ github.ref }}
cancel-in-progress: true
jobs:
# —————————————————————–
# Job 1: コード内のフラグ参照検証（技術的負債の予防）
# —————————————————————–
validate-flags:
name: Validate Feature Flags
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
- name: Install Dependencies
run: npm ci
# LaunchDarklyの公式アクションを使用し、コード内のフラグキーが
# 実際にLDダッシュボード上に存在するかを静的チェック
- name: Verify Code References with LaunchDarkly
uses: launchdarkly/find-code-references-action@v2
with:
accessToken: ${{ secrets.LD_ACCESS_TOKEN }}
projectKey: ${{ secrets.LD_PROJECT_KEY }}
repoName: ${{ github.repository }}
commitHash: ${{ github.sha }}
# —————————————————————–
# Job 2: ビルド＆ダークデプロイ
# —————————————————————–
dark-deploy:
name: Dark Deploy to Production
needs: validate-flags
if: github.event_name == ‘push’ && github.ref == ‘refs/heads/main’
runs-on: ubuntu-latest
environment: production # GitHub Environmentsの保護ルール（承認者設定など）を適用
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Set up Cloud SDK (e.g., AWS / GCP)
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ap-northeast-1
- name: Build and Push Container Image
run: |
echo “Building Docker image with dark-launch capability…”
# docker build & push の処理をここに記述
# 例: docker build -t my-app:${{ github.sha }} .
- name: Deploy to Production (Zero Downtime)
run: |
echo “Executing rolling update…”
# ECSやK8sへのデプロイコマンド
# この時点では新機能はフラグがOFFのためユーザーには露出しない
# —————————————————————–
# Job 3: フラグの自動制御（CI/CDとフラグライフサイクルの同期）
# —————————————————————–
sync-flag-state:
name: Sync LaunchDarkly Flag
needs: dark-deploy
runs-on: ubuntu-latest
steps:
- name: Control Feature Flag via LD REST API
env:
LD_ACCESS_TOKEN: ${{ secrets.LD_ACCESS_TOKEN }}
LD_PROJECT_KEY: ${{ secrets.LD_PROJECT_KEY }}
LD_ENV_KEY: ‘production’
# 例として制御したいフラグのキー
FEATURE_FLAG_KEY: ‘new-checkout-flow’
run: |
echo “Synchronizing feature flag state for automated rollout…”
# パッチJSONの作成：必要に応じてここでターゲットルールの追加や
# デフォルトルールの変更をAPI経由でプログラムmaticallyに実行できる。
# ここでは安全のため、デプロイ完了後に特定の社内テストユーザー向けにのみONにする例。
curl –request PATCH \
–url “https://app.launchdarkly.com/api/v2/flags/${{ env.LD_PROJECT_KEY }}/${{ env.FEATURE_FLAG_KEY }}” \
–header “Authorization: ${{ env.LD_ACCESS_TOKEN }}” \
–header “Content-Type: application/json; domain-version=20220603” \
–data ‘{
“instructions”: [
{
“kind”: “updateDescription”,
“description”: “Auto-updated by GitHub Actions workflow run ${{ github.run_id }}”
}
]
}’
—
4. チーム開発におけるルールとベストプラクティス
このパイプラインをチームに導入し、カオスを生み出さないための「鉄の掟」を共有する。
1. フラグには必ず「寿命（TTL）」を持たせろ
フィーチャーフラグの最大の敵は「消し忘れ」だ。コードベースがif文の要塞になり、技術的負債化する。
- ルール: フラグを作成する際、Jiraチケットと紐付け、「公開後2週間以内にコードからフラグを完全削除する（フラグを常時ONの状態にしてコードをクリーンアップする）」ことをPRのマージ条件に組み込む。前述の `validate-flags` ジョブはその強制力を担保する強力な武器になる。
2. GitHub Environments の承認ゲートを組み合わせる
`dark-deploy` ジョブで紹介した `environment: production` 設定。これに対し、GitHubのレポジトリ設定で「Required reviewers（必須承認者）」を設定しておこう。
コードのビルドとダークデプロイまでは完全自動化し、「本番環境のフラグを実際に誰に・どのセグメントに開放するか」というビジネスロジックの最終承認だけを人間が担う、というハイブリッドな統制が可能になる。
3. キルスイッチ（緊急停止）のドリルを定期化せよ
万が一、ダークローンチした機能が悪影響を及ぼした場合、GitHub Actionsのロールバックを待つ必要はない。
LaunchDarklyのダッシュボード、あるいはSlack連携コマンド（例: `/ld toggle new-checkout-flow off`）を叩くだけで、0秒で機能を殺せる状態をチームメンバー全員が把握していること。これこそが、エンジニアが夜ぐっすり眠れるための必須条件だ。
—
5. おわりに：本当の「アジリティ」を手に入れろ
「デプロイが怖い」という感情は、プロセスの不確実性から生まれる。
GitHub Actionsによる堅牢なCI/CDパイプラインと、フィーチャーフラグによる精密なリリース制御を組み合わせれば、その恐怖は「いつでも安全に本番環境へ変更を届けられる」という確信へと変わる。
恐れるな。コードを書き、安全にデプロイし、スイッチ一つで世界を書き換えろ。
君のチームのデプロイ体験が、今日から劇的に変わることを願っている。