104. CIで品質を自動チェック — mainを守る門番を立てる

CI(継続的インテグレーション)は、コードをpushするたびにlint・test・buildなどの検査をサーバー上で自動実行する仕組みです。GitHub Actionsなら、リポジトリに .github/workflows/ci.yml を1枚置くだけで動き始めます。検査の結果は、プルリクエストの画面に緑のチェックや赤のバツで表示されます。

チーム開発でのCIは、壊れた変更をmainブランチに入れない門番の役割を果たします。「自分の環境では動いた」は通用せず、全員のコードが同じ環境・同じ手順で検査されます。ブランチ保護と組み合わせれば、検査が通らない限りマージできないルールを機械的に強制でき、mainが常に動く状態を保てます。

初学者の落とし穴は、CIの失敗を放置してしまうことです。赤いバツが常態化すると誰も結果を見なくなり、CIは形骸化します。失敗したらログを開き、まず手元で同じコマンドを実行して再現させるのが基本の直し方です。push前に手元でlintとtestを走らせる習慣をつけると、CIの失敗自体が減ります。

サンプルコード(フレームワーク環境が必要なため表示のみ)

# .github/workflows/ci.yml — push のたびに品質チェックを自動実行する最小例
name: CI
on: [push, pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4        # コードを取得
      - uses: actions/setup-node@v4      # Node.js を用意
        with:
          node-version: 22
          cache: npm
      - run: npm ci                      # 依存を再現性のある方法で入れる
      - run: npm run lint                # 検査
      - run: npm test -- --watch=false --browsers=ChromeHeadless  # 検証
      - run: npm run build               # ビルドが通るか確認

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