デプロイメントパイプライン設計

承認ゲート、デプロイメント戦略、環境プロモーションワークフローを備えたマルチステージCI/CDパイプラインのアーキテクチャパターン。

目的

適切なステージ構成、自動化された品質ゲート、段階的デリバリー戦略を通じて、スピードと安全性のバランスを取る堅牢でセキュアなデプロイメントパイプラインを設計します。このスキルは、パイプラインアーキテクチャの構造設計と、本番環境への信頼性の高いデプロイメントの運用パターンの両方をカバーしています。

入力／出力

あなたが提供するもの

• アプリケーションタイプ: 言語/ランタイム、コンテナ化またはベアメタル、モノリスまたはマイクロサービス
• デプロイメント対象: Kubernetes、ECS、VM、サーバーレス、またはプラットフォームアズサービス
• 環境トポロジー: 環境の数（開発/ステージング/本番）、リージョンレイアウト、エアギャップ要件
• ロールアウト要件: 許容可能なダウンタイム、ロールバック SLA、トラフィック分割のニーズ、カナリア対ブルーグリーンの選好
• ゲート制約: 承認チーム、必要なテストカバレッジしきい値、コンプライアンススキャン（SAST、DAST、SCA）
• モニタリングスタック: Prometheus、Datadog、CloudWatch、または自動プロモーション判定に使用するその他のメトリクスソース

このスキルが提供するもの

• パイプライン構成: ステージ定義、ジョブ依存関係、並列処理、キャッシング戦略
• デプロイメント戦略: 選択したロールアウトパターンと注釈付き構成（カナリアウェイト、ブルーグリーン切り替え、ローリングパラメータ）
• ヘルスチェック設定: シャローとディープなレディネスプローブ、デプロイ後スモークテストスクリプト
• ゲート定義: 自動メトリクしきい値と手動承認ワークフロー
• ロールバック計画: 自動ロールバックトリガーと手動ランブックステップ

使用時期

• 新しいサービスまたはプラットフォーム移行用のCI/CDアーキテクチャを設計する
• 環境間のデプロイメントゲートを実装する
• 必須のセキュリティスキャンを含むマルチ環境パイプラインを構成する
• カナリアまたはブルーグリーン戦略による段階的デリバリーを確立する
• ステージは成功するが本番環境の動作が誤っているパイプラインをデバッグする
• メトリクスの劣化時の自動ロールバックで平均復旧時間を短縮する

パイプラインステージ

標準パイプラインフロー

┌─────────┐   ┌──────┐   ┌─────────┐   ┌────────┐   ┌──────────┐
│  Build  │ → │ Test │ → │ Staging │ → │ Approve│ → │Production│
└─────────┘   └──────┘   └─────────┘   └────────┘   └──────────┘

詳細なステージ分析

1. Source - コードチェックアウト、依存関係グラフの解決
2. Build - コンパイル、パッケージ化、コンテナ化、アーティファクト署名
3. Test - ユニット、統合、SAST/SCA セキュリティスキャン
4. Staging Deploy - ステージング環境へのデプロイとスモークテスト
5. Integration Tests - E2E、コントラクトテスト、パフォーマンスベースライン
6. Approval Gate - 手動または自動メトリクスベースのゲート
7. Production Deploy - カナリア、ブルーグリーン、またはローリング戦略
8. Verification - ディープなヘルスチェック、合成モニタリング
9. Rollback - 失敗信号での自動ロールバック

承認ゲートパターン

パターン1: 手動承認（GitHub Actions）

production-deploy:
  needs: staging-deploy
  environment:
    name: production
    url: https://app.example.com
  runs-on: ubuntu-latest
  steps:
    - name: Deploy to production
      run: kubectl apply -f k8s/production/

GitHub の環境保護ルールは、このジョブが開始される前に必要なレビューアーを強制します。Settings → Environments → production → Required reviewers でレビューアーを設定してください。

パターン2: 時間ベースの承認（GitLab CI）

deploy:production:
  stage: deploy
  script:
    - deploy.sh production
  environment:
    name: production
  when: delayed
  start_in: 30 minutes
  only:
    - main

パターン3: マルチ承認者（Azure Pipelines）

