全部を毎回走らせない
品質チェックは重要です。しかし、すべてのタイミングで全部を実行すると、開発速度が落ちます。
CI/CD設計では、ローカルhook、PR CI、main CIの役割を分けることが重要です。
軽いチェックは早いタイミングで、重いチェックは必要なタイミングで実行します。
役割の全体像
| タイミング | 目的 | 向いている処理 |
|---|---|---|
| pre-commit | 手元の小さなミスを即修正 | format、staged files lint |
| pre-push | push前の簡易確認 | unit test、typecheckの一部 |
| PR CI | merge前の品質確認 | lint、typecheck、test、build |
| main CI | 本番反映前後の確認 | deploy、E2E、重いscan |
pre-commitに全部入れるとcommitが重くなります。main CIだけに寄せると、フィードバックが遅すぎます。
pre-commit
pre-commitでは、軽くて自動修正しやすい処理を実行します。
向いているもの:
- Prettier
- ESLintのfix
- import整理
- staged filesだけのlint
- 秘密情報の簡易検出
避けたいもの:
- 全体typecheck
- 全テスト
- E2E
- build
- 外部APIに依存する処理
pre-commitは頻繁に動くため、数秒以内を目標にします。重い処理を入れると、開発者が --no-verify を使いたくなります。
pre-push
pre-pushは、push前に少し重い確認をする場所です。
候補:
- unit test
- typecheck
- 変更範囲のtest
- packageの軽いbuild
ただし、pre-pushも重すぎると邪魔になります。チームによってはpre-pushを使わず、PR CIへ寄せる判断もあります。
PR CI
PR CIは、merge前の標準チェックです。
おすすめ:
on:
pull_request:
jobs:
lint:
typecheck:
test:
build:
PR CIでは、ローカルhookを飛ばした変更も検出できるようにします。
見るべきもの:
- lintが通る
- typecheckが通る
- unit testが通る
- buildできる
- 必要なら軽いintegration testが通る
PR CIは、レビュー前の機械的な品質チェックです。
main CI
main CIは、merge後の信頼できるブランチで動きます。
候補:
- production build
- deploy
- migration dry-run
- E2E
- security scan
- release作成
- Docker image build/push
main CIは重くてもよい場合があります。ただし、失敗したときの影響が大きいので、通知とロールバック手順を用意します。
重いE2Eの扱い
E2Eは価値がありますが、遅くなりやすいです。
実行タイミングの候補:
| タイミング | 使い方 |
|---|---|
| PRごと | 重要なsmoke testだけ |
| main merge後 | フルE2E |
| nightly | 重い全ケース |
| release前 | 本番相当で確認 |
PRごとに全E2Eを走らせると、CI待ちが長くなります。重要な導線だけに絞るなど、段階を分けます。
失敗時の責務
どこで失敗したかによって、修正すべき内容が変わります。
| 失敗場所 | 意味 |
|---|---|
| pre-commit | 手元のformat/lint違反 |
| pre-push | push前に気づける品質問題 |
| PR CI | merge前に止めるべき問題 |
| main CI | merge後の環境差、deploy問題 |
ローカルhookだけで守ろうとせず、PR CIを最終防衛線にします。
ポートフォリオでの設計例
ポートフォリオなら、次の構成で十分強いです。
pre-commit:
Lefthook
staged files lint
format
PR CI:
lint
typecheck
test
build
main CI:
deploy
READMEには、役割分担を書きます。
## CI/CD
- pre-commit: Lefthookで変更ファイルだけlint/format
- Pull Request: lint/typecheck/test/buildを実行
- main: build成功後にデプロイ
- concurrencyで古いCIをキャンセル
これだけで、現場の開発フローを意識していることが伝わります。
まとめ
CI/CDは、全部を毎回走らせればよいわけではありません。
- pre-commitは軽く速く
- pre-pushは必要なら中程度の確認
- PR CIはmerge前の標準チェック
- main CIはdeployや重い検証
- E2Eは重要度で段階分けする
- ローカルhookに依存せず、CIでも必ず確認する
速度と品質のバランスを取れると、CI/CD設計の見え方が一段上がります。
