cicd-pipeline-generator

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

概要

さまざまなプラットフォーム（GitHub Actions、GitLab CI、CircleCI、Jenkins）向けに、本番環境ですぐに使える CI/CD パイプライン設定ファイルを生成します。このスキルでは、特に Node.js／Next.js プロジェクトなどの最新のウェブアプリケーションで、Lint、テスト、ビルド、デプロイを処理する自動ワークフローを設定するためのテンプレートとガイダンスを提供します。

主な機能

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

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

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

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

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

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

パイプラインのステージ

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

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

   • リポジトリからコードをチェックアウトする
   • 実行環境をセットアップする（Node.js のバージョン）
   • キャッシュされた依存関係を復元する
   • npm ci で依存関係をインストールする
   • 次回以降の実行に備えて依存関係をキャッシュする

2. Lint

   • コード品質の確認に ESLint を実行する
   • TypeScript の型チェックを実行する
   • Lint エラーがあれば速やかに失敗させる

3. テスト

   • 単体テストを実行する
   • 統合テストを実行する
   • コードカバレッジレポートを生成する
   • カバレッジをレポートサービス（Codecov、Coveralls）にアップロードする

4. ビルド

   • 本番ビルドを作成する
   • ビルドが成功することを確認する
   • ビルド成果物を保存する

5. デプロイ

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

キャッシュ戦略

ビルドを高速化するために、効果的なキャッシュを実装します。

# Cache node_modules based on package-lock.json
cache:
  key: ${{ hashFiles('package-lock.json') }}
  paths:
    - node_modules/
    - .npm/

環境変数

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

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

3. テンプレートの使用

assets/ ディレクトリにあるテンプレートを使用します。

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

• Lint、テスト、ビルド、デプロイを含む複数ジョブのワークフロー
• 複数の 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

速やかに失敗させる戦略：

# Run quick tests first
jobs:
  lint:  # Fails in ~30 seconds
  test:  # Fails in ~2 minutes
  build: # Fails in ~5 minutes
    needs: [lint, test]
  deploy:
    needs: [build]

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

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

機能ブランチ／PR：

• Lint とテストのみを実行する
• デプロイしない
• テスト結果を PR コメントに追加する

Develop ブランチ：

• Lint、テスト、ビルドを実行する
• ステージング環境にデプロイする
• 自動デプロイする

Main ブランチ：

• Lint、テスト、ビルドを実行する
• 本番環境にデプロイする
• 手動承認（任意）
• リリースタグを作成する

例：

deploy_staging:
  if: github.ref == 'refs/heads/develop'
  # Deploy to staging

deploy_production:
  if: github.ref == 'refs/heads/main'
  environment: production  # Requires manual approval
  # Deploy to production

ワークフロー決定ツリー

次の決定ツリーに従って、適切なパイプラインを生成します。

1. どのプラットフォームを使用しますか？

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

2. 必要なステージは何ですか？

   • 必ず含める項目：Lint、Test、Build
   • オプション：セキュリティスキャン、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（Don't 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 * * *'  # Daily at 2 AM

外部サービスとの連携

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

Security Scanning

- 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 }}