CI/CDとは・パイプライン｜クラウドインフラ

← クラウドインフラ一覧

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：Dockerイメージとレイヤ　|　関連：デプロイ戦略（ローリング・ブルーグリーン・カナリア）・GitOpsと自動化

要点（BLUF）

CI（継続的インテグレーション）＝コードを頻繁に統合し、毎回自動でビルド＆テストして壊れを早期に見つける。CD は2つの意味——継続的デリバリ（いつでも出せる状態に）と継続的デプロイ（自動で本番へ）。
パイプライン＝コミットを起点に「ビルド → テスト → イメージ作成 → デプロイ」を自動で順に流す仕組み。各段は前段の成功が条件。
価値は「速く・安全に・繰り返し届ける」こと。リリースを小さく頻繁にし、1回あたりの риスクを下げる。

概念 ── CI と CD

CI は「統合の痛みを毎日に分散する」発想。各自が長くブランチを抱えると、最後の合流（マージ）が地獄になる。だからこまめに統合し、そのたびに自動テストして、壊れを小さいうちに潰します。

CD は CI の先。

継続的デリバリ：テストを通った成果物を「いつでも本番に出せる状態」に保つ。最後のボタンは人が押す。
継続的デプロイ：そのボタンすら自動。テストを通れば自動で本番へ。

flowchart LR
    commit["git push（コミット）"] --> ci["CI: ビルド＋テスト"]
    ci --> art["イメージ作成・登録"]
    art --> deliv["継続的デリバリ: いつでも出せる状態"]
    deliv -->|"人が承認"| prod1["本番デプロイ"]
    deliv -->|"自動（継続的デプロイ）"| prod2["本番デプロイ"]

仕組み ── パイプラインの段

パイプラインは段（stage/job）の連なり。前段が成功したら次段へ進み、どこかで失敗すれば止まって通知します。典型構成：

flowchart LR
    s1["lint（静的チェック）"] --> s2["test（自動テスト）"]
    s2 --> s3["build（イメージ作成：3章）"]
    s3 --> s4["push（レジストリ登録）"]
    s4 --> s5["deploy（K8s/IaC へ：4・5章）"]

3章のイメージ作り（Dockerイメージとレイヤ）のレイヤキャッシュがここで効きます。依存を先・コードを後にしておくと CI のビルドが速い。

動く例 ── GitHub Actions の最小ワークフロー

push をトリガに lint→test→build を流す例（YAML・要最新確認のアクション版）。

# .github/workflows/ci.yml
name: ci
on:
  push:
    branches: [ main ]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Python セットアップ
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: 依存インストール
        run: pip install -r requirements.txt
      - name: テスト
        run: pytest -q
      - name: Docker イメージをビルド
        run: docker build -t myapp:${{ github.sha }} .

ポイントは トリガ（on）・ジョブ・ステップの3要素。push で起動し、ステップを上から実行、どれかが失敗すれば赤くなって止まる。${{ github.sha }} でコミットごとに一意なイメージタグを付ける（latest を避ける＝Dockerイメージとレイヤ）。

なぜ自動化するのか

早く失敗するため：壊れはコミット直後に分かるのが一番安い。本番で気づくと修正コストが跳ね上がる。
属人性を消すため：「○○さんしかデプロイできない」を無くす。手順がコード（ワークフロー）になり、誰でも・いつでも同じ品質で出せる。
小さく頻繁に出すため：1回の変更が小さいほど、壊れたとき原因の切り分けが速くロールバックも軽い（デプロイ戦略（ローリング・ブルーグリーン・カナリア））。これが DORA の高頻度・低失敗率（DevOps文化とDORA 4指標）につながる。

⚠️ よくある誤解・落とし穴

「テストが無いCI」→ ビルドが通るだけでは品質を担保しない。自動テストがCIの心臓。
「秘密情報をワークフローに平文」→ トークン・鍵はリポジトリのシークレット機能で注入。ログに出さない（マスキング）。デプロイ鍵は用途限定（パッケージとユーザー・SSH）。
「latest タグでデプロイ」→ 何が動いているか不明に。コミットSHA等で一意タグ。
「mainに直接pushしてCIを回す文化」→ レビュー無しが常態化。PR＋必須チェックで品質ゲートを。
「CIが遅いまま放置」→ 遅いと回さなくなり形骸化。キャッシュ・並列化・テスト分割で短く保つ。

対応ラボ

cloud-infra-study/labs/06-01_ci.yml（push で lint→test→build を流す GitHub Actions ワークフロー雛形。リポジトリの .github/workflows/ に置いて動作確認）。