SKILLOfficialdevelopment

platform-quick-deploy

プラグイン: salesforce-development
ソース: GitHub で見る ↗

説明

検証済みのメタデータ（Salesforce内の設定情報）を本番環境に展開し、テストの再実行をスキップします。 **次のような場合に使用:** - ユーザーが本番環境への展開を希望している - 「クイックデプロイ」「プロモート」「本番環境に送出」などの指示がある - 検証済みの状態で、その変更をすぐに反映させたい **必須条件:** 最近実行した `sf project deploy validate` コマンドのジョブID（10日以内、または `--use-most-recent` オプション使用時は3日以内）が必要です。 **使用してはいけない場合:** - サンドボックス環境やスクラッチ環境への展開（代わりに platform-metadata-deploy を使用） - 未検証の状態での展開（事前に platform-deploy-validate を使用してください）

原文を表示

Deploy validated metadata to a Production Salesforce org without re-running tests. TRIGGER when the user wants to deploy to production, says 'quick deploy', 'promote', 'ship to prod', or has just validated and wants to push the change live. REQUIRES a recent `sf project deploy validate` job ID (≤10 days old, ≤3 days for --use-most-recent). DO NOT TRIGGER for sandbox/scratch deploys (use platform-metadata-deploy) or unvalidated deploys (use platform-deploy-validate first).

ユースケース

検証済みメタデータを本番環境に展開する
クイックデプロイやプロモートを実行する
変更をすぐに本番環境に反映させたい

本文（日本語訳）

本番環境への迅速なデプロイ

以前実行した sf project deploy validate（デプロイの事前検証）から得たジョブIDを使って、検証済みのデプロイを本番環境に昇格させます。テストの再実行や部品の再検証は行わず、昇格処理のみを実施します。

実行前の確認項目（厳密にチェック）

何をする前に、以下の4つをすべて確認してください：

1. 対象が本番環境か確認する

対象がほんとうに本番環境かを、ゲート（検証装置）の分類機能で確認します。この分類機能はデプロイフックと同じ方法で環境を判定し、production|sandbox|scratch|trial|unknown を返します：

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

本番環境とは、スクラッチ環境やサンドボックス（-- や test.salesforce.com のホスト名がない）および試用環境・開発者用環境ではないもの（orgfarm-*、*.develop.my.salesforce.com、*.pc-rnd.* のホスト名、または将来の試用期限が記載されているもの（SDO（Salesforce Demo Org）など）を除く）ことを意味します。これらの特徴がないDev Hub（開発用ハブ）は本番環境です。

対象が本番環境でない場合（分類機能が production 以外を返した場合）→ 処理を中止し、platform-metadata-deploy（非本番環境に対応）にリダイレクトしてください。unknown は環境タイプが確認できなかったことを意味します（通常は環境の記録が不完全）。率直にユーザーに伝え、デプロイゲートは処理を許可していること、その環境では自動デプロイが無効なこと、sf org login web で再認証すれば通常は分類が復旧することを説明してください。

2. 検証済みジョブが存在するか確認する

以下のいずれかから検証済みジョブを取得します：

.sfdx/last-validation.json が存在すればそこから読み込む（platform-deploy-validate が作成）
またはユーザーにジョブIDを入力してもらう
または --use-most-recent にフォールバック（過去3日以内の検証を使用）

3. 検証が新しいか確認する

明示的なジョブID指定時 → Salesforceの迅速デプロイ対応期間である10日以内であること
--use-most-recent 使用時 → 3日以内であること
記録された createdAt がこの期間を超えている場合 → 処理を中止し、先に platform-deploy-validate を実行してください

4. ユーザーの明示的な確認を得る

確認ブロックを表示し（エイリアス、インスタンスURL、エディション、検証済み部品数、テスト結果を含む）、「本番環境へのデプロイを実行しますか？（はい/いいえ）」と尋ねます。明確な「はい」なしには先に進まないでください。

実行手順

ステップ1：本番環境デプロイの確認バナーを表示

以下の形式で表示してください：

┌─ 本番環境デプロイ ─────────────────────────────┐
│ 環境エイリアス:  <alias>                       │
│ インスタンス:    <instanceUrl>                 │
│ エディション:    <edition>                     │
│ 検証ID:         <jobId>                        │
│ 検証日時:        <createdAt> (X日前)           │
│ 部品数:         <componentCount> 件 待機中     │
│ テスト:         <run>件実行/<passed>件成功/<failed>件失敗 │
└─────────────────────────────────────────────────┘
本番環境へのデプロイを実行しますか？（はい/いいえ）

