CI/CD レッスン2
パイプライン設計
ビルド・テスト・デプロイの各ステージを組み立てるCI/CDパイプラインの設計方法を学ぶ
パイプラインの基本構造
CI/CDパイプラインは、コードの変更から本番へのリリースまでを一連のステージとして自動化したものです。 各ステージは前段階が成功して初めて実行され、途中で失敗すればそこで止まります。
Build→
Unit Test→
Integration Test→
Deploy Staging→
E2E Test→
Deploy Production
各ステージの役割
1. Build（ビルド）
依存関係のインストール・コンパイル・型チェックなど、実行可能な成果物を作る段階。
2. Test（テスト）
単体テスト→結合テストの順に、テストピラミッドに沿って軽いものから実行する。
3. Deploy Staging（ステージング配置）
本番に近い検証環境へ自動デプロイし、E2Eテストなど重い検証を行う。
4. Deploy Production（本番配置）
承認を経て、あるいは自動で本番環境へリリースする最終ステージ。
ステージ構成の実装例
# ① .github/workflows/pipeline.yml
name: Pipeline
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm run build
test:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run test:unit
- run: npm run test:integration
deploy-staging:
needs: test
runs-on: ubuntu-latest
steps:
- run: echo "ステージング環境へデプロイ"
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production # 承認フローを挟める
steps:
- run: echo "本番環境へデプロイ"needsで前段階への依存を明示することで、 「ビルドが通らなければテストしない」「テストが通らなければデプロイしない」という 安全なゲートを構築できます。
設計時に意識すべきこと
- • 「速く失敗する(fail fast)」原則で、軽くて速いチェックを先に配置する
- • 独立したテストは並列実行し、パイプライン全体の待ち時間を短縮する
- • 本番デプロイの前には手動承認や自動ロールバックの仕組みを用意する
- • パイプライン自体の設定もコードとしてリポジトリで管理し、レビュー対象にする
ポイント
- • パイプラインはビルド→テスト→デプロイの順にステージを積み上げる
- • 前段階の失敗は後段階に進ませない（fail fast）
- • 軽いチェックを先に、重い検証を後に配置して時間を節約する
- • パイプライン設定自体もコードとしてレビュー・バージョン管理する
確認クイズ
1 / 3CI/CDパイプラインの一般的なステージ順序として適切なものはどれか？