女性向けエンジニアスクール
3秒でわかる
コードの変更をきっかけにテストとビルドと配布を自動で走らせる仕組み。人手の確認漏れを減らし、小さな変更を安全に何度も本番へ出すために使われます。
30秒図解
もう少し詳しく
どういうものか
CI は継続的インテグレーション (Continuous Integration) の略で、変更を頻繁に共有ブランチへ取り込み、そのたびに自動でビルドとテストを走らせる進め方を指す。CD は継続的デリバリー (Continuous Delivery) または継続的デプロイメント (Continuous Deployment) の略で、テストを通った成果物をいつでも出せる状態に保つ、あるいはそのまま自動で本番へ出す進め方を指す。
実体は、リポジトリへの push や pull request をきっかけに動くワークフローである。GitHub Actions、GitLab CI、CircleCI などが実行基盤になる。
なぜ必要か
手作業のリリース手順は、回数を重ねるほど抜けが出る。テストを流し忘れる、ビルド前に依存を更新し忘れる、本番の環境変数だけ古い、といった失敗はどれも「毎回同じ手順を人が繰り返す」ことに起因する。
自動化の効果は時間短縮より、失敗の検知が早くなる点にある。壊れたコードは統合の直後に落ちるので、原因となる変更が 1 つに絞れる。1 週間分をまとめて統合して落ちた場合、どの変更が原因かを探すところから始まる。
具体例
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
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 run lint
- run: npm test -- --run
- run: npm run buildpull request を出すたびにこの 4 つが走り、1 つでも失敗すればマージできない状態にできる。
つまずきやすいところ
不安定なテスト (実行するたびに結果が変わるテスト) を放置すると、赤くなっても再実行で通してしまう習慣が付き、本物の失敗まで見逃す。時刻や外部 API に依存するテストは固定値に置き換える。
もう 1 つ、CI 上の秘密情報の扱いである。API キーはリポジトリに書かず、GitHub Actions の Secrets のような仕組みに預ける。fork からの pull request には Secrets を渡さない設定が既定であることも把握しておく。
似た用語との違い
| 語 | 何をどこまでやるか |
|---|---|
| 継続的インテグレーション | 変更のたびにビルドとテストを自動実行する |
| 継続的デリバリー | いつでも本番へ出せる成果物を用意する。最後の実行は人が押す |
| 継続的デプロイメント | テストが通ったらそのまま本番へ自動で出す |
| DevOps | 開発と運用を通して回す考え方全体。CI/CD はその一部の実践 |
