CI/CD（継続的インテグレーション/デリバリー）

なぜ要るのか：手動の何が問題か

機能ごとに長く別ブランチで作業し、リリース直前にまとめて統合・手作業でデプロイする——昔ながらのやり方には、はっきりした痛みがあります。

• 統合が遅れるほど衝突が爆発する：別々に書いたコードを後でまとめると、競合の解決に何日もかかる（いわゆる「マージ地獄」）。
• 手順書頼みのデプロイは事故る：「設定ファイルを書き換え忘れた」「順番を間違えた」が本番障害に直結する。再現性がない。
• テストが後回しになる：人手でしか確認しないと、リリース前にまとめて手動テスト → 時間切れで省略 → バグが本番へ。
• 属人化する：「あの人しかデプロイできない」状態は、休暇や退職で一気にリスクになる。

CI/CD はこれらを 「機械が毎回・同じ手順で実行する」 ことで潰します。人間は判断に集中し、繰り返し作業と確認は自動化に任せる、という発想です。

CI：継続的インテグレーション

CI（Continuous Integration）は、各開発者の変更を一日に何度も共有ブランチ（main など）へ統合 し、そのたびに自動で検証する習慣と仕組みです。

• 小さく頻繁にマージ：変更が小さいうちに統合するので、衝突も小さく済む。
• プッシュ/PR をトリガーに自動実行：ビルド → 静的解析（lint）→ 自動テスト（単体・結合）を機械が回す。
• 失敗したら即フィードバック：壊した本人が、壊した直後に気づける（数日後ではなく数分後）。
• main を常に「グリーン」に保つ：テストが通った変更だけが取り込まれる。

→ ねらいは「統合の痛みを毎回ちょっとずつ払う」こと。CI の本質はツールより、ブランチを長生きさせず頻繁に統合する文化 にあります。

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

CD は CI の先を引き継ぎ、テストを通った成果物を、自動で次の環境へ運ぶ 部分です。CD には紛らわしい2つの意味があります。

• 継続的デリバリー（Continuous Delivery）：本番の 直前まで全自動。ステージングへの配置・受け入れテストまで自動で進み、本番反映だけ人間がボタンを押す（リリースのタイミングを人が決める）。
• 継続的デプロイ（Continuous Deployment）：本番まで全自動。テストが全て通れば、承認を挟まず自動で本番へ 出る。

どちらも「いつでも安全に出せる状態（リリース可能な成果物）を保つ」点は同じで、最後の本番反映を手動にするか／自動にするか が違いです。

パイプライン：流れを自動化する

CI/CD の実体は パイプライン——「コードが本番に届くまでの一連の工程を、段階（ステージ）に分けて自動実行する流れ」です。前のステージが成功したら次へ進み、どこかで失敗すれば そこで止めて知らせる（壊れたものを先へ進めない）。

典型的なステージはこんな並びです。

push / PR ──▶ ビルド ──▶ テスト ──▶ パッケージ化 ──▶ ステージング配置 ──▶ （承認）──▶ 本番デプロイ
              └─ ここまでが CI ─┘   └──────────── ここからが CD ────────────┘

GitHub Actions ならワークフローを YAML で宣言します（「push されたら、Ubuntu 上で依存解決 → テスト」という最小例）。

name: CI
on: [push, pull_request]   # いつ動かすか（トリガー）
jobs:
  test:
    runs-on: ubuntu-latest # どこで動かすか（実行環境）
    steps:
      - uses: actions/checkout@v4   # コードを取得
      - run: npm ci                 # 依存をインストール
      - run: npm test               # テストを実行（失敗すれば赤になる）

ポイントは、この定義が リポジトリにコードとして入っていること。手順書ではなくコードなので、誰が実行しても同じ結果になり（再現性）、変更履歴も残ります。これは Infrastructure as Code（IaC） と同じ「手順をコード化する」発想です。

つまずきポイント

実運用で効きにくくなる典型パターンを押さえておきましょう。

• 遅すぎるパイプライン：1回30分かかると、開発者は回すのを嫌がり頻度が落ちる。キャッシュ・並列実行・テスト分割で 速さ＝フィードバックの早さ を守る。
• 不安定なテスト（flaky test）：実行のたびに結果が変わるテストは、「どうせまた失敗」と赤信号を無視させる元凶。早めに隔離・修正する。
• デプロイ＝リリースと思い込む：本番に出す（デプロイ）ことと、ユーザーに機能を見せる（リリース）ことは分離できる。フィーチャーフラグで「出してあるが、まだ無効」が可能。
• 切り戻しを用意していない：全自動で出すなら、安全に戻せること が前提。どう出すか（段階公開など）は デプロイ戦略 で、何を見て異常を判断するかは オブザーバビリティ で支える。

どこから始める？

• まず CI から：テストを自動化し、PR ごとに必ず回るようにする。これだけで品質と速度が大きく変わる。
• 次に 継続的デリバリー：ステージングまで自動化し、本番は手動承認で安全に。
• 自動テストと監視・切り戻しが整ってきたら 継続的デプロイ へ。承認を外し、小さな変更を高頻度で本番へ。

具体的なツールの動かし方は GitHub Actions を入り口にするとイメージしやすいです。まずは「テストを自動で1回回す」——その小さな一歩が CI/CD の出発点になります。