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)の目的として最も適切なものはどれか?