CI/CDの全体像

ストーリー

ある月曜日の朝、チームのSlackチャンネルにアラートが飛んだ。

「本番環境のデプロイに失敗しました。手動でロールバックが必要です」

DevOpsエンジニアの木村先輩が、深いため息をつきながらやってきた。

「また手動デプロイのミスか......。先月から3回目だ。そろそろ本気で自動化しないとまずい」

「自動化......ですか？」

木村先輩は頷いた。

「CI/CDパイプラインを構築する。コードをpushしたら、テスト、ビルド、デプロイまで全自動で走る仕組みだ。今月のミッションは、この自動化パイプラインをゼロから構築することだ。まずはCI/CDの全体像から理解していこう」

CI/CDとは何か

CI/CDとは、ソフトウェア開発における「継続的インテグレーション（CI）」と「継続的デリバリー/デプロイ（CD）」の総称です。コードの変更からデプロイまでのプロセスを自動化し、高品質なソフトウェアを迅速にリリースすることを目指します。

手動デプロイの問題点

従来の手動デプロイフロー

開発者       テスト担当      運用担当
  │              │              │
  │  コード完成   │              │
  ├──────→│              │
  │        │  手動テスト    │
  │        │  (2〜3日)     │
  │        ├──────→│
  │        │        │  手動デプロイ
  │        │        │  (半日〜1日)
  │        │        │
  │     問題発見!   │
  │←──────┤              │
  │  修正して再提出  │              │
  │  (さらに数日...)  │              │

問題	影響
ヒューマンエラー	デプロイ手順のミスでサービス障害
長いリードタイム	コード完成からリリースまで数日〜数週間
テストの漏れ	手動テストでは全パターンを網羅できない
再現性の欠如	「この前はうまくいったのに」問題
属人化	特定の人しかデプロイできない

CI/CDパイプラインの全体像

CI/CDパイプラインは、コードの変更が本番環境に届くまでの一連の自動化されたプロセスです。

CI/CDパイプライン全体像

  [コード変更]                    CI                              CD
      │        ┌──────────────────────────┐  ┌─────────────────────────┐
      │        │                            │  │                         │
      ▼        │  ┌─────┐  ┌─────┐  ┌────┐│  │ ┌────┐  ┌────┐  ┌────┐│
  git push ──→│  │Lint  │→│Test  │→│Build││→│ │Stg  │→│承認 │→│Prod ││
              │  │検査  │  │テスト│  │構築 ││  │ │Deploy│  │Gate│  │Deploy││
              │  └─────┘  └─────┘  └────┘│  │ └────┘  └────┘  └────┘│
              │                            │  │                         │
              └──────────────────────────┘  └─────────────────────────┘
                   失敗したら即座にフィードバック        段階的にリリース

パイプラインの各ステージ

ステージ	役割	実行時間目安
Lint/静的解析	コードスタイルや潜在的バグの検出	1〜3分
単体テスト	個々の関数やモジュールの動作確認	2〜5分
結合テスト	複数モジュールの連携確認	5〜15分
ビルド	アプリケーションのコンパイル/パッケージング	3〜10分
ステージングデプロイ	本番同等環境でのデプロイ検証	5〜15分
E2Eテスト	エンドツーエンドでの動作検証	10〜30分
本番デプロイ	実際のユーザーへのリリース	5〜15分

CI/CDがもたらす変化

Before: 手動運用

リリースサイクル: 月1回
デプロイ所要時間: 半日
デプロイ失敗率: 20%
障害復旧時間: 2〜4時間

After: CI/CD導入後

リリースサイクル: 1日に複数回
デプロイ所要時間: 15分
デプロイ失敗率: 2%
障害復旧時間: 15分（自動ロールバック）

DORA メトリクス

DevOps Research and Assessment（DORA）が定義する4つのキー指標で、CI/CDの効果を測定できます。

メトリクス	説明	エリートチームの基準
デプロイ頻度	どのくらいの頻度でリリースするか	1日に複数回
リードタイム	コミットからデプロイまでの時間	1時間未満
変更失敗率	デプロイが障害を引き起こす割合	0〜15%
復旧時間	障害からの復旧にかかる時間	1時間未満

CI/CDの適用範囲

CI/CDはアプリケーションコードだけでなく、幅広い領域に適用できます。

CI/CDの適用範囲

┌─────────────────────────────────────┐
│             CI/CD パイプライン         │
│                                       │
│  ┌──────────┐  ┌──────────┐          │
│  │アプリコード │  │インフラコード│          │
│  │(Node.js等) │  │(Terraform) │          │
│  └──────────┘  └──────────┘          │
│                                       │
│  ┌──────────┐  ┌──────────┐          │
│  │設定ファイル  │  │ドキュメント │          │
│  │(k8s manifest)│  │(API docs)  │          │
│  └──────────┘  └──────────┘          │
│                                       │
│  ┌──────────┐  ┌──────────┐          │
│  │DB マイグレーション│  │セキュリティ  │          │
│  │(SQL/ORM)  │  │ポリシー     │          │
│  └──────────┘  └──────────┘          │
└─────────────────────────────────────┘

今月は特に「アプリケーションコードのCI/CD」と「インフラコード（IaC）のCI/CD」に焦点を当てて学びます。

まとめ

ポイント	内容
CI/CDとは	コード変更からデプロイまでを自動化する仕組み
手動の問題	ヒューマンエラー、長いリードタイム、属人化
パイプライン	Lint → テスト → ビルド → デプロイの一連の自動化プロセス
効果測定	DORAメトリクスで定量的に評価できる

チェックリスト

CI/CDの目的と手動デプロイの問題点を説明できる
パイプラインの各ステージの役割を理解した
DORAメトリクスの4つの指標を挙げられる

次のステップへ

次のセクションでは、CI/CDの「CI」の部分 -- 継続的インテグレーションの概念を深掘りします。なぜ「頻繁にマージする」ことが品質向上につながるのか、その仕組みを理解しましょう。

推定読了時間: 20分