deployment-automation

デプロイ自動化

システムがすでにビルド可能であることを前提に、安全なリリース実行を行う場合にこのスキルを使用します。

deployment-automation は、リポジトリにおける次のリリース実行を担います。

• プレビューリリースと共有可能なレビュー環境
• ステージング → 本番への昇格と承認ゲート
• ロールアウト戦略の選択：置き換え、ローリング、ブルーグリーン、カナリア、段階的ロールアウト
• デプロイ後の検証と停止条件
• ロールバック対応と不適切なリリースの封じ込め
• 既存のデプロイ経路を対象としたリリース強化パッケージ

パッケージを決定する前に、次の関連ドキュメントを読んでください。

• references/deployment-modes-and-boundaries.md
• references/release-packet-templates.md
• references/strategy-selection-and-stop-conditions.md
• references/rollout-and-rollback-checklist.md
• references/platform-routing-notes.md

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

• プレビューまたはブランチのデプロイ環境はあるものの、マージ前に何を確認するためのものなのか、誰も合意できていません。
• リリースは技術的にはすでに動作していますが、ステージング／本番への昇格が依然として暗黙知に依存しています。
• 主な判断事項が、ロールアウト戦略、リリースゲート、検証の深さ、またはロールバックの準備状況です。
• デプロイに失敗し、次に必要なのが広範なプラットフォームの再設計ではなく、封じ込め、ロールバック、安全な復旧です。
• プラットフォーム固有のオペレータースキルを使用する前に、ベンダーに依存しないリリースパッケージが必要です。
• 既存のデプロイ経路に、事前確認、承認ロジック、明示的な停止条件を加えて強化する必要があります。

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

• 主な作業が Docker、kubectl、クラウド CLI のインストール、認証の初期設定、またはマシンの実行可能化である場合 → system-environment-setup
• 主な作業がダッシュボード、アラート、トレース、または長期的なテレメトリーアーキテクチャである場合 → monitoring-observability
• 主な作業が Vercel 固有のリンク設定、ドメイン、エイリアス、環境変数、またはクレーム URL である場合 → vercel-deploy
• システムがまだビルド、パッケージ化、またはテストを実行できない場合 → デプロイ自動化を再検討する前に、ビルド／セットアップの問題を修正してください
• 主な作業がシークレットのローテーション、IAM ポリシー、署名、またはコンプライアンスアーキテクチャである場合 → 該当するセキュリティスキルに引き継いでください

手順

Step 1: リリースプロファイルを確定する

手順を提案する前に、依頼内容を整理してください。

release_profile:
  mode: preview-release | environment-promotion | container-paas-rollout | kubernetes-rollout | rollback-response | release-hardening
  runtime_shape: static-frontend | web-app | api-service | worker-job | multi-service | unknown
  artifact_shape: platform-build | image | build-output | package | unknown
  target_environment: preview | staging | production | mixed | unknown
  promotion_model: same-artifact-promotion | rebuild-per-env | direct-deploy | unknown
  rollout_strategy: replace | rolling | blue-green | canary | progressive | feature-flag-assisted | unknown
  stateful_risk: low | medium | high | unknown
  verification_depth: health-only | smoke-tests | release-checklist | automated-analysis | unknown

実行ごとに、主要な mode を必ず1つ選んでください。

• preview-release — マージまたは昇格の前に共有可能な検証を行う
• environment-promotion — ステージング → 本番、またはゲートを設けた複数環境への昇格
• container-paas-rollout — マネージドアプリ／コンテナプラットフォームのリリース計画
• kubernetes-rollout — ロールアウトコントローラーの動作、停止条件、ロールバック経路
• rollback-response — 不適切なデプロイの封じ込めと復旧
• release-hardening — 既存フローに不足している事前確認、承認、または検証を追加する

Step 2: 必要最小限の事実に基づく証拠を集める

雰囲気でリリースフローをでっち上げないでください。必要最小限の事実を記録してください。

1. 実際に出荷するアーティファクトは何ですか？
2. 現時点で対象となる環境はどこですか？
3. 同じアーティファクトを環境間で昇格させますか。それとも環境ごとに再ビルドしますか？
4. 現在のデプロイコマンド、プロバイダーのアクション、またはコントローラーは何ですか？
5. すでに存在するヘルスチェック、スモークチェック、または承認シグナルは何ですか？
6. 実際のロールバック方法は何ですか？
7. ロールバックが一方向になり得るスキーマ／データ変更はありますか？

答えが不明な場合は、そのことを明示し、安全側に最小限の解釈をしてください。

Step 3: 境界を早い段階で明確にする

パケットを生成する前に、以下の振り分け先を使用してください。

リクエストの実際の内容	振り分け先
Docker／kubectl／クラウド CLI のインストール、認証の初期設定、マシンの準備状況	system-environment-setup
ダッシュボード、アラート、トレース、ログパイプライン、SLO モニタリング	monitoring-observability
Vercel プロジェクトのリンク、エイリアス、ドメイン、環境変数、Vercel のデプロイ方法	vercel-deploy
シークレットのローテーション、IAM スコープ、署名、アテステーション、コンプライアンスの証跡	セキュリティスキル
ロールアウトの選択、昇格ゲート、検証、ロールバックパケット	deployment-automation

