継続的デリバリー/デプロイ（CD）

ストーリー

「CIでコードの品質は自動で確認できるようになった。次は、その品質が保証されたコードをどうやって本番環境に届けるかだ」

木村先輩がホワイトボードに「CD」と書き足した。

「CDには2つの意味がある。Continuous Delivery（継続的デリバリー）と Continuous Deployment（継続的デプロイ）だ」

「似てるけど違うんですか？」

「大きな違いがある。デリバリーは『いつでもリリースできる状態を保つ』、デプロイは『テストが通ったら自動でリリースまでする』だ。どちらを選ぶかは、チームとプロダクトの状況次第だ」

継続的デリバリー vs 継続的デプロイ

継続的デリバリー（Continuous Delivery）

テストに通ったコードを「いつでもリリース可能な状態」に保つプラクティスです。本番へのデプロイは手動承認を経て実行します。

継続的デリバリー

[push] → [CI] → [ステージング] → [承認ゲート] → [本番デプロイ]
                   自動           手動判断         自動
                                 ↑
                              人間が判断
                          「リリースして良いか？」

継続的デプロイ（Continuous Deployment）

テストに通ったコードが自動的に本番環境にデプロイされるプラクティスです。人間の承認を必要としません。

継続的デプロイ

[push] → [CI] → [ステージング] → [E2Eテスト] → [本番デプロイ]
                   自動            自動            自動
                                               ↑
                                          完全自動化
                                    テスト通過 = 即リリース

比較表

観点	継続的デリバリー	継続的デプロイ
本番デプロイ	手動承認後	完全自動
リリース判断	ビジネス判断を含む	テスト結果のみ
求められるテスト品質	高い	非常に高い
向いている場面	規制産業、初期導入段階	成熟したチーム、SaaS
デプロイ頻度	日〜週単位	1日に複数回

デプロイ戦略

CDを実現するためには、安全にデプロイするための戦略が重要です。

1. ローリングデプロイ

古いバージョンのインスタンスを順次新しいバージョンに置き換えます。

ローリングデプロイ

Time 1:  [v1] [v1] [v1] [v1]     ← 全てv1
Time 2:  [v2] [v1] [v1] [v1]     ← 1台ずつ更新
Time 3:  [v2] [v2] [v1] [v1]
Time 4:  [v2] [v2] [v2] [v1]
Time 5:  [v2] [v2] [v2] [v2]     ← 全てv2

メリット	デメリット
ダウンタイムなし	一時的にv1/v2が混在
リソース効率が良い	ロールバックに時間がかかる

2. Blue/Greenデプロイ

本番環境（Blue）と全く同じ環境（Green）を用意し、一括切り替えます。

Blue/Green デプロイ

         ┌───── LB ─────┐
         │               │
    ┌────▼────┐    ┌─────────┐
    │  Blue    │    │  Green   │
    │  (v1)    │    │  (v2)    │
    │ [現在]   │    │ [準備中] │
    └─────────┘    └─────────┘

        切り替え後 ↓

         ┌───── LB ─────┐
         │               │
    ┌─────────┐    ┌────▼────┐
    │  Blue    │    │  Green   │
    │  (v1)    │    │  (v2)    │
    │ [待機]   │    │ [現在]   │
    └─────────┘    └─────────┘

メリット	デメリット
瞬時の切り替え	2倍のリソースが必要
瞬時のロールバック	コストが高い

3. カナリアデプロイ

新バージョンを一部のユーザーにだけ公開し、問題がないことを確認してから全体に展開します。

カナリアデプロイ

Phase 1: 5%のトラフィックを新バージョンへ
  ┌────────────── LB ──────────────┐
  │  95%           │            5% │
  ▼                               ▼
[v1] [v1] [v1] [v1]            [v2]
                              ← 少数で検証

Phase 2: 問題なし → 50%に拡大
  ┌────────────── LB ──────────────┐
  │  50%                       50% │
  ▼                               ▼
[v1] [v1]                  [v2] [v2]

Phase 3: 全体展開
  ▼
[v2] [v2] [v2] [v2]

メリット	デメリット
リスクが最小	段階的で時間がかかる
実トラフィックで検証	ルーティング設定が複雑

戦略の選択指針

状況	推奨戦略
シンプルなWebアプリ	ローリングデプロイ
ダウンタイムゼロ必須	Blue/Green
大規模ユーザー基盤	カナリア
初めてのCI/CD導入	ローリングデプロイ

CDパイプラインの実装パターン

環境の段階構成

CDパイプライン環境構成

[CI成功] → [Dev] → [Staging] → [Production]
             │         │            │
          開発検証   本番同等     本番環境
          自動      自動        承認後自動

各環境の役割:
- Dev:       機能確認、開発者のみアクセス
- Staging:   本番と同じ構成でのリリース検証
- Production: エンドユーザーがアクセスする環境

ロールバック戦略

デプロイ後に問題が発生した場合の復旧計画も重要です。

ロールバック方式	説明	復旧時間
前バージョンの再デプロイ	1つ前のバージョンをデプロイし直す	5〜15分
Blue/Green切り戻し	トラフィックを旧環境に戻す	数秒〜1分
Feature Flag無効化	問題の機能のフラグをOFFにする	数秒
DB マイグレーション考慮	DBスキーマ変更の互換性を保つ	ケースによる

まとめ

ポイント	内容
継続的デリバリー	いつでもリリース可能な状態を保つ（承認後デプロイ）
継続的デプロイ	テスト通過で自動的に本番デプロイ
デプロイ戦略	ローリング、Blue/Green、カナリアの3種類
ロールバック	デプロイ前にロールバック手順を必ず用意する

チェックリスト

継続的デリバリーと継続的デプロイの違いを説明できる
3つのデプロイ戦略の特徴とメリット/デメリットを理解した
環境の段階構成（Dev → Staging → Production）を把握した
ロールバック戦略の重要性を理解した

次のステップへ

CI/CDの概念が固まったところで、次のセクションでは代表的なCI/CDツールを比較します。その中から、今月メインで使うGitHub Actionsの位置づけを理解しましょう。

推定読了時間: 20分