SalesforceでSandboxを経て本番へリリースする進め方

こんなことで困っていませんか

• 本番組織の [設定] で項目や自動化を直接変えていて、変更のたびに不安がある[1]
• 変更を試す場所がなく、使っている人に影響が出ないか気になる[1][2]
• Sandbox を使える環境なのに、種別の違いや作り方が分からず使えていない[3][15]
• Sandbox で作った変更を、本番組織へどう移せばよいか決まっていない[5][12]

なぜ起きるのか

Salesforce のヘルプは、本番組織で直接変更を加えることを、通常は勧めていません。小さな変更でも影響が連鎖し、業務が止まるおそれがあるためです。たとえば項目の型を変えると、データが元に戻せなくなる場合があります。[1]

Sandbox は、本番組織から隔離された組織のコピーです。Sandbox での操作は本番組織に影響しないため、開発・テスト・トレーニングに使えます。[2][3]

ただし、本番組織で行ったカスタマイズやデータの変更は、Sandbox には反映されません。本番組織の状態に合わせるには、Sandbox を更新します。[13][16]

Sandbox で作った変更は、リリースの仕組みを使って本番組織に移します。変更セットに含められるのは [設定] から行える変更だけで、レコードなどのデータは含まれません。[5][12]

直し方の選択肢

Sandbox から本番組織へ変更を移す方法は、ヘルプで複数示されています。変更の大きさや体制に合わせて選びます。[12]

• 変更セット：Salesforce の画面で送信変更セットを作り、コンポーネントを追加して本番組織にアップロードし、リリースします[5][12]
• DevOps センター：Sandbox などの開発環境をソース管理のリポジトリにつなぎ、作業項目ごとに変更を追跡して、パイプラインのフェーズ間で移します。複数のチームが環境を共有する場合に向くとされています[12][14]
• DX インスペクターからのリリース：パイプライン全体を使わずに、小さな変更のメタデータと設定データを移す方法です[12][14]
• Sandbox の種別：Developer と Developer Pro は設定（メタデータ）だけのコピー、Partial Copy はサンプルデータ付き、Full はすべてのデータを含む複製です。更新間隔はそれぞれ 1 日・1 日・5 日・29 日です[3][15]

作業の流れ

• Sandbox を作る：[設定] の [クイック検索] に「Sandbox」と入力して [Sandbox] を開き、[新規 Sandbox] から名前と種別を指定して作成します[3][4]
• Sandbox で変更を作って確かめる：Sandbox で変更を加え、関係者に動きを確かめてもらいます。Partial Copy や Full の Sandbox では、ユーザー受け入れテストができます[1][15]
• リリース接続を承認する：本番組織の [設定] で「リリース」と検索して [リリース設定] を開き、Sandbox の横の [編集] から [変更着信を許可] を選んで保存します[6]
• 送信変更セットを作る：Sandbox の [送信変更セット] で変更セットを作り、[追加] でコンポーネントを入れます。[連動関係を参照/追加] で、連動するコンポーネントも加えます[8]
• アップロードする：変更セットの [アップロード] をクリックし、送信先の組織を選んでアップロードします[7]
• 検証してリリースする：本番組織の [受信変更セット] で [検証] を実行し、結果を確かめてから [リリース] をクリックします[9][10]

気をつけること

• アップロードした変更セットは、編集も取り消しもできません。コンポーネントを足すときは、変更セットをコピーしてからもう一度アップロードします[7][11]
• リリースが途中で失敗したときは全体が戻りますが、正常に終わったリリースはロールバックできません[10]
• 変更セットでは、コンポーネントの削除や名前の変更はできません。削除はリリース先の組織の画面で行います[11]
• 本番組織へ Apex をリリースするときは、既定でローカルの Apex テストが実行されます。コードの 75% 以上が単体テストを受けている必要があります[10][11]
• 検証やリリースの間は組織がロックされ、メタデータを変える設定変更ができません。利用の少ない時間帯に行うよう案内されています[1][9][11]
• 送信変更セットは、アップロードから 6 か月で期限が切れ、削除されます[7]