mcpField
P
platform-quick-deploy

platform-quick-deploy

github.com/forcedotcomクラウド・DevOps1.1k2.8k 回インストール1 日前に更新
リポジトリ

platform-quick-deploy について

検証済みのデプロイを Salesforce の Production 組織へ昇格させるスキルです。本番リリースを扱う開発者向けに、組織種別と検証の有効期間を確認し、明示的な承認後にテストを再実行せずクイックデプロイします。

主な機能

  1. 01対象が Production か確認
  2. 02検証ジョブと有効期間の確認
  3. 03デプロイ前の明示的な承認
  4. 04検証ジョブを使ったクイックデプロイ
  5. 05監査用デプロイレポートの保存

活用シーン

  1. 01検証済みの変更を Production 組織へ昇格
  2. 02検証ジョブの有効性を確認
  3. 03本番デプロイの監査レポートを保管

MCP 対応

README には MCP との関係が記載されていません。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/forcedotcom/sf-skills --skill platform-quick-deploy

インストール後、Claude Code で/platform-quick-deployを入力して読み込まれたか確認します。

詳細

本番環境へのクイックデプロイ

以前の sf project deploy validate のジョブ ID を使用して、検証済みのデプロイを本番組織に昇格させます。テストの再実行も、コンポーネントの再検証も行わず、昇格のみを実行します。

前提条件（厳守するゲート）

作業を始める前に、次の 4 項目すべてを確認してください。

  1. ターゲットが本番環境であること ゲートの判定ツールを使って、ターゲットが本当に本番環境であることを確認してください。このツールはデプロイフックと同じ方法で組織を解決し、production|sandbox|scratch|trial|unknown を返します。

    "${CLAUDE_PLUGIN_ROOT}/scripts/sf-deploy-gate" bucket <alias>

    本番環境とは、スクラッチ組織でもサンドボックスでもなく（-- または test.salesforce.com のホストマーカーがない）、トライアル版または Developer Edition 組織でもないことを意味します（SDO のように、orgfarm-*、*.develop.my.salesforce.com、*.pc-rnd.* の各ホスト、または将来のトライアル有効期限が該当します）。これらの兆候がない Dev Hub は本番環境です。

    ターゲットが本番環境でない場合（判定ツールが production 以外を返す場合）→ STOP し、platform-metadata-deploy に案内してください（非本番環境をネイティブに処理します）。unknown は組織の種類を確認できなかったことを意味します（通常は組織レコードが不完全です）。その旨を明確に伝えてください。デプロイゲートは引き続きデプロイを許可しますが、その組織では保存時の自動デプロイはオフのままであり、sf org login web で再認証すると通常は判定が復元されます。

  2. 検証が存在すること

    • .sfdx/last-validation.json が存在する場合は読み取ります（platform-deploy-validate によって残されています）。
    • または、ユーザーにジョブ ID を尋ねます。
    • または、--use-most-recent にフォールバックします（過去 3 日以内に検証されたもの）。

  3. 検証が十分に新しいこと

    • 明示的に指定した --job-id：Salesforce のクイックデプロイ期間に従い、作成から 10 日以内である必要があります。
    • --use-most-recent：作成から 3 日以内である必要があります。
    • 記録された createdAt が期間を超えている場合 → STOP し、まず platform-deploy-validate を実行します。

  4. ユーザーによる明示的な確認

    • 確認ブロック（エイリアス、インスタンス URL、エディション、検証済みコンポーネント数、テスト結果）を表示し、次のように尋ねます。「本番環境にデプロイしますか？（yes/no）」
    • 明示的な「yes」がなければ、先に進んではいけません。

ワークフロー

ステップ 1 — 本番環境の確認バナーを表示する

次の形式を厳守してください。

┌─ PRODUCTION DEPLOY ─────────────────────────────┐
│ Org alias:      <alias>                         │
│ Instance:       <instanceUrl>                   │
│ Edition:        <edition>                       │
│ Validation ID:  <jobId>                         │
│ Validated:      <createdAt> (X days ago)        │
│ Components:     <componentCount> queued         │
│ Tests:          <run>/<passed>/<failed>         │
└─────────────────────────────────────────────────┘
Confirm deploy to PRODUCTION? (yes/no)
ステップ 2 — クイックデプロイを実行する

「yes」の後に実行します。

sf project deploy quick --job-id <id> --target-org <alias> --wait 30 --json

ユーザーが選択した場合は、--use-most-recent を指定して実行することもできます。

クイックデプロイでは、次の処理が行われます。

  • 検証済みコンポーネントを組織に昇格させます。
  • テストは再実行しません（Salesforce プラットフォームの動作に従います）。
  • 最終的なデプロイステータスを返します。
ステップ 3 — デプロイレポートを保存する

完了後、監査用に次の内容を保存します。

mkdir -p .sfdx/deploy-history
sf project deploy report --job-id <id> --target-org <alias> --json > ".sfdx/deploy-history/<id>.json"

ユーザーには次の情報を提示します。

  • ✅ デプロイ成功 — デプロイされたコンポーネント、所要時間
  • ⚠️ デプロイ失敗 — エラーの概要。レポートの確認を推奨します。
ステップ 4 — デプロイ後の案内

本番環境へのデプロイが成功した後、次を提案します。

  • 組織内で重要なパスのスモークテストを実施する（分かっている場合は直接 URL を提示します）。
  • 次の 30 分間、本番環境を監視する。
  • Setup → Deployment Status を確認する。
  • 何かが退行した場合は、ロールバック計画を準備する（前バージョンのパッケージを再デプロイします）。

ルール

  • 本番環境をターゲットに sf project deploy start を実行してはいけません（必ず検証してからクイックデプロイします）。
  • 本番環境で --ignore-errors または --ignore-warnings を使用してはいけません。
  • 確認を自動で行ってはいけません。ユーザーから明示的な「yes」を得る必要があります。
  • 有効期間を過ぎたジョブ ID をクイックデプロイしてはいけません。代わりに再検証します。
  • 監査証跡として、デプロイレポートを必ず .sfdx/deploy-history/ に保存します。
  • prod-check フックが操作を拒否した場合は、回避してはいけません。拒否されたことをユーザーに伝え、まず platform-deploy-validate を実行するよう推奨します。

コメント

Markdown 対応