CI/CD パイプラインジェネレーター

概要

様々なプラットフォーム（GitHub Actions、GitLab CI、CircleCI、Jenkins）向けのプロダクションレディなCI/CDパイプライン設定ファイルを生成します。このスキルは、リント、テスト、ビルド、デプロイメントを処理する自動ワークフローのセットアップに関するテンプレートと指針を提供します。特にNode.js/Next.js プロジェクトの現代的なウェブアプリケーションに適しています。

コア機能

1. プラットフォーム選択

プロジェクトの要件に基づいて適切なCI/CDプラットフォームを選択します：

• GitHub Actions: GitHub でホストされたプロジェクトに最適で、ネイティブ統合が可能
• GitLab CI/CD: 複雑なパイプイン要件を持つGitLabリポジトリに最適
• CircleCI: Docker ワークフローと高速ビルド時間に最適化
• Jenkins: 自己ホスト型で高度なカスタマイズが可能な環境に適している

詳細なプラットフォーム比較、長所/短所、ユースケース推奨については references/platform-comparison.md を参照してください。

2. パイプライン設定生成

以下の原則に従ってパイプライン設定を生成します：

パイプラインステージ

パイプラインを以下の標準的なステージで構成します：

1. 依存関係のインストール

   • リポジトリからコードをチェックアウト
   • ランタイム環境を設定（Node.js バージョン）
   • キャッシュされた依存関係を復元
   • npm ci で依存関係をインストール
   • 今後の実行用に依存関係をキャッシュ

2. リント

   • ESLintでコード品質をチェック
   • TypeScript の型チェックを実行
   • リントエラーで早期に失敗

3. テスト

   • ユニットテストを実行
   • 統合テストを実行
   • コードカバレッジレポートを生成
   • Codecov、Coveralls などのレポートサービスにカバレッジをアップロード

4. ビルド

   • プロダクションビルドを作成
   • ビルドが成功することを確認
   • ビルドアーティファクトを保存

5. デプロイ

   • ステージング環境にデプロイ（develop ブランチ）
   • プロダクション環境にデプロイ（main ブランチ）
   • デプロイ後のスモークテストを実行

キャッシング戦略

ビルドを高速化するための効果的なキャッシングを実装します：

# package-lock.json に基づいて node_modules をキャッシュ
cache:
  key: ${{ hashFiles('package-lock.json') }}
  paths:
    - node_modules/
    - .npm/

環境変数

必要な環境変数を設定します：

• NODE_ENV: ビルド時に production に設定
• プラットフォーム固有のトークン: シークレットとして保存
• ビルド時変数: ビルドプロセスに渡す

3. テンプレート使用法

assets/ ディレクトリから提供されるテンプレートを使用します：

GitHub Actions テンプレート (assets/github-actions-nodejs.yml)：

• リント、テスト、ビルド、デプロイを含むマルチジョブワークフロー
• 複数の Node.js バージョンのマトリックスビルド（オプション）
• Vercel デプロイメント統合
• アーティファクトのアップロード
• コードカバレッジレポート

GitLab CI テンプレート (assets/gitlab-ci-nodejs.yml)：

• マルチステージパイプライン
• 依存関係のキャッシング
• 本番環境への手動デプロイ
• ステージング環境への自動デプロイ
• カバレッジレポート

テンプレートを使用するには：

1. 適切なテンプレートファイルをコピー
2. 正しい場所に配置：
   • GitHub Actions: .github/workflows/ci.yml
   • GitLab CI: .gitlab-ci.yml
3. デプロイターゲット、環境変数、ブランチ名をカスタマイズ
4. 必要なシークレットをプラットフォーム設定に追加

4. デプロイメント設定

Vercel デプロイメント

GitHub Actions の場合：

- uses: amondnet/vercel-action@v25
  with:
    vercel-token: ${{ secrets.VERCEL_TOKEN }}
    vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
    vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
    vercel-args: '--prod'

必須シークレット：

