ci-cd

CI/CD パイプラインのセットアップ

このスキルを使うと、エージェントはソフトウェア配信ライフサイクル全体を自動化する CI/CD パイプラインを設計、設定、保守できます。エージェントは、リンティング、テスト、ビルド、デプロイ、関係者への通知などのパイプラインステージを設定し、コードの変更をすべて確実に検証して配信できます。また、シークレット管理、キャッシュ戦略、マトリックスビルド、ブルー／グリーンデプロイやカナリアリリースなどのデプロイ戦略にも対応しています。

ワークフロー

1. プロジェクトを評価してプラットフォームを選択する： エージェントは、プロジェクトの言語、フレームワーク、ホスティング環境、チームの意向を分析し、CI/CD プラットフォームを推奨します。選択肢には GitHub Actions、GitLab CI/CD、Jenkins、CircleCI、Azure DevOps があります。推奨する前に、リポジトリのホスティング先、コスト、プラグインのエコシステム、既存ツールとの統合などの要素を考慮します。

2. パイプラインステージを定義する： エージェントはパイプラインを、リンティング（静的解析とコードスタイル）、テスト（単体、統合、エンドツーエンド）、ビルド（コンパイル、バンドル、Docker イメージの作成）、デプロイ（ステージングと本番環境）、通知（Slack、メール、Webhook アラート）の各ステージに分割します。各ステージの入力、出力、失敗条件を明確に定義し、エラーが発生した場合はパイプラインを速やかに停止できるようにします。

3. シークレットと環境変数を設定する： エージェントは、プラットフォーム標準のシークレットマネージャー（例：GitHub Secrets、GitLab CI/CD Variables、Jenkins Credentials）を使用して、API キー、データベースの認証情報、クラウドプロバイダーのトークンなどの機密情報を安全に保管するよう設定します。シークレットをパイプラインファイルにハードコードすることはなく、適切な環境に限定します。

4. キャッシュと最適化を実装する： エージェントは、依存関係（npm、pip、Maven）とビルド成果物のキャッシュを設定し、パイプラインの実行時間を短縮します。マトリックスビルドを使って、複数の言語バージョンやオペレーティングシステムで並列にテストします。また、エンドツーエンドテストのような負荷の高いステージは、関連するブランチでのみ実行するなど、条件付き実行も設定します。

5. デプロイ戦略を設定する： エージェントは、プロジェクトのリスク許容度とインフラストラクチャに応じて、適切なデプロイ戦略を実装します。選択肢には、ローリングアップデート、ブルー／グリーンデプロイ（ロードバランサーで切り替える同一構成の2つの環境）、カナリアリリース（トラフィックを段階的に切り替える方法）があります。また、デプロイでヘルスチェックに失敗した場合に備えて、ロールバック手順も設定します。

6. 通知とモニタリングを設定する： エージェントは、Slack、Microsoft Teams、メール、カスタム Webhook を通じて、ビルドのステータスをチームに知らせるパイプライン実行後の通知を設定します。デプロイイベントを記録し、各デプロイ後にアプリケーションの健全性を確認するため、エージェントはモニタリングツールと連携することもできます。

対応テクノロジー

• プラットフォーム： GitHub Actions、GitLab CI/CD、Jenkins、CircleCI、Azure DevOps、Bitbucket Pipelines、Travis CI
• 言語： Node.js、Python、Java、Go、Rust、Ruby、.NET、PHP
• コンテナ化： Docker、Podman、Buildah
• クラウドプロバイダー： AWS（ECS、EKS、Lambda）、GCP（Cloud Run、GKE）、Azure（App Service、AKS）
• アーティファクトレジストリ： Docker Hub、GitHub Container Registry、AWS ECR、Google Artifact Registry

使い方

プロジェクトの言語、フレームワーク、リポジトリのホスティング先、デプロイ先の環境、およびテストフレームワークやデプロイ戦略などの具体的な要件をエージェントに伝えてください。

プロンプトの例：

Set up a CI/CD pipeline for my Node.js Express app hosted on GitHub.
- Run ESLint and Prettier checks, then Jest unit tests
- Build a Docker image and push to GitHub Container Registry
- Deploy to AWS ECS staging on push to develop, production on push to main
- Send Slack notifications on failure

例

例 1：Node.js アプリケーション向け GitHub Actions ワークフロー

