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

継続的インテグレーション（CI）とは、開発者が小さな変更をメインブランチへ頻繁にマージし、プッシュやプルリクエストのたびにサーバーがコードをビルドして自動テストを実行することです。目的は素早いフィードバックです。変更が何かを壊した場合、数日後の大規模なマージのときではなく、変更内容がまだ記憶に新しいうちに作成者が気付けます。

具体例（GitHub Actions）

すべてのプルリクエストと main へのプッシュでテストスイートを実行する最小限のパイプラインです。

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

npm test が 0 以外の終了コードで終わるとジョブは失敗し、プルリクエストには赤いチェックが表示されます。このチェックを必須にするブランチ保護と組み合わせれば、壊れたコードはマージできなくなります。

CI でテスターが担うこと

• どのテストをどこで実行するか。 高速なユニットテストと API テストはすべてのプルリクエストで、時間のかかる E2E スイートはマージ時や定期実行で回します。40 分かかるプルリクエストのパイプラインは、やがて使われなくなります。
• シグナルの品質。 ブロッキングジョブにフレーキーテストがあると、皆が「再実行」をクリックする癖が付きます。フレーキーなテストは隔離し、赤いビルドが常に意味を持つようにします。
• 成果物（アーティファクト）。 失敗した実行のレポート、トレース、スクリーンショットを公開し、失敗を見るためだけにローカルで再現する必要がないようにします。
• 並列化。 長いスイートを複数のマシンにシャーディングすれば、スイートが大きくなってもフィードバック時間を一定に保てます。

CD との違い

継続的デリバリーは CI を拡張したもので、合格したすべてのビルドがパッケージ化され、通常はステージング環境を経由して、いつでもリリースできる状態に保たれます。継続的デプロイはさらに一歩進み、合格したすべての変更を自動で本番環境へリリースします。CI はその両方の土台です。コミットごとに信頼できるテストスイートがなければ、どちらも安全ではありません。

よくある間違い

CI を夜間にしか実行しない、メインブランチを何日も赤いままにしておく、パイプラインをテストを実行する場所ではなくテストを書く場所として扱う、といったことです。CI はツールであると同時にチームの習慣でもあります。小さくマージし、ビルドが壊れたら修正するか差し戻します。