• VERCEL_TOKEN: Vercel アカウント設定から取得
• VERCEL_ORG_ID: Vercel プロジェクト設定から取得
• VERCEL_PROJECT_ID: Vercel プロジェクト設定から取得

Netlify デプロイメント

- run: |
    npm install -g netlify-cli
    netlify deploy --prod --dir=.next
  env:
    NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
    NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

AWS S3 + CloudFront

- uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

- run: |
    aws s3 sync .next/static s3://${{ secrets.S3_BUCKET }}/static
    aws cloudfront create-invalidation --distribution-id ${{ secrets.CF_DIST_ID }} --paths "/*"

5. テスト統合

適切なレポート機能でテスト実行を設定します：

Jest 設定：

- name: Run tests with coverage
  run: npm test -- --coverage --coverageReporters=text --coverageReporters=lcov

- name: Upload coverage
  uses: codecov/codecov-action@v4
  with:
    files: ./coverage/lcov.info
    flags: unittests

高速失敗戦略：

# まず高速なテストを実行
jobs:
  lint:  # 約30秒で失敗
  test:  # 約2分で失敗
  build: # 約5分で失敗
    needs: [lint, test]
  deploy:
    needs: [build]

6. ブランチベースのワークフロー

ブランチごとに異なる動作を実装します：

フィーチャーブランチ / PR：

• リント + テストのみを実行
• デプロイメントなし
• PR コメントにテスト結果を追加

Develop ブランチ：

• リント + テスト + ビルドを実行
• ステージング環境にデプロイ
• 自動デプロイ

Main ブランチ：

• リント + テスト + ビルドを実行
• プロダクション環境にデプロイ
• 手動承認（オプション）
• リリースタグを作成

例：

deploy_staging:
  if: github.ref == 'refs/heads/develop'
  # ステージング環境にデプロイ

deploy_production:
  if: github.ref == 'refs/heads/main'
  environment: production  # 手動承認が必要
  # 本番環境にデプロイ

ワークフロー決定ツリー

以下の決定ツリーに従って、適切なパイプラインを生成してください：

1. どのプラットフォーム？

   • GitHub → assets/github-actions-nodejs.yml を使用
   • GitLab → assets/gitlab-ci-nodejs.yml を使用
   • CircleCI/Jenkins → GitHub Actions テンプレートを適応
   • 不確定 → references/platform-comparison.md を参照

2. どのステージが必要？

   • 常に含める: リント、テスト、ビルド
   • オプション: セキュリティスキャン、E2E テスト、パフォーマンステスト
   • CI からデプロイする場合はデプロイステージを追加

3. どのデプロイプラットフォーム？

   • Vercel → Vercel デプロイメント例を使用
   • Netlify → Netlify CLI アプローチを使用
   • AWS → AWS Actions/CLI を使用
   • カスタム → カスタムデプロイスクリプトを実装

4. どのトリガー？

   • main/develop へのプッシュ時
   • プルリクエスト時
   • タグ作成時
   • 手動ワークフロー実行

5. どの環境変数が必要？

   • プラットフォームトークン（Vercel、Netlify、AWS）
   • 外部サービス用の API キー
   • ビルド時環境変数
   • 機能フラグ

ベストプラクティス

セキュリティ

• すべてのシークレットをプラットフォームのシークレット管理に保存（コードに記載しない）
• 最小権限トークンを使用（可能な場合は読み取り専用）
• 定期的にシークレットをローテーション
• シークレットアクセス権限を監査
• シークレットをログに出力しない（*** でマスク）

パフォーマンス

• 依存関係を積極的にキャッシュ
• 独立したジョブを並列化
• 複数バージョンテスト用にマトリックスビルドを使用
• 高速失敗: 遅いチェックの前に素早いチェックを実行
• Docker レイヤーキャッシングを最適化

信頼性

