mcpField
P
platform-deploy-validate

platform-deploy-validate

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

platform-deploy-validate について

Salesforce のメタデータをデプロイ前に検証するスキルです。対象組織に応じてドライランまたは本番検証を選び、本番検証のジョブ ID を `platform-quick-deploy` 用に保存します。

主な機能

  1. 01組織種別に応じた検証方法の選択
  2. 02Sandbox と Scratch Org のドライラン
  3. 03テストを伴う本番検証
  4. 04クイックデプロイ用ジョブ ID の保存
  5. 05コンポーネントとテスト失敗の整理

活用シーン

  1. 01本番デプロイ前のメタデータ検証
  2. 02組織を変更せず Sandbox のデプロイを確認
  3. 03検証時のコンポーネントやテストエラーの分析

インストール

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

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

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

詳細

デプロイの検証

メタデータをデプロイする前に、サーバー側で検証を実行します。検証では組織を変更せずにエラーを検出できます。また、本番環境を対象とする場合は、platform-quick-deploy で高速かつテストなしのデプロイに使用できるジョブ ID が生成されます。

機能の選択

Tooling API を直接使用するよりも、常に sf project deploy validate（本番環境）または sf project deploy start --dry-run（サンドボックス／スクラッチ）を優先してください。

ワークフロー

ステップ 1 — 対象組織の確認

ゲートの分類器を使って組織を分類します。分類器は信頼できる唯一の情報源であり、デプロイフックと同じ方法で組織を判定します（サンドボックス／スクラッチのマーカー、トライアル組織と Developer Edition 組織（SDO を含む）を処理し、そのような情報がない Dev Hub は本番環境として扱います。戻り値は production|sandbox|scratch|trial|unknown のいずれかです）。

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

production の場合のみ本番環境用の手順（ステップ 2b）に進み、それ以外の結果ではサンドボックス／スクラッチ用の手順（ステップ 2a）に進みます。unknown は組織の種類を確認できなかったことを意味します（通常は組織レコードが不完全です）。その旨を明確に伝えてください。デプロイゲートでは引き続きデプロイが許可されますが、その組織では保存時の自動デプロイはオフのままです。通常、sf org login web で再認証すると分類が復元されます。

ステップ 2a — サンドボックス／スクラッチの手順（ドライラン）
sf project deploy start --dry-run --target-org <alias> --json [scope flags]

スコープフラグ（すべてではなく、1 つだけ使用してください）：

  • --source-dir <path> — ディレクトリをデプロイします
  • --metadata <Type:Name> — 特定のコンポーネントをデプロイします
  • --manifest manifest/package.xml — マニフェストからデプロイします

デフォルトのテストレベル：サンドボックスでは --test-level を省略します（組織のデフォルトに委ねます）。ユーザーから依頼があった場合のみ、--test-level RunLocalTests を追加します。

結果として、成功／失敗、試行したコンポーネント、エラーを報告します。ドライランではジョブ ID は返されません（これは想定どおりです）。

ステップ 2b — 本番環境の手順（検証）
sf project deploy validate --target-org <alias> --json [scope flags] --test-level RunLocalTests

本番環境の検証ではテストレベルが必須です。デフォルトでは RunLocalTests を使用します。ユーザーがテストを明示的に指定した場合は、RunSpecifiedTests --tests <ClassName>... に切り替えます。

レスポンスには ジョブ ID（result.id）が含まれ、有効期間は 10 日間です。platform-quick-deploy で使えるように保存してください。

mkdir -p .sfdx
echo '{"jobId":"<id>","createdAt":"<iso8601>","targetOrg":"<alias>","testLevel":"RunLocalTests"}' > .sfdx/last-validation.json

以下を報告します。

  • 検証結果（成功／失敗）
  • ジョブ ID と有効期限（10 日後）
  • テスト結果の概要（実行数／成功数／失敗数）
  • 推奨する次の手順：このジョブ ID を指定した platform-quick-deploy
ステップ 3 — 失敗のトリアージ

検証に失敗した場合は、result.details.componentFailures と result.details.runTestResult.failures を解析して、以下を提示します。

  • コンポーネントエラーの上位 5 件（メッセージ全文付き）
  • テスト失敗の上位 5 件（スタック付き）
  • 推奨する修正（コンポーネント名 → 原因の候補：依存関係の欠落、FLS、構文など）

無関係なメタデータを変更する修正案は提示しないでください。検証で報告された範囲に限定してください。

ルール

  • CLI を呼び出すたびに、必ず --json を使用してください
  • 本番環境を対象とする場合、検証を省略しないでください（このスキルから本番環境に対して sf project deploy start を実行しないでください）
  • 検証時に --ignore-errors や --ignore-warnings を使用しないでください。これらのフラグは検証ではなく、実際のデプロイで使用します
  • ユーザーが事前検証なしで「本番環境にデプロイ」するよう依頼した場合、まず検証を実行し、その後 platform-quick-deploy に引き継いでください（本番環境に対して通常のデプロイを開始しないでください）
  • クイックデプロイスキルが参照できるよう、検証ジョブ ID を .sfdx/last-validation.json に保存してください

出力

必ず以下のいずれかで締めくくってください。

  • ✅ 検証成功 → 次の手順として、ジョブ ID と有効期限を含む platform-quick-deploy、または本番環境以外の場合は platform-metadata-deploy を案内します
  • ❌ 検証失敗 → エラーを分類して列挙し、次の修正に向けた提案を示します

コメント

Markdown 対応