女性向けエンジニアスクール
3秒でわかる
変更をこまめに共有ブランチへ統合し、そのたびに自動でビルドとテストを回す進め方。壊れた箇所をその日のうちに見つけられます。
もう少し詳しく
どういうものか
CI は Continuous Integration の略で、日本語では継続的インテグレーションと呼びます。各自の変更を長く手元に留めず、1日1回以上の頻度で共有ブランチへ統合し、統合のたびに自動でビルドとテストを実行する進め方です。
実体としては、リポジトリへの push や Pull Request の作成をきっかけに、決められた手順を自動で走らせる仕組みになります。GitHub Actions、GitLab CI、Jenkins などがその実行役です。
なぜ必要か
各自が2週間分の変更を手元に抱えたまま最後にまとめて統合すると、衝突の解消と不具合の切り分けが同時に襲ってきます。どの変更が壊したのかを特定するには、2週間分の差分を疑うことになります。
こまめに統合していれば、壊れた瞬間に通知が来て、疑う範囲は直前の1コミットに絞られます。修正のコストは、原因の混入から発見までの時間にほぼ比例して増えます。CI はこの時間を短くするための仕掛けです。
レビューの質も変わります。動くかどうかの確認が自動で済むため、人は設計や読みやすさに時間を使えます。
具体例
name: test
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm run lint
- run: npm testこのファイルをリポジトリに置くだけで、push のたびに依存のインストール、静的検査、テストが自動で走ります。失敗すると Pull Request に赤い印が付き、そのままマージできない設定にもできます。
つまずきやすいところ
手元では通るのに CI で落ちる、という食い違いは大半が環境差です。依存の版がロックファイルで固定されていない、環境変数が設定されていない、タイムゾーンや文字コードが違う、といったあたりが原因の上位です。差が出た時点で手元を CI に合わせておくと、以後の調査が短くなります。
実行が10分を超えると、結果を待たずに次の作業へ移り、赤いままの状態が放置され始めます。遅いテストは並列化するか、重いものだけ夜間実行へ回します。
不安定に落ちるテストも危険です。再実行で通ることが続くと、本物の失敗まで再実行で流されます。
似た用語との違い
CI は統合と検証まで、CD (継続的デリバリー / デプロイ) はその先の配布や本番反映までを指します。まず CI を安定させ、それから CD を足すのが順序です。