Step 4: 入口を拡張するのではなく、適切なサポートパケットを読み込む

分類したら、対応するリファレンスパケットを使用してください。

• preview-release → references/release-packet-templates.md#preview-release-packet
• environment-promotion → references/release-packet-templates.md#environment-promotion-packet
• container-paas-rollout → references/release-packet-templates.md#containerpaas-rollout-packet
• kubernetes-rollout → references/release-packet-templates.md#kubernetes-rollout-packet
• rollback-response → references/release-packet-templates.md#rollback-response-packet
• release-hardening → references/release-packet-templates.md#release-hardening-packet

replace／rolling／blue-green／canary／progressive の各方式から選ぶ場合は、references/strategy-selection-and-stop-conditions.md を使用してください。 最終決定の前に、最低限のリリース安全チェックリストとして references/rollout-and-rollback-checklist.md を使用してください。

Step 5: リリース実行ルールを適用する

• ビルドとリリースを分けてください。 ビルドが成功しても、リリースが安全であるとは限りません。
• デプロイと公開を分けてください。 トラフィックの切り替え、昇格ゲート、フィーチャーフラグは、最初のデプロイコマンドより重要な場合があります。
• アプリのロールバックとデータのロールバックを分けてください。 決して両者が同じだと示唆しないでください。
• チームの検証成熟度に合った、最小限のロールアウト戦略を優先してください。
• 再現性が重要な場合は、同一アーティファクトの昇格を優先してください。 環境ごとにシステムを再ビルドする場合は、そのリスクを明示してください。
• 検証は必須です。 ヘルスチェックと主要フローを1つ実施することが、最低限の完了条件です。
• 楽観視せず、停止条件を優先してください。 昇格を停止すべき条件、またはロールバックを開始すべき条件を明記してください。

Step 6: DevOps の講義ではなく、リリースパケットを作成する

出力には必ず以下を含めてください。

# Release Packet
- Mode:
- Runtime / provider:
- Artifact:
- Environment(s):
- Promotion model:
- Rollout strategy:

## Preconditions
- Existing deploy path:
- Required auth/config:
- Known blockers / migrations:

## Steps
1. ...
2. ...
3. ...

## Verification
- Health checks:
- Smoke checks:
- Human/automatic sign-off:
- Stop conditions:

## Rollback / recovery
- Immediate rollback path:
- What rollback does not undo:

## Handoffs
- Adjacent skills or provider-specific follow-up:

Step 7: ラッパーの乱立より、堅牢化を優先する

リクエストが「デプロイが煩雑だ」という内容であれば、以下を優先してください。

1. リリースモードを分類する。
2. 現在の信頼できる情報源を明示する。
3. 事前確認／検証／ロールバックの構成を追加する。
4. プラットフォーム固有の詳細は、適切な隣接スキルに振り分ける。

新たな汎用デプロイラッパーを作ったり、Kubernetes の全般を再説明したり、CI の作成をこのスキルに取り込んだりしてはいけません。

出力形式

以下を返してください。

1. 選択したリリースモード
2. 収集した証拠と不明点
3. 根拠を添えたロールアウト戦略
4. 検証計画
5. ロールバックまたは復旧計画
6. 振り分け先または残るリスク

例

例 1: プレビューのデプロイに関する混乱

入力：「すべての PR にプレビュー URL が割り当てられますが、レビュー担当者は壊れたフローを承認し続けています。マージ前にデプロイプロセスで実際に何を必須にすべきですか？」

出力の形式：preview-release と分類し、プレビューで確認できる内容を定義し、スモークチェックを列挙し、プレビューの検証と、その後のステージング／本番への昇格を分けます。

例 2: ステージングから本番への昇格

入力：「ステージングには自動でデプロイしていますが、本番への昇格は今も手動の Slack 上の儀式になっています。最も安全なリリースパケットを作成してください。」

出力の形式：environment-promotion と分類し、アーティファクトとゲートを明示し、昇格後のチェックを必須にし、スキーマに関する注意点とロールバックを指定します。

例 3：本番環境へのデプロイ失敗

入力：「最新リリースが本番環境でタイムアウトしており、マイグレーションも含まれていました。最も安全なロールバック計画が必要です。」

出力形式：rollback-response と分類し、影響範囲を限定して、アプリのロールバックとマイグレーションのリスクを分け、復旧後の検証を定義します。

ベストプラクティス

1. 最初に示すのはプラットフォームの百科事典ではなく、リリースに関する判断事項にします。
2. 提案を行う前に、実際の成果物、環境、ロールバック手順を明示します。
3. オペレーターがプレッシャーのかかる状況でも実行できる、短いリリース用パケットを優先します。
4. プロバイダー固有の懸念事項や関連する懸念事項は、早い段階で別の担当先に回します。
5. 検証と停止条件は、任意の仕上げではなく必須の出力として扱います。

参考資料

• Kubernetes Deployments
• Argo Rollouts
• Vercel Deployments