• 正確な Node.js バージョンをピン留め（18 ではなく 18.x）
• ロックファイルをコミット（package-lock.json）
• 不安定な外部サービスに再試行ロジックを追加
• 妥当なタイムアウトを設定（最大10～15分）
• 重要でないステップに continue-on-error を使用

保守性

• 複雑なロジックを説明するコメントを追加
• 再利用可能なワークフロー/テンプレートを使用
• 設定を DRY に保つ（Do Not Repeat Yourself）
• すべてのパイプライン変更をバージョン管理
• 必要なシークレットを README に記載

共通パターン

マルチ環境デプロイメント

deploy_staging:
  environment: staging
  if: github.ref == 'refs/heads/develop'

deploy_production:
  environment: production
  if: github.ref == 'refs/heads/main'
  needs: [deploy_staging]

マトリックステスト

strategy:
  matrix:
    node-version: [16.x, 18.x, 20.x]
    os: [ubuntu-latest, windows-latest]

条件付きステップ

- name: Deploy
  if: github.event_name == 'push' && github.ref == 'refs/heads/main'
  run: npm run deploy

アーティファクト管理

- name: Upload build
  uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: .next/
    retention-days: 7

- name: Download build
  uses: actions/download-artifact@v4
  with:
    name: build-output

トラブルシューティング

パイプライン失敗

1. アクション/ジョブログでエラーメッセージを確認
2. 環境変数とシークレットが設定されていることを確認
3. パイプラインに追加する前にコマンドをローカルでテスト
4. ドキュメントでプラットフォーム固有の問題を確認

遅いビルド

1. キャッシュが機能していることを確認（キャッシュヒット/ミスログをチェック）
2. 独立したジョブを並列化
3. 利用可能な場合はより高速なランナーを使用
4. 依存関係のインストールを最適化

デプロイメント失敗

1. デプロイメントトークンが有効であることを確認
2. プラットフォームのステータスページを確認
3. デプロイメントログを確認
4. デプロイメントコマンドをローカルでテスト

リソース

テンプレート（assets/）

• github-actions-nodejs.yml: 完全な GitHub Actions ワークフロー
• gitlab-ci-nodejs.yml: 完全な GitLab CI パイプライン

リファレンスドキュメント（references/）

• platform-comparison.md: CI/CD プラットフォーム、デプロイターゲット、ベストプラクティス、共通パターンの詳細な比較

使用例

ユーザーリクエスト: 「テストを実行して Vercel にデプロイする GitHub Actions ワークフローを作成してください」

ステップ：

1. assets/github-actions-nodejs.yml テンプレートをコピー
2. .github/workflows/ ディレクトリが存在しない場合は作成
3. .github/workflows/ci.yml として保存
4. Vercel 認証情報でデプロイセクションを更新
5. GitHub リポジトリ設定にシークレットを追加：
   • VERCEL_TOKEN
   • VERCEL_ORG_ID
   • VERCEL_PROJECT_ID
6. コミットしてプッシュしてワークフローをトリガー

ユーザーリクエスト: 「ステージング環境と本番環境を備えた GitLab CI をセットアップしてください」

ステップ：

1. assets/gitlab-ci-nodejs.yml テンプレートをコピー
2. リポジトリルートに .gitlab-ci.yml として保存
3. GitLab CI/CD 変数を設定：
   • VERCEL_TOKEN
   • その他のデプロイメント認証情報
4. 本番環境の手動承認設定を確認
5. パイプラインをトリガーするためにコミット

高度な設定

モノレポサポート

paths:
  - 'apps/frontend/**'
  - 'packages/**'

スケジュール実行

on:
  schedule:
    - cron: '0 2 * * *'  # 毎日午前2時

外部サービス統合

- name: Notify Slack
  uses: 8398a7/action-slack@v3
  with:
    status: ${{ job.status }}
    webhook_url: ${{ secrets.SLACK_WEBHOOK }}

セキュリティスキャン

- name: Run security audit
  run: npm audit --audit-level=moderate

- name: Check for vulnerabilities
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}