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

ストーリー

あなた

あ

佐

佐藤先輩

CI — Continuous Integration、継続的インテグレーションだ。これはCI/CDの土台になる考え方だから、しっかり押さえておこう

あなた

インテグレーション…統合ですか？

あ

佐

佐藤先輩

そうだ。開発者全員のコードを頻繁に統合（マージ）して、その都度自動でテストを走らせる。これだけで、うちのチームが抱えている問題の半分以上が解決する

あなた

半分以上…そんなに効果があるんですか？

あ

佐

佐藤先輩

マージの頻度が上がれば、コンフリクトは小さくなる。テストが自動で走れば、バグは早期に見つかる。地味だけど、これが開発チームの生産性を根本から変えるんだ

CIの基本原則

CIとは

継続的インテグレーション（CI）とは、開発者がコードの変更を頻繁にメインブランチに統合し、統合のたびに自動テストを実行することで、問題を早期に検出するプラクティスです。

CIの5つの原則

原則	説明
頻繁なマージ	最低でも1日1回はメインブランチにマージする
自動テスト	マージのたびに自動でテストスイートを実行する
即座のフィードバック	テスト結果を数分以内に開発者に通知する
ビルドの修復優先	ビルドが壊れたら最優先で修復する
全員の責任	CIの維持はチーム全員の責任である

CIがない世界 vs CIがある世界

CIがない場合：インテグレーション地獄

graph LR
    subgraph "週1回のマージ（CI なし）"
        MON["月曜"] --> FRI["金曜"]
        A["開発者A: 500行"] --> M1["マージ"]
        B["開発者B: 300行"] --> M2["マージ<br/>コンフリクト大量発生!"]
        C["開発者C: 400行"] --> M3["マージ<br/>さらにコンフリクト!"]
        M1 --> TEST["結合テスト"]
        M2 --> TEST
        M3 --> TEST
        TEST --> BUG["バグ大量発見<br/>→ 原因調査に時間がかかる<br/>→ リリース延期..."]
    end

    classDef conflict fill:#f8d7da,stroke:#dc3545,color:#000
    class M2,M3,BUG conflict

CIがある場合：小さな変更を頻繁にマージ

1日に複数回のマージ（CI あり）

 開発者A: 50行の変更 → push → 自動テスト OK → マージ
 開発者B: 30行の変更 → push → 自動テスト OK → マージ
 開発者A: 40行の変更 → push → 自動テスト NG → 即修正 → OK → マージ
 開発者C: 20行の変更 → push → 自動テスト OK → マージ

 → コンフリクトは小さく、バグは早期発見
 → リリースは予定通り

CIパイプラインの構成

典型的なCIパイプラインは以下のステージで構成されます。

graph TD
    PUSH["git push"]
    subgraph S1 ["Stage 1: コード品質チェック"]
        LINT["Lint<br/>(ESLint)"]
        FMT["Format<br/>(Prettier)"]
        TS["Type Check<br/>(TS)"]
    end
    subgraph S2 ["Stage 2: テスト実行"]
        UNIT["単体テスト<br/>(Jest)"]
        INT["結合テスト<br/>(Supertest)"]
    end
    subgraph S3 ["Stage 3: ビルド"]
        COMPILE["Compile<br/>(tsc)"]
        DOCKER["Docker<br/>Build"]
    end
    SUCCESS["ビルド成功!<br/>アーティファクト保存"]

    PUSH --> S1
    S1 -->|OK| S2
    S2 -->|OK| S3
    S3 -->|OK| SUCCESS

    classDef stage fill:#cce5ff,stroke:#004085,color:#000
    classDef ok fill:#d4edda,stroke:#28a745,color:#000
    class LINT,FMT,TS,UNIT,INT,COMPILE,DOCKER stage
    class SUCCESS ok

各ステージの詳細

Stage 1: コード品質チェック（1〜3分）

# ESLint でコードスタイルチェック
npx eslint src/ --ext .ts,.tsx

# Prettier でフォーマットチェック
npx prettier --check "src/**/*.{ts,tsx}"

# TypeScript の型チェック
npx tsc --noEmit

Stage 2: テスト実行（2〜10分）

# 単体テスト
npx jest --coverage

# 結合テスト
npx jest --config jest.integration.config.js

Stage 3: ビルド（3〜10分）

# TypeScript コンパイル
npx tsc

# Docker イメージビルド
docker build -t myapp:latest .

CIのフィードバックループ

CIの最大の価値は「素早いフィードバック」です。

graph TD
    A["コード変更"] --> B["push"]
    B --> C["CI実行"]
    C --> D["結果通知"]
    D -->|"数分で結果がわかる"| A

    D --> E["成功<br/>マージ可能"]
    D --> F["失敗<br/>修正してre-push<br/>失敗箇所が明確<br/>小さな変更なので<br/>原因特定が容易"]

    classDef ok fill:#d4edda,stroke:#28a745,color:#000
    classDef ng fill:#f8d7da,stroke:#dc3545,color:#000
    class E ok
    class F ng

フィードバックの通知方法

方法	ツール例	特徴
GitHub PR ステータスチェック	GitHub Actions	PRに直接結果が表示される
Slack 通知	Slack Integration	チーム全体に共有
メール通知	GitHub Notifications	個人に直接通知
ダッシュボード	Grafana, DataDog	チーム全体の状態を可視化

CIのアンチパターン

よくある失敗パターンを把握しておきましょう。

アンチパターン	問題	対策
遅いCIパイプライン	フィードバックが遅く開発が停滞	10分以内を目標にする
テストが不安定（Flaky）	同じコードで成功/失敗が変わる	不安定なテストを特定し修正する
ビルド失敗の放置	壊れたまま新しい変更が積まれる	「ビルド修復は最優先」ルールを徹底
大きなPR	変更が大きくレビューもテストも困難	小さなPRに分割する
テストなしのCI	CIがあっても品質が保証されない	テストカバレッジの基準を設ける

まとめ

ポイント	内容
CIとは	コードを頻繁にマージし、自動テストで品質を担保するプラクティス
核心	小さな変更を頻繁にマージすることでリスクを小さくする
フィードバック	テスト結果を数分以内に開発者に返す
アンチパターン	遅いCI、Flakyテスト、ビルド失敗の放置は要注意

チェックリスト

CIの5つの原則を説明できる
CIがない場合の問題点を理解した
CIパイプラインの典型的なステージ構成を把握した
CIのアンチパターンを3つ以上挙げられる

次のステップへ

次のセクションでは、CI/CDの「CD」の部分 — 継続的デリバリー/デプロイの概念を学びます。 CIで品質を担保したコードを、いかに安全に本番環境へ届けるかを理解しましょう。

推定読了時間: 20分