deployment-pipeline-design

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

承認ゲートとデプロイ戦略を備えた、多段階 CI/CD パイプラインのアーキテクチャパターンです。

このスキルを使用しない場合

• タスクがデプロイメントパイプラインの設計に関係しない場合
• この範囲外の別の分野やツールが必要な場合

手順

• 目標、制約、必要な入力を明確にします。
• 関連するベストプラクティスを適用し、結果を検証します。
• 実行可能な手順と検証方法を提示します。

目的

適切なステージ構成と承認ワークフローによって速度と安全性のバランスを取り、堅牢で安全なデプロイメントパイプラインを設計します。

このスキルを使用する場合

• CI/CD アーキテクチャを設計する
• デプロイメントゲートを実装する
• マルチ環境パイプラインを構成する
• デプロイメントのベストプラクティスを確立する
• 段階的デリバリーを実装する

パイプラインのステージ

標準的なパイプラインフロー

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

ステージの詳細

1. ソース - コードをチェックアウトします
2. ビルド - コンパイル、パッケージ化、コンテナ化を行います
3. テスト - 単体テスト、統合テスト、セキュリティスキャンを実行します
4. ステージングへのデプロイ - ステージング環境にデプロイします
5. 統合テスト - E2E テスト、スモークテストを実行します
6. 承認ゲート - 手動承認を必須にします
7. 本番環境へのデプロイ - カナリア、ブルーグリーン、ローリング方式でデプロイします
8. 検証 - ヘルスチェックとモニタリングを行います
9. ロールバック - 失敗時に自動でロールバックします

承認ゲートのパターン

パターン 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: |
        # Deployment commands

パターン 2：遅延デプロイ

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

パターン 3：複数承認者

プラットフォームで実際に設定されている保護環境の承認ポリシーを構成し、誰が承認またはバイパスできるかを確認します。Azure の場合は、手動検証を任意のデプロイメントフックに配置するのではなく、インストール済みタスクのバージョンと、そのタスクがサポートするエージェントレスジョブに結び付けます。必要な承認者と証跡を記録します。通知は承認の代わりにはなりません。

デプロイメント戦略

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1

特徴：

• 段階的にリリースします
• 可用性は、準備状況、容量、変更内容の互換性によって左右されます
• ロールバックが容易です
• ほとんどのアプリケーションに適しています

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

# Blue (current)
kubectl apply -f blue-deployment.yaml
kubectl patch service my-app --type merge -p '{"spec":{"selector":{"app":"my-app","version":"blue"}}}'

# Green (new)
kubectl apply -f green-deployment.yaml
# Test green environment
kubectl patch service my-app --type merge -p '{"spec":{"selector":{"app":"my-app","version":"green"}}}'

# Rollback if needed
kubectl patch service my-app --type merge -p '{"spec":{"selector":{"app":"my-app","version":"blue"}}}'

特徴：

• 即時に切り替えられます
• ロールバックが容易です
• 一時的にインフラコストが倍増します
• リスクの高いデプロイメントに適しています

3. カナリアデプロイメント

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

特徴：

• トラフィックを段階的に切り替えます
• リスクを軽減できます
• 実際のユーザーを対象にテストできます
• サービスメッシュまたは同様の仕組みが必要です

4. フィーチャーフラグ

from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key="API_KEY")

if flagsmith.has_feature("new_checkout_flow"):
    # New code path
    process_checkout_v2()
else:
    # Existing code path
    process_checkout_v1()

特徴：

• リリースせずにデプロイできます
• A/B テストを実施できます
• 即時にロールバックできます
• きめ細かく制御できます

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

マルチステージ実装の要件

ビルドは一度だけ行い、コミットと変更不可能なアーティファクトのダイジェストを記録します。そのアーティファクトに対してテストとセキュリティチェックを実行し、承認されたステージング環境にデプロイして統合チェックを実施した後、設定済みの本番環境承認を取得し、同じダイジェストのまま段階的にトラフィックを増やしてデプロイします。各ジョブで、それぞれチェックアウト、ロック済みツール、必要な範囲に限定した認証情報、アーティファクトの受け渡しを確立します。昇格の前にロールアウトとアプリケーションのメトリクスを検証します。カナリアをただちに昇格させて、観察期間を省略してはいけません。通知には、明示的に設定された承認済みの受信者と宛先が必要です。

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

1. 素早く失敗させる - まず時間のかからないテストを実行します
2. 並列実行 - 独立したジョブを同時に実行します
3. キャッシュ - 実行間で依存関係をキャッシュします
4. アーティファクト管理 - ビルドアーティファクトを保存します
5. 環境の同等性 - 環境間で一貫性を保ちます
6. シークレット管理 - シークレットストア（Vault など）を使用します
7. デプロイメント時間帯 - 適切な時間帯にデプロイをスケジュールします
8. モニタリングとの連携 - デプロイメントのメトリクスを追跡します
9. ロールバックの自動化 - 失敗時に自動でロールバックします
10. ドキュメント化 - パイプラインの各ステージを文書化します

ロールバック戦略

自動ロールバック

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

    - name: Wait for rollout
      run: kubectl rollout status deployment/my-app

    - name: Health check
      id: health
      run: |
        for i in {1..10}; do
          if curl -sf https://app.example.com/health; then
            exit 0
          fi
          sleep 10
        done
        exit 1

    - name: Rollback on failure
      if: failure()
      run: kubectl rollout undo deployment/my-app

手動ロールバック

# List revision history
kubectl rollout history deployment/my-app

# Rollback to previous version
kubectl rollout undo deployment/my-app

# Rollback to specific revision
kubectl rollout undo deployment/my-app --to-revision=3

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

主要なパイプライン指標

• デプロイ頻度 - デプロイの実行頻度
• リードタイム - コミットから本番環境への反映までの時間
• 変更失敗率 - 失敗したデプロイの割合
• 平均復旧時間（MTTR） - 障害から復旧するまでの時間
• パイプライン成功率 - 成功した実行の割合
• パイプラインの平均所要時間 - パイプラインの完了までにかかる時間

モニタリングとの統合

測定済みのベースライン、最小トラフィック量、観測間隔、妥当な閾値を定義します。検証済みのメトリクスエンドポイントに、上限を設定したタイムアウトでクエリを実行し、プロバイダーのステータス、結果の形式、数値を検証します。メトリクスが欠落している、空である、または形式が不正な場合は、検証が不完全であり、健全な結果として扱ってはなりません。検証を実施できない場合は、昇格を停止してエスカレーションします。一定時間の待機とシェルでの比較だけでは、デプロイの健全性を確認できません。

承認とオーケストレーションのチェックリスト

アーティファクトを不変のコミット／イメージダイジェストに紐付け、正確なターゲットと既存のデプロイ識別情報を確認し、本番環境では保護された環境の承認を必須にして、健全性の判定基準と明示的なロールバック先のリビジョンを記録します。各ジョブは独自のチェックアウト／ランタイムで実行されます。前のランナーのファイルシステムが引き続き利用できると想定せず、検証済みのアーティファクトを転送してください。これらは概要を示す例であり、認証情報やオーケストレーションの完全なテンプレートではありません。追加のプレイブックは不要です。

関連するスキル

• github-actions-templates - GitHub Actions の実装用
• gitlab-ci-patterns - GitLab CI の実装用
• secrets-management - シークレットの取り扱い用

制限事項

• タスクが上記の説明範囲に明確に該当する場合に限り、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中止して確認してください。