cicd-setup

CI/CD のセットアップ

使用するタイミング

• 新しいプロジェクトの CI をゼロからセットアップするとき
• 実際のスタックに合わない、コピーした信頼性の低いパイプライン設定を置き換えるとき
• GitHub Actions と GitLab CI のプラットフォーム間で移行するとき
• パイプラインのステージが実際のプロジェクトのツールと一致しているか確認するとき
• ビルドの遅さを改善するとき（キャッシュ、並列処理、条件付きステップ）
• 専門的な強化を追加する前に、安定した CI の基盤を構築するとき

必要なコンテキスト

startup-context から、技術スタック、デプロイ先、チーム規模を取得します。また、次の項目を検出するか、確認してください。

• 言語とフレームワーク（質問する前にリポジトリのファイルから自動検出します）
• デプロイ先（Vercel、AWS、GCP、Fly.io など）
• CI/CD プラットフォーム（デフォルト：GitHub Actions。GitLab CI にも対応）
• 環境（dev、staging、production）と既存のテストカバレッジ
• ビルドまたはデプロイに必要なシークレットと認証情報

ワークフロー

1. リポジトリ内の兆候からスタックを検出する — ロックファイル（package-lock.json、yarn.lock、poetry.lock、go.sum、Cargo.lock）、言語マニフェスト（package.json、pyproject.toml、go.mod）、スクリプト定義（test、lint、build コマンド）をスキャンします。ロックファイルからパッケージマネージャーを判定します。スクリプトがない場合は、保守的なデフォルトを使用します。Python プロジェクトを Node と決めつけないでください。
2. パイプラインのステージを選択する — 信頼できる基本構成から開始します。チェックアウト、ランタイムのセットアップ、キャッシュを使った依存関係のインストールに続いて、lint、test、build を順番に実行します。基本構成が動作してから複雑さを追加してください。
3. パイプライン設定を生成する — 検出したプラットフォーム用の CI 設定を作成します。検出したパッケージマネージャーに適したキャッシュ戦略を用いて、機械可読な YAML を出力します。参照するコマンドがすべてプロジェクト内に実在することを確認してください。
4. シークレットを設定する — 必要なシークレットと追加方法を列挙します。プラットフォーム管理のシークレットストアを使用してください。クラウド認証では、長期間有効なキーより OIDC を推奨します。YAML に認証情報をハードコードしないでください。
5. 安全にデプロイステージを追加する — まず CI のみ（lint/test/build）から始めます。明示的な環境情報を指定して staging へのデプロイを追加します。手動承認を伴う production へのデプロイを追加します。ロールアウトとロールバックの手順は透明性を保ってください。
6. マージ前に検証する — 生成した YAML の構文が正しいこと、すべてのコマンドがプロジェクト内に存在すること、キャッシュがパッケージマネージャーに適合していること、ブランチ保護が組織の要件に合っていることを確認します。
7. 設定と手順を提供する — 設定ファイル全体とセットアップ手順を提供します。

出力形式

# CI/CD Pipeline: [Project Name]
## Stack Detection Results — detected language, runtime, tools, and build commands
## Pipeline Overview — Mermaid flowchart showing stages
## Pipeline Configuration — Full YAML config file
## Secrets Required — table: name, where to get, how to add
## Setup Instructions — step-by-step to activate
## Validation Checklist — commands verified, caching confirmed, branch rules set
## Optimization Notes — caching strategy, estimated build time

フレームワークとベストプラクティス

検出を優先したパイプライン生成

生成前に必ず検出します。検出処理では、次の具体的なファイル情報を参照します。

• ロックファイルからパッケージマネージャーを判定します（npm、yarn、pip、cargo、go modules）
• 言語マニフェストからランタイムの種類を特定します
• package.json/pyproject.toml のスクリプト定義から lint/test/build コマンドを判断します
• スクリプトがない場合は、推測せず保守的なデフォルトコマンドを使用します

エコシステムごとのキャッシュ戦略

エコシステム	キャッシュパス	キャッシュキー
Node.js	~/.npm or node_modules	hashFiles('**/package-lock.json')
Python	~/.cache/pip	hashFiles('**/requirements*.txt')
Go	~/go/pkg/mod	hashFiles('**/go.sum')
Rust	~/.cargo/registry, target/	hashFiles('**/Cargo.lock')
Ruby	vendor/bundle	hashFiles('**/Gemfile.lock')

パイプラインアーキテクチャの原則

• 最初に Lint — コストの高いテストの実行前に、早い段階で失敗を検出します
• 基本構成は順次実行 — チェックアウト、インストール、lint、test、build の後にアーティファクトを公開します
• 積極的にキャッシュする — ビルド時間を 30～60% 短縮します
• アクションのバージョンを固定する — サプライチェーンのセキュリティのため、タグではなく SHA ハッシュを使用します
• タイムアウト（timeout-minutes: 15）と並行実行制御を設定して、重複する実行をキャンセルします
• 一度に追加する改善は 1 つだけ — マトリックスビルド、セキュリティスキャン、デプロイを 1 つの PR で追加しないでください

環境戦略

環境	トリガー	承認	目的
CI	プッシュ／PR のたび	なし	lint とテストを実行
ステージング	main へのマージ	なし（自動）	統合テスト、QA
本番環境	Git タグまたは手動	必須	実際のユーザー向け

よくある落とし穴

1. Python や Go のリポジトリに Node 固有のパイプラインを適用する（まず検出してください）
2. 信頼できるテストカバレッジを確立する前にデプロイを有効にする
3. 依存関係のキャッシュ設定を見落とす
4. 小規模なブランチ更新でフルマトリックスビルドを実行する（パスフィルターを使用してください）
5. 本番環境へのデプロイでブランチ保護を設定しない
6. パイプライン YAML に認証情報を直接埋め込む

スケーリングとプラットフォームに関する注意事項

• 実行時間が 10 分を超える場合は、長時間実行されるジョブを分割します
• 実際に互換性への懸念がある場合にのみ、テストマトリックスを導入します
• GitHub エコシステムには GitHub Actions、セルフホスト型 SCM＋CI には GitLab CI を使用します
• リポジトリごとに、正式なパイプラインソースを 1 つだけ維持します

関連スキル

• code-review — コミット前に CI 設定自体をレビューするよう連携します
• security-review — セキュリティスキャンのステージ（trivy、semgrep、npm audit）を追加または監査するよう連携します

例

プロンプトの例：「Vercel にデプロイする Next.js アプリの CI/CD を設定してください。」

出力の良い例：

name: CI
on:
  push: { branches: [main] }
  pull_request: { branches: [main] }
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
jobs:
  lint:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npm run lint && npx tsc --noEmit
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci && npm test -- --coverage

プロンプトの例：「Python の CI に 8 分かかります。高速化するにはどうすればよいですか？」

出力の良い例：

Stack detection shows: Python 3.11, pytest, pip. Three fixes to cut to ~3 minutes:
(1) Add pip caching keyed on hashFiles('requirements*.txt'),
(2) split unit/integration tests into parallel jobs,
(3) add path filters to skip CI on docs-only changes.