stages:
  - stage: Production
    dependsOn: Staging
    jobs:
      - deployment: Deploy
        environment:
          name: production
          resourceType: Kubernetes
        strategy:
          runOnce:
            preDeploy:
              steps:
                - task: ManualValidation@0
                  inputs:
                    notifyUsers: "team-leads@example.com"
                    instructions: "Review staging metrics before approving"

パターン4: 自動メトリクスゲート

AnalysisTemplate（Argo Rollouts）またはカスタムゲートスクリプトを使用して、エラー率がしきい値を超えた場合のプロモーションをブロックします:

# Argo Rollouts AnalysisTemplate — カナリアプロモーションを自動的にブロック
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 60s
    successCondition: "result[0] >= 0.95"
    failureCondition: "result[0] < 0.90"
    inconclusiveLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status!~"5..",job="my-app"}[2m]))
          / sum(rate(http_requests_total{job="my-app"}[2m]))

デプロイメント戦略

意思決定テーブル

戦略	ダウンタイム	ロールバック速度	コスト影響	最適な用途
Rolling	なし	~数分	なし	ほとんどのステートレスサービス
Blue-Green	なし	即座	2倍のインフラ（一時）	高リスク、またはデータベースマイグレーション
Canary	なし	即座	最小限	高トラフィック、メトリクス駆動
Recreate	あり	高速	なし	開発/テスト、バッチジョブ
Feature Flag	なし	即座	なし	段階的なフィーチャー公開

1. ローリングデプロイメント

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2         # ロールアウト中は最大 12 ポッド
      maxUnavailable: 1   # 常に最低 9 ポッドがサービス中

特性: 段階的なロールアウト、ダウンタイムなし、簡単なロールバック、ほとんどのアプリケーションに最適。

2. ブルーグリーンデプロイメント

# ブルーからグリーンへトラフィックを切り替え
kubectl apply -f k8s/green-deployment.yaml
kubectl rollout status deployment/my-app-green

# サービスセレクターを切り替え
kubectl patch service my-app -p '{"spec":{"selector":{"version":"green"}}}'

# 必要に応じて即座にロールバック
kubectl patch service my-app -p '{"spec":{"selector":{"version":"blue"}}}'

特性: 即座の切り替え、簡単なロールバック、インフラコストが一時的に倍増、長いウォームアップ時間を伴う高リスクデプロイメントに適切。

3. カナリアデプロイメント（Argo Rollouts）

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      analysis:
        templates:
          - templateName: success-rate
        startingStep: 2
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

特性: 段階的なトラフィックシフト、実ユーザーメトリクス検証、自動プロモーションまたはロールバック、Argo Rollouts またはサービスメッシュが必要。

4. フィーチャーフラグ

from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key="API_KEY")

if flagsmith.has_feature("new_checkout_flow"):
    process_checkout_v2()
else:
    process_checkout_v1()

特性: リリースせずにデプロイ、A/B テスト、ユーザーセグメント単位での即座なロールバック、デプロイメント独立の細粒度な制御。

パイプラインオーケストレーション

マルチステージパイプラインの例（GitHub Actions）

