CI/CD レッスン1

継続的インテグレーションの基本

変更を頻繁に統合しビルド・テストを自動化する継続的インテグレーション(CI)の目的と仕組みを学ぶ

CIが解決する問題

複数人が長期間ブランチを分けたまま開発を続けると、統合(マージ)する段階で 大量のコンフリクトや想定外の不具合が発生しがちです。継続的インテグレーション(CI)は、 各自の変更を頻繁にmain(共有ブランチ)へ統合し、 そのたびに自動でビルド・テストを実行することで、問題を小さいうちに検出する考え方です。

CIがない場合

  • • 統合のタイミングで大きなコンフリクトが発生する
  • • 問題の発見が数週間後、リリース直前になる
  • • 「動くこと」の確認が手動レビューだけに依存する

CIがある場合

  • • 変更のたびに自動テストが走り、即座に問題が分かる
  • • 差分が小さいうちに統合するのでコンフリクトが小さい
  • • 「テストが通っている」という客観的な事実で品質を判断できる

最小限のCIワークフロー例

プルリクエストが作成・更新されるたびに、依存関係のインストール・型チェック・テストを自動実行する例です。

# ① .github/workflows/ci.yml
name: CI
on:
  pull_request:
    branches: [main]

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

このワークフローが緑(成功)にならない限りマージできないようブランチ保護ルールを設定することで、 「テストが通っているコードだけがmainに入る」状態を機械的に強制できます。

CIを機能させるための習慣

  • • ブランチの寿命を短くし、こまめにmainへ統合する(トランクベース開発に近づける)
  • • ビルドが壊れたら最優先で直す(「赤いまま放置」を許容しない文化を作る)
  • • テストの実行時間を意識し、遅くなりすぎたら並列化やテストピラミッドの見直しを行う

ポイント

  • • CIは変更を頻繁に統合し、自動テストで問題を早期発見する仕組み
  • • ブランチ保護と組み合わせ、テストが通ったコードだけmainに入る状態を作る
  • • 差分を小さく保つことでコンフリクトも小さくなる
  • • ビルドが壊れたら最優先で修正する文化が前提になる

確認クイズ

1 / 3

継続的インテグレーション(CI)の目的として最も適切なものはどれか?