ステップ2：迅速デプロイを実行

「はい」と答えた後：

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分間、本番環境を監視する
設定 → デプロイメント状況で確認する
何か問題が起きた場合：ロールバック計画を準備する（前バージョンのパッケージを再度デプロイ）

厳守事項

決して sf project deploy start を本番環境に対して実行しない（必ず検証してから迅速デプロイを使う）
決して 本番環境で --ignore-errors（エラーを無視）や --ignore-warnings（警告を無視）を使わない
決して 自動確認しない — ユーザーからの明確な「はい」を要求する
決して 有効期限を過ぎたジョブIDで迅速デプロイしない — 代わりに再検証する
必ずデプロイレポートを .sfdx/deploy-history/ に保存して監査証跡を残す
本番環境チェックのゲートがその操作を拒否した場合、決して 迂回しない — ユーザーに拒否を伝え、先に platform-deploy-validate を実行することを推奨する

原文（English）を表示

Quick Deploying to Prod

Promote a validated deploy to a Production org using the job ID from a prior sf project deploy validate. No tests re-run, no components re-validated — just the promotion.

Preconditions (gate strictly)

Before doing ANYTHING, verify all four:

Target is Production Confirm the target really is production with the gate's classifier, which resolves the org the same way the deploy hook does (returns production|sandbox|scratch|trial|unknown):
```
"${CLAUDE_PLUGIN_ROOT}/scripts/sf-deploy-gate" bucket <alias>
```
Production means not a scratch org or sandbox (no -- or test.salesforce.com host marker) and not a trial/Developer Edition org (orgfarm-*, *.develop.my.salesforce.com, *.pc-rnd.* hosts, or a future trial expiration date, as on SDOs). A Dev Hub with none of those signals is production.

If target is NOT production (classifier returns anything other than production) → STOP and redirect to platform-metadata-deploy (which handles non-prod natively). unknown means the org type could not be confirmed (usually an incomplete org record). Say so plainly: the deploy gate still allows the deploy, auto-deploy on save stays off for that org, and re-authenticating with sf org login web usually restores the classification.
A validation exists
- Read .sfdx/last-validation.json if it exists (left there by platform-deploy-validate)
- OR ask the user for the job ID
- OR fall back to --use-most-recent (validates within last 3 days)
Validation is fresh enough
- Explicit --job-id: must be ≤10 days old per Salesforce's quick-deploy window
- --use-most-recent: must be ≤3 days old
- If the recorded createdAt exceeds the window → STOP and run platform-deploy-validate first
Explicit user confirmation
- Print a confirmation block (alias, instance URL, edition, validated component count, test results) and ask: "Confirm deploy to PRODUCTION? (yes/no)"
- Do NOT proceed without an explicit "yes"

Workflow

Step 1 — Display the production confirmation banner

Format exactly:

┌─ 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)

Step 2 — Run the quick deploy

After "yes":

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

Or with --use-most-recent if the user opted in.

The quick deploy will:

Promote the validated components to the org
NOT re-run tests (per Salesforce platform behavior)
Return final deploy status

Step 3 — Capture the deploy report

After completion, persist for audit:

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

Surface to the user:

✅ Deploy succeeded — components deployed, time taken
⚠️ Deploy failed — error summary; recommend looking at the report

Step 4 — Post-deploy guidance

After a successful prod deploy, suggest:

Smoke-test critical paths in the org (provide direct URLs if known)
Monitor the prod environment for the next 30 min
Check Setup → Deployment Status to confirm
If anything regressed: prepare a rollback plan (re-deploy the previous version's package)

Rules

NEVER run sf project deploy start against a Production target (always validate then quick-deploy)
NEVER use --ignore-errors or --ignore-warnings on production
NEVER auto-confirm — require an explicit "yes" from the user
NEVER quick-deploy a job ID older than its validity window — re-validate instead
ALWAYS persist the deploy report to .sfdx/deploy-history/ for the audit trail
If the prod-check hook denies the operation, do NOT bypass it — surface the denial to the user and recommend platform-deploy-validate first

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。