name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run format:check

  test:
    runs-on: ubuntu-latest
    needs: lint
    strategy:
      matrix:
        node-version: [18, 20, 22]
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        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: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
        env:
          DATABASE_URL: postgres://postgres:testpass@localhost:5432/testdb
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node-version }}
          path: coverage/

  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push'
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy-staging:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.ref == 'refs/heads/develop'
    environment: staging
    steps:
      - 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 ecs update-service --cluster staging-cluster \
            --service my-app --force-new-deployment

  deploy-production:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - 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 ecs update-service --cluster production-cluster \
            --service my-app --force-new-deployment

  notify:
    runs-on: ubuntu-latest
    needs: [deploy-staging, deploy-production]
    if: always() && contains(needs.*.result, 'failure')
    steps:
      - uses: slackapi/[email protected]
        with:
          payload: |
            {"text": "Pipeline failed for ${{ github.repository }} on ${{ github.ref_name }}"}
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

例 2：Docker を使用する Python アプリケーション向け GitLab CI パイプライン

stages:
  - lint
  - test
  - build
  - deploy

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

cache:
  paths:
    - .pip-cache/
    - .venv/

lint:
  stage: lint
  image: python:3.12-slim
  script:
    - pip install ruff mypy
    - ruff check src/
    - mypy src/ --ignore-missing-imports

test:
  stage: test
  image: python:3.12-slim
  services:
    - postgres:16
  variables:
    POSTGRES_DB: testdb
    POSTGRES_PASSWORD: testpass
    DATABASE_URL: "postgresql://postgres:testpass@postgres:5432/testdb"
  script:
    - python -m venv .venv
    - source .venv/bin/activate
    - pip install -r requirements.txt -r requirements-dev.txt
    - pytest tests/ --cov=src --cov-report=xml
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $DOCKER_IMAGE -t $CI_REGISTRY_IMAGE:latest .
    - docker push $DOCKER_IMAGE
    - docker push $CI_REGISTRY_IMAGE:latest

deploy_production:
  stage: deploy
  image: alpine:latest
  only:
    - main
  environment:
    name: production
    url: https://myapp.example.com
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
  script:
    - ssh deploy@production-server "docker pull $DOCKER_IMAGE && docker-compose up -d"

ベストプラクティス

• 早期に失敗させる： パイプラインのステージは、lint やフォーマットなどの迅速なチェックを最初に実行するよう並べます。これにより、いずれにせよレビューに通らないコードに計算リソースを浪費するのを防げます。
• アクションとイメージのバージョンを固定する： 再現可能なビルドを確保し、サプライチェーン攻撃を避けるため、CI アクションと Docker イメージには必ず特定のバージョンタグ（例：actions/checkout@v4、python:3.12-slim）を使用します。
• シークレットの適用範囲を厳密に制限する： シークレットを必要とする環境とブランチに限定します。本番環境へのデプロイ前に手動承認を必須にするため、環境レベルの保護ルールを使用します。
• 積極的にキャッシュする： パイプラインの実行間で、依存関係のインストール、Docker レイヤー、ビルド成果物をキャッシュします。一般的なプロジェクトでは、パイプラインの実行時間を 50% 以上短縮できる場合があります。
• 互換性の確認にはマトリックスビルドを使用する： 複数の言語バージョンとオペレーティングシステムで並行してテストし、パイプライン全体の所要時間を延ばさずに、互換性の問題を早期に発見します。
• デプロイゲートを実装する： 不適切なデプロイの影響範囲を抑えるため、リリースを本番環境に昇格する前に、手動承認、ヘルスチェックの検証、またはカナリア分析を行います。

エッジケース

• 不安定なテスト： 成功したり失敗したりするテストは、パイプラインを妨げることがあります。既知の不安定なテストには再試行ロジックを実装し、不安定さの指標を追跡して、修正の優先順位を決めます。ほとんどの CI プラットフォームでは、個々のジョブに retry ディレクティブを指定できます。
• モノレポのパイプライン： モノレポでは、あるサービスへの変更によって、無関係なサービスのパイプラインが起動しないようにします。パスベースのフィルター（例：GitHub Actions の paths: や GitLab の changes:）を使用して、パイプラインの起動対象を絞ります。
• レート制限とクォータ： Docker Hub、npm、クラウド API にはレート制限があります。スロットリングによるパイプラインの失敗を避けるため、認証済みのプル、プライベートミラー、またはキャッシュプロキシを使用します。
• 実行時間の長いパイプライン： プラットフォームの制限時間（例：GitHub Actions の 6 時間のジョブ制限）を超えるパイプラインは、より小さなジョブに分割するか、より高い制限時間を持つセルフホストランナーを使用する必要があります。
• ブランチ保護との競合： CI パイプラインがリポジトリに変更を書き戻す場合（例：自動フォーマットによるコミット）、ブランチ保護ルールと競合することがあります。変更をプッシュするには、専用のボットトークンまたはアプリレベルの認証を使用します。