ci-cd-and-automation
CI/CDパイプラインの設定を自動化します。ビルドおよびデプロイメントパイプラインの構築または変更時に使用できます。品質ゲートの自動化、CI内のテストランナー設定、またはデプロイメント戦略の確立が必要な場合に活用します。
description の原文を見る
Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
SKILL.md 本文
CI/CDと自動化
概要
品質ゲートを自動化し、テスト、リント、型チェック、ビルドに合格しない変更が本番環境に到達しないようにします。CI/CDは他のすべてのスキルの実行メカニズムです。人間とエージェントが見落とすものをキャッチし、すべての変更について一貫して実行します。
左へのシフト: パイプラインの早い段階で問題をキャッチします。リントで見つかったバグは数分で解決できますが、本番環境で見つかった同じバグは数時間かかります。チェックを上流に移動させてください。静的分析をテストの前に、テストをステージングの前に、ステージングを本番環境の前に実施します。
速いほど安全: より小さなバッチと頻繁なリリースはリスクを減らします。増やしません。3つの変更を含むデプロイメントは、30の変更を含むものより調査しやすくなります。頻繁なリリースはリリースプロセス自体への信頼を高めます。
使用時期
- 新しいプロジェクトのCIパイプラインのセットアップ
- 自動化されたチェックの追加または変更
- デプロイメントパイプラインの設定
- 変更が自動検証をトリガーする場合
- CI障害のデバッグ
品質ゲートパイプライン
すべての変更はマージ前にこれらのゲートを通過します。
Pull Request Opened
│
▼
┌─────────────────┐
│ LINT CHECK │ eslint, prettier
│ ↓ pass │
│ TYPE CHECK │ tsc --noEmit
│ ↓ pass │
│ UNIT TESTS │ jest/vitest
│ ↓ pass │
│ BUILD │ npm run build
│ ↓ pass │
│ INTEGRATION │ API/DB tests
│ ↓ pass │
│ E2E (optional) │ Playwright/Cypress
│ ↓ pass │
│ SECURITY AUDIT │ npm audit
│ ↓ pass │
│ BUNDLE SIZE │ bundlesize check
└─────────────────┘
│
▼
Ready for review
どのゲートもスキップできません。 リントが失敗した場合は、リントを修正してください。ルールを無効にしないでください。テストが失敗した場合は、コードを修正してください。テストをスキップしないでください。
GitHub Actionsの設定
基本的なCIパイプライン
# .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npx tsc --noEmit
- name: Test
run: npm test -- --coverage
- name: Build
run: npm run build
- name: Security audit
run: npm audit --audit-level=high
データベース統合テストを含む
integration:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:16
env:
POSTGRES_DB: testdb
POSTGRES_USER: ci_user
POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
ports:
- 5432:5432
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Run migrations
run: npx prisma migrate deploy
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
- name: Integration tests
run: npm run test:integration
env:
DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
注: CI専用のテストデータベース用であっても、値をハードコーディングするのではなく、GitHub Secretsを使用して認証情報を管理してください。これは良い習慣を構築し、他のコンテキストでテスト認証情報が誤って再利用されるのを防ぎます。
E2Eテスト
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- run: npm ci
- name: Install Playwright
run: npx playwright install --with-deps chromium
- name: Build
run: npm run build
- name: Run E2E tests
run: npx playwright test
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/
CI障害をエージェントにフィードバックする
AIエージェントを使用したCIの力はフィードバックループです。CIが失敗したとき:
CI fails
│
▼
Copy the failure output
│
▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
│
▼
Agent fixes → pushes → CI runs again
主要なパターン:
Lint failure → Agent runs `npm run lint --fix` and commits
Type error → Agent reads the error location and fixes the type
Test failure → Agent follows debugging-and-error-recovery skill
Build error → Agent checks config and dependencies
デプロイメント戦略
プレビューデプロイメント
すべてのPRは手動テスト用のプレビューデプロイメントを取得します。
# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
runs-on: ubuntu-latest
if: github.event_name == 'pull_request'
steps:
- uses: actions/checkout@v4
- name: Deploy preview
run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}
フィーチャーフラグ
フィーチャーフラグはデプロイメントをリリースから分離します。不完全またはリスクのある機能をフラグの後ろにデプロイして、次のことができます。
- コードを有効にせずにシップする。 早期にメインにマージし、準備ができたら有効にします。
- 再デプロイせずにロールバックする。 コードをリバートするのではなく、フラグを無効にします。
- 新機能をカナリアリリースする。 1%のユーザーに有効にしてから、10%、そして100%に有効にします。
- A/Bテストを実行する。 機能の有無での動作を比較します。
// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
return renderNewCheckout();
}
return renderLegacyCheckout();
フラグのライフサイクル: 作成 → テスト用に有効化 → カナリア → 完全ロールアウト → フラグとデッドコードを削除します。永遠に存在するフラグは技術的負債になります。フラグを作成するときはクリーンアップ日を設定してください。
ステージロールアウト
PR merged to main
│
▼
Staging deployment (auto)
│ Manual verification
▼
Production deployment (manual trigger or auto after staging)
│
▼
Monitor for errors (15-minute window)
│
├── Errors detected → Rollback
└── Clean → Done
ロールバック計画
すべてのデプロイメントは可逆的である必要があります。
# Manual rollback workflow
name: Rollback
on:
workflow_dispatch:
inputs:
version:
description: 'Version to rollback to'
required: true
jobs:
rollback:
runs-on: ubuntu-latest
steps:
- name: Rollback deployment
run: |
# Deploy the specified previous version
npx vercel rollback ${{ inputs.version }}
環境管理
.env.example → Committed (template for developers)
.env → NOT committed (local development)
.env.test → Committed (test environment, no real secrets)
CI secrets → Stored in GitHub Secrets / vault
Production secrets → Stored in deployment platform / vault
CIは本番環境のシークレットを持つべきではありません。CIテスト用に別のシークレットを使用します。
CI以外の自動化
Dependabot / Renovate
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: npm
directory: /
schedule:
interval: weekly
open-pull-requests-limit: 5
ビルドコップロール
CIをグリーンに保つ責任のある人を指定してください。ビルドが壊れたときは、ビルドコップの仕事は修正またはリバートです。変更を引き起こした人の仕事ではありません。これは、誰もが他の誰かが修正すると思っている間に、壊れたビルドが蓄積されるのを防ぎます。
PRチェック
- 必須レビュー: マージ前に少なくとも1つの承認
- 必須ステータスチェック: マージ前にCIが合格する必要があります
- ブランチ保護: mainへの強制プッシュなし
- 自動マージ: すべてのチェックに合格し、承認されたら自動的にマージします
CI最適化
パイプラインが10分を超える場合は、影響の順序でこれらの戦略を適用します。
Slow CI pipeline?
├── Cache dependencies
│ └── Use actions/cache or setup-node cache option for node_modules
├── Run jobs in parallel
│ └── Split lint, typecheck, test, build into separate parallel jobs
├── Only run what changed
│ └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
├── Use matrix builds
│ └── Shard test suites across multiple runners
├── Optimize the test suite
│ └── Remove slow tests from the critical path, run them on a schedule instead
└── Use larger runners
└── GitHub-hosted larger runners or self-hosted for CPU-heavy builds
例: キャッシングと並列化
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm run lint
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npx tsc --noEmit
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '22', cache: 'npm' }
- run: npm ci
- run: npm test -- --coverage
よくある言い訳
| 言い訳 | 現実 |
|---|---|
| 「CIが遅い」 | パイプラインを最適化してください。スキップしないでください。5分のパイプラインは何時間ものデバッグを防ぎます。 |
| 「この変更は簡単だからCIをスキップしよう」 | 簡単な変更もビルドを壊します。簡単な変更ではCIは速いです。 |
| 「テストは不安定だから再実行すればいい」 | 不安定なテストは実際のバグを隠し、みんなの時間を浪費します。不安定さを修正してください。 |
| 「CIは後で追加しよう」 | CIのないプロジェクトは壊れた状態が蓄積します。初日にセットアップしてください。 |
| 「手動テストで十分」 | 手動テストはスケールしません。繰り返し可能ではありません。できることを自動化してください。 |
危険信号
- プロジェクトにCIパイプラインがない
- CI障害が無視されるか沈黙させられている
- パイプラインに合格させるためにCIでテストが無効化されている
- 本番デプロイがステージング検証なしに行われている
- ロールバック機構がない
- シークレットがコードまたはCI設定ファイルに保存されている（シークレットマネージャーではなく）
- 最適化の努力なしに長いCI時間
検証
CI をセットアップまたは変更した後:
- すべての品質ゲートが存在します (リント、型、テスト、ビルド、監査)
- パイプラインはすべてのPRと main へのプッシュで実行されます
- 障害はマージをブロックします (ブランチ保護が設定されている)
- CI結果が開発ループにフィードバックされます
- シークレットはコードではなくシークレットマネージャーに保存されています
- デプロイメントにはロールバック機構があります
- パイプラインがテストスイートの10分以内で実行されます
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- addyosmani
- ライセンス
- MIT
- 最終更新
- 2026/5/10
Source: https://github.com/addyosmani/agent-skills / ライセンス: MIT