サンプルコードで身につける: CIで品質を自動チェック — mainを守る門番を立てる

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

1最小のGitHub Actionsワークフロー

リポジトリに.github/workflows/ci.ymlを置くだけで、pushのたびに検査が自動実行されます。まずはlintだけの最小構成から始めて、動くことを確認してからステップを足していくのが確実です。

# .github/workflows/ci.yml — まずは lint だけの最小構成
name: CI
on: [push, pull_request]   # push と PR のたびに実行

jobs:
  lint:
    runs-on: ubuntu-latest # GitHub が用意する Linux 上で実行
    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            # 検査を実行

2CIで動くテストコマンドにする

ng testは既定では監視モードで起動し、終了しないためCIでは使えません。--watch=falseで一度だけ実行し、ヘッドレスブラウザを指定するのがCI用の定番の形です。npm scriptsに登録しておくと便利です。

# 手元用: 監視モードで起動し、変更のたびに再実行される(終了しない)
ng test

# CI 用: 一度だけ実行して終了する。画面のないブラウザを使う
ng test --watch=false --browsers=ChromeHeadless

# package.json に CI 用コマンドとして登録しておくと呼びやすい
#   "scripts": {
#     "test:ci": "ng test --watch=false --browsers=ChromeHeadless"
#   }

3npm ciを使う — CIでの依存インストール

CIではnpm installではなくnpm ciを使います。package-lock.jsonの内容をそのまま再現するので、実行のたびにバージョンがずれる事故がなく、全員と同じ依存で検査できます。

# npm install — 手元での開発用
#   package.json の範囲内で依存を解決し、lock ファイルを更新することもある
npm install

# npm ci — CI 用
#   ・package-lock.json の内容を完全に再現する
#   ・node_modules を一度削除してから入れ直す
#   ・lock ファイルと package.json が食い違っていたらエラーで止まる
npm ci

# => 「実行するたびに依存が微妙に違う」を防ぎ、検査結果が安定する

4lint・test・buildを揃えた実用形

最小構成が動いたら、テストとビルドのステップを足して門番を完成させます。ステップは上から順に実行され、途中で失敗するとその時点で赤いバツになります。並び順は速く終わるものを先にするのが定石です。

# .github/workflows/ci.yml — lint・test・build を揃えた実用形
name: CI
on: [push, pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm          # node_modules のキャッシュで2回目以降を高速化
      - run: npm ci
      - run: npm run lint     # 1. 速い検査を先に
      - run: npm run test:ci  # 2. テスト
      - run: npm run build    # 3. 最後にビルド確認
      # どこかで失敗すると以降は実行されず、PR に赤いバツが付く

5ブランチ保護 — 検査が通るまでマージさせない

CIを門番として機能させる仕上げが、GitHubのブランチ保護設定です。mainへの直接pushを禁止し、CIの成功をマージの必須条件にすると、壊れた変更は仕組みとして入らなくなります。

# GitHub のブランチ保護でよく使う設定(リポジトリの Settings → Branches)
#
#   ・Require a pull request before merging
#       → main への直接 push を禁止し、必ず PR を経由させる
#   ・Require status checks to pass
#       → CI(例: check ジョブ)の成功をマージの必須条件にする
#
# これで開発の流れはこうなる:
#   ブランチで作業 → push → CI が自動実行
#     → 緑のチェック + レビュー承認 → マージできる
#     → 赤いバツ → 直して push し直すまでマージできない
#   → main は「常にCIが通った状態」に保たれる