ストーリー

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

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

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

graph LR
    A["push"] --> B["CI"]
    B --> C["ステージング<br/>自動"]
    C --> D["承認ゲート<br/>手動判断"]
    D --> E["本番デプロイ<br/>自動"]

    D -.- F["人間が判断<br/>「リリースして良いか？」"]

    classDef auto fill:#d4edda,stroke:#28a745,color:#000
    classDef manual fill:#fff3cd,stroke:#856404,color:#000
    class B,C,E auto
    class D,F manual

継続的デプロイ（Continuous Deployment）

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

graph LR
    A["push"] --> B["CI"]
    B --> C["ステージング<br/>自動"]
    C --> D["E2Eテスト<br/>自動"]
    D --> E["本番デプロイ<br/>自動"]

    E -.- F["完全自動化<br/>テスト通過 = 即リリース"]

    classDef auto fill:#d4edda,stroke:#28a745,color:#000
    class B,C,D,E auto

比較表

デプロイ戦略

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

1. ローリングデプロイ

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

graph TD
    subgraph T1 ["Time 1: 全てv1"]
        A1["v1"] ~~~ A2["v1"] ~~~ A3["v1"] ~~~ A4["v1"]
    end
    subgraph T2 ["Time 2: 1台ずつ更新"]
        B1["v2"] ~~~ B2["v1"] ~~~ B3["v1"] ~~~ B4["v1"]
    end
    subgraph T3 ["Time 3"]
        C1["v2"] ~~~ C2["v2"] ~~~ C3["v1"] ~~~ C4["v1"]
    end
    subgraph T4 ["Time 4"]
        D1["v2"] ~~~ D2["v2"] ~~~ D3["v2"] ~~~ D4["v1"]
    end
    subgraph T5 ["Time 5: 全てv2"]
        E1["v2"] ~~~ E2["v2"] ~~~ E3["v2"] ~~~ E4["v2"]
    end

    T1 --> T2 --> T3 --> T4 --> T5

    classDef old fill:#f8d7da,stroke:#dc3545,color:#000
    classDef new fill:#d4edda,stroke:#28a745,color:#000
    class A1,A2,A3,A4,B2,B3,B4,C3,C4,D4 old
    class B1,C1,C2,D1,D2,D3,E1,E2,E3,E4 new

2. Blue/Greenデプロイ

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

graph TD
    subgraph BEFORE ["切り替え前"]
        LB1["LB"] --> BLUE1["Blue (v1)<br/>現在"]
        LB1 -.- GREEN1["Green (v2)<br/>準備中"]
    end

    subgraph AFTER ["切り替え後"]
        LB2["LB"] --> GREEN2["Green (v2)<br/>現在"]
        LB2 -.- BLUE2["Blue (v1)<br/>待機"]
    end

    BEFORE --> AFTER

    classDef active fill:#d4edda,stroke:#28a745,color:#000
    classDef standby fill:#e2e3e5,stroke:#6c757d,color:#000
    classDef lb fill:#cce5ff,stroke:#004085,color:#000
    class BLUE1,GREEN2 active
    class GREEN1,BLUE2 standby
    class LB1,LB2 lb

3. カナリアデプロイ

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

graph TD
    subgraph P1 ["Phase 1: 5%のトラフィックを新バージョンへ"]
        LB1["LB"]
        LB1 -->|"95%"| V1A["v1 x4"]
        LB1 -->|"5%"| V2A["v2 x1<br/>少数で検証"]
    end

    subgraph P2 ["Phase 2: 問題なし → 50%に拡大"]
        LB2["LB"]
        LB2 -->|"50%"| V1B["v1 x2"]
        LB2 -->|"50%"| V2B["v2 x2"]
    end

    subgraph P3 ["Phase 3: 全体展開"]
        V2C["v2 x4"]
    end

    P1 --> P2 --> P3

    classDef old fill:#f8d7da,stroke:#dc3545,color:#000
    classDef new fill:#d4edda,stroke:#28a745,color:#000
    classDef lb fill:#cce5ff,stroke:#004085,color:#000
    class V1A,V1B old
    class V2A,V2B,V2C new
    class LB1,LB2 lb

戦略の選択指針

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

環境の段階構成

graph LR
    CI["CI成功"] --> DEV["Dev<br/>開発検証<br/>自動"]
    DEV --> STG["Staging<br/>本番同等<br/>自動"]
    STG --> PROD["Production<br/>本番環境<br/>承認後自動"]

    classDef dev fill:#cce5ff,stroke:#004085,color:#000
    classDef stg fill:#fff3cd,stroke:#856404,color:#000
    classDef prod fill:#d4edda,stroke:#28a745,color:#000
    class DEV dev
    class STG stg
    class PROD prod

各環境の役割:

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

ロールバック戦略

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

まとめ

チェックリスト

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

次のステップへ

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

推定読了時間: 20分