name: Production Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
    steps:
      - uses: actions/checkout@v4
      - name: Build and push Docker image
        id: build
        run: |
          IMAGE=myapp:${{ github.sha }}
          docker build -t $IMAGE .
          docker push $IMAGE
          echo "image=$IMAGE" >> $GITHUB_OUTPUT

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Unit tests
        run: make test
      - name: Security scan
        run: trivy image ${{ needs.build.outputs.image }}

  deploy-staging:
    needs: test
    environment:
      name: staging
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: kubectl apply -f k8s/staging/

  integration-test:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: Run E2E tests
        run: npm run test:e2e

  deploy-production:
    needs: integration-test
    environment:
      name: production        # 必要なレビューアーが承認するまでここでブロック
    runs-on: ubuntu-latest
    steps:
      - name: Canary deployment
        run: |
          kubectl apply -f k8s/production/
          kubectl argo rollouts promote my-app

  verify:
    needs: deploy-production
    runs-on: ubuntu-latest
    steps:
      - name: Deep health check
        run: |
          for i in {1..12}; do
            STATUS=$(curl -sf https://app.example.com/health/ready | jq -r '.status')
            [ "$STATUS" = "ok" ] && exit 0
            sleep 10
          done
          exit 1
      - name: Notify on success
        run: |
          curl -X POST ${{ secrets.SLACK_WEBHOOK }} \
            -d '{"text":"Production deployment successful: ${{ github.sha }}"}'

ヘルスチェック

シャロー対ディープなヘルスエンドポイント

シャローな /ping は、ダウンストリーム依存関係が壊れていても 200 を返します。トラフィックプロモーション前に実際の依存関係を検証するディープなレディネスエンドポイントを使用します。

# /health/ready — 実際の依存関係をチェック、パイプラインゲートで使用
@app.get("/health/ready")
async def readiness():
    checks = {
        "database": await check_db_connection(),
        "cache":    await check_redis_connection(),
        "queue":    await check_queue_connection(),
    }
    status = "ok" if all(checks.values()) else "degraded"
    code = 200 if status == "ok" else 503
    return JSONResponse({"status": status, "checks": checks}, status_code=code)

デプロイ後の検証スクリプト

#!/usr/bin/env bash
# verify-deployment.sh — 本番デプロイ後に毎回実行
set -euo pipefail

ENDPOINT="${1:?usage: verify-deployment.sh <base-url>}"
MAX_ATTEMPTS=12
SLEEP_SECONDS=10

for i in $(seq 1 $MAX_ATTEMPTS); do
  STATUS=$(curl -sf "$ENDPOINT/health/ready" | jq -r '.status' 2>/dev/null || echo "unreachable")
  if [ "$STATUS" = "ok" ]; then
    echo "Health check passed after $((i * SLEEP_SECONDS))s"
    exit 0
  fi
  echo "Attempt $i/$MAX_ATTEMPTS: status=$STATUS — retrying in ${SLEEP_SECONDS}s"
  sleep "$SLEEP_SECONDS"
done

echo "Health check failed after $((MAX_ATTEMPTS * SLEEP_SECONDS))s"
exit 1

ロールバック戦略

パイプラインでの自動ロールバック

deploy-and-verify:
  steps:
    - name: Deploy new version
      run: kubectl apply -f k8s/

    - name: Wait for rollout
      run: kubectl rollout status deployment/my-app --timeout=5m

    - name: Post-deployment health check
      id: health
      run: ./scripts/verify-deployment.sh https://app.example.com

    - name: Rollback on failure
      if: failure()
      run: |
        kubectl rollout undo deployment/my-app
        echo "Rolled back to previous revision"

手動ロールバックコマンド

# change-cause アノテーション付きのリビジョン履歴を一覧表示
kubectl rollout history deployment/my-app

# 前のバージョンへロールバック
kubectl rollout undo deployment/my-app

# 特定のリビジョンへロールバック
kubectl rollout undo deployment/my-app --to-revision=3

# ロールバックが完了したことを確認
kubectl rollout status deployment/my-app

データベース移行ロールバックや Argo Rollouts abort フローを含む高度なロールバック戦略については、references/advanced-strategies.md を参照してください。

モニタリングとメトリクス

追跡すべき主要な DORA メトリクス

メトリク	ターゲット（エリート）	測定方法
Deployment Frequency	複数回/日	1日あたりのパイプライン実行回数
Lead Time for Changes	< 1 時間	コミットタイムスタンプ → 本番デプロイ
Change Failure Rate	< 5%	失敗したデプロイ / 総デプロイ数
Mean Time to Recovery	< 1 時間	インシデント開始 → サービス復旧

デプロイ後のメトリクス検証

- name: Verify error rate post-deployment
  run: |
    sleep 60  # メトリクスが蓄積されるまで待機

    ERROR_RATE=$(curl -sf "$PROMETHEUS_URL/api/v1/query" \
      --data-urlencode 'query=sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))' \
      | jq '.data.result[0].value[1]')

    echo "Current error rate: $ERROR_RATE"
    if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
      echo "Error rate $ERROR_RATE exceeds 1% threshold — triggering rollback"
      exit 1
    fi

パイプラインのベストプラクティス

1. 早期に失敗 — 遅いテスト（E2E、セキュリティスキャン）の前に快速チェック（リント、ユニットテスト）を実行
2. 並列実行 — 独立したジョブを並行実行して総パイプライン時間を最小化
3. キャッシング — 実行間で依存関係レイヤーとビルドアーティファクトをキャッシュ
4. アーティファクト昇格 — 一度ビルド、すべての環境を通じて同じアーティファクトを昇格
5. 環境パリティ — ステージング インフラを本番環境に可能な限り近い状態に保つ
6. シークレット管理 — シークレットストア（Vault、AWS Secrets Manager、GitHub 暗号化シークレット）を使用 — ハードコーディング禁止
7. デプロイメントウィンドウ — 低トラフィック時間帯を優先; ゲートポリシーによるチェンジ フリーズ期間を強制
8. べき等なデプロイ — デプロイの再実行が同じ結果を生成するようにする
9. ロールバック自動化 — ヘルスチェックまたはメトリクしきい値失敗時に自動ロールバックをトリガー
10. デプロイメントへのアノテーション — デプロイメントマーカーをモニタリングツール（Datadog、Grafana）に送信して相関を図る

トラブルシューティング

ヘルスチェックはパイプラインで成功するが本番環境ではサービスが不健康

パイプラインのヘルスチェックがシャローな /ping エンドポイントにヒットしており、データベースに到達不可でも 200 を返しています。実際の依存関係（上のヘルスチェックセクション参照）を検証するディープなレディネスチェックを使用してください。

カナリアデプロイメントが 100% にプロモートされない

Argo Rollouts は自動プロモーションのために有効な AnalysisTemplate を必要とします。Prometheus クエリがデータを返さない場合（例：メトリック名が変更された）、分析は未決定のままでプロモーションが停止します。inconclusiveLimit を追加してロールアウトが無期限に待機するのではなく、迅速に失敗するようにします:

spec:
  metrics:
  - name: error-rate
    failureCondition: "result[0] > 0.05"
    inconclusiveLimit: 2   # 無期限に待機するのではなく、2つの未決定結果の後に失敗
    provider:
      prometheus:
        query: |
          sum(rate(http_requests_total{status=~"5.."}[2m]))
          / sum(rate(http_requests_total[2m]))

ステージングデプロイは成功するが本番ジョブが開始されない

本番環境の保護ルールが構成されていないことを確認します — レビューアーが割り当てられていないということは、承認ゲートが通知なく無期限に待機するという意味です。GitHub Actions では、Settings → Environments → production で既存のユーザーまたはチームに Required reviewers が設定されていることを確認してください。

Docker レイヤーキャッシュが毎回失効し、ビルドが遅い

COPY . . がステージングインストール前に表示される場合、ソースファイル変更が依存関係レイヤーを無効にします。依存関係マニフェストを最初にコピーして再注文します:

# 良い例: 依存関係がソースコードとは別にキャッシュされる
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

ロールバックはデータベースマイグレーションを適用したままにする

サービスロールバックをマイグレーションロールバックなしで実行すると、スキーマ/コード不一致エラーが発生します。マイグレーション前方互換性を最低 1 リリースサイクル（追加のみ）を保つし、マイグレーションとともにアンドゥスクリプトをバージョン管理します:

# migrations/V20240315__add_nullable_column.sql       (前方)
# migrations/V20240315__add_nullable_column.undo.sql  (後方)

古いコードバージョンがすべての環境から完全に廃止されるまで、破壊的マイグレーション（DROP COLUMN、ALTER NOT NULL）を実行しないでください。

高度なトピック

プラットフォーム固有のパイプライン構成、マルチリージョンプロモーションワークフロー、高度な Argo Rollouts パターンについては、以下を参照してください:

• references/advanced-strategies.md — 拡張 YAML の例、プラットフォーム固有の構成（GitHub Actions、GitLab CI、Azure Pipelines）、マルチリージョンカナリアパターン、データベースマイグレーション ロールバック戦略

関連スキル

• github-actions-templates - GitHub Actions 実装パターンと再利用可能なワークフロー
• gitlab-ci-patterns - GitLab CI/CD パイプライン実装
• secrets-management - CI/CD パイプラインでのシークレット処理