SalesforceにおけるSandboxの作成とそのポイント

SalesforceにはSandboxというテスト環境がある

SalesforceにはSandboxと呼ばれるテスト環境があります。 本番環境のことをproduction、テスト環境のことをSandboxと呼び、ログイン環境がそもそも違います。Sandbox環境にログインする場合は「Sandboxログイン」というログインボタンがあり、本番環境とは入り口自体、すなわちサーバー環境自体が違うことが明示されています。 ログイン時のユーザ名も、たとえば本番が「abc@company.com」だとしたら、「abc@company.com.dev」と言ったようにsandbox名をつけてログインする形になります。

Salesforceの本番環境とSandboxの違い

SalesforceにおけるSandboxは本番環境と同じ環境でテストをするという点ではほぼ同じものですが、細かい部分で違っていることがあります。 また、どういうシーンで使うべきかなどのポイントもあります。

Sandboxは開発したものをテストする環境

まず大原則としてSandboxは開発したものをテストする環境です。 初期導入時の設定で、ApexやVisualforce、Auraコンポーネントなどの開発がいらない場合は、「Sandboxを使わない」という選択をしても良いという点が重要です。

Sandboxは必ずしも使わなくて良い

開発を伴わない設定を行う場合でも、すでに運用が始まっているSalesforce環境においては影響を考えてSandboxを利用するのが基本です。 しかし、これが全くの新規構築であれば、ある程度構築するまでは（または初期運用を開始するまでは）本番環境のみを使い、運用開始後に本番環境とテスト環境を分けなくてはならないシーンが出たら初めてSandboxを使うという考え方もあります。 これは後述するリリースという作業にも影響する話になりますが、とにかく「猫も杓子もSandbox作成」としてしまうと作業効率という面で支障が出る可能性があるので「Sandboxは必ずしも使わなくて良い」という視点も必要です。

Sandboxを作成する際の注意点

Sandboxを作成して運用する場合、本番環境とは異なる点がいくつかあることに注意を払う必要があります。 よくある注意点について解説をして行きます。

ユーザのメールアドレス

1つはユーザのメールアドレスです。本番環境からSandboxを作成しようとすると、本番環境のユーザがコピーされて登録されるのですが、メールアドレスには「.invalid」がついてしまいます。 これはSandbox環境でのメール配信が無駄に多くのメール配信にならないようにというSalesfore側の配慮ではあるのですが、メール通知を使っている環境であれば注意が必要です。 Sandbox環境でもメール通知をしたい場合はユーザ設定でメールアドレスを確認することをお勧めします。

メールの「配信到達性」の設定

実は上述したユーザのメールアドレスから「.invalid」を削除したとしてもSalesforceからのメールはほぼ配信されません。 作成したSandbox組織の設定画面から配信到達性を設定し、「システムメールのみ」となっている設定を「すべてのメール」に変更することで、Sandboxからもメールを受信することができるようになります。 これはSandboxを作成して本番環境と並行して運用する場合に、Sandboxから意図しないメールが送信されないようにするというSalesforce側の配慮によるものです。（但し、メールタイトルには「Sandbox:」とつくので本番環境からのメールとの区別はつきます。） Sandboxを使う場合は、こういった点を押さえておきましょう。

データ容量（ストレージ）の制限

Salesforceライセンスの契約内容によって異なりますが、1つの本番環境に対してSandboxはいくつも作れるようになっています。 しかし、無尽蔵に容量が提供されている訳ではなく、本番環境のストレージ容量に対してSandboxのストレージ容量は制限されています。 たとえば開発環境としてよく使用される「Developer」というタイプでは200MBしか容量がありません。データのインポートを行ってテストをしたいという場合には、インポートするデータの容量によってはすぐに上限に達してしまうことがあるので注意が必要です。

Sandboxの作成のしかた

Sandboxの作成は簡単です。 しかし、Salesforceの本番環境を元に作成することが基本になります。例えば、ユーザ登録や決まっているカスタムオブジェクト、カスタム項目などは一通り作ってからSandboxを作成するといいでしょう。

システム管理者が設定画面から作成する

Sandboxの作成はSalesforceの設定画面から行います。 設定画面のホーム→検索で「Sandbox」と入れれば設定画面に入れます。メインの「Sandbox」タブにある「新規Sandbox」ボタンをクリックすることで作成画面が開きます。 ここで、Sandboxライセンスを選ぶことになりますが、選べるものは「Developer」「Developer Pro」「Partial Copy」「Full」のいずれかになります。 但し、本番環境のライセンスの種類によっては上記の中からも限られたsandboxライセンスしか選べない点に注意が必要です。

作成のタイミングは開発規模、設定内容によって異なる

前述の通り、Sandbox作成のタイミングは開発規模や設定内容によって異なります。小規模かつ開発がなく設定のみで構築が完了する場合は、あえてSandboxを使用しない選択肢もあります。 運用が開始され、新たな設定や開発が発生する場合は、運用している本番環境と、次期バージョンのSandbox環境を用意する必要が出て来ますが、そうでない限りは本番環境のみの運用で問題ありません。 しかし、規模が一定以上の場合、あるいは運用が開始されている場合、更に言えば開発が入っている場合はテスト用のSandbox環境を持っておく必要があります。逆に言うとこのようなケースでSandbox環境を作らないのは無謀です。 従って、本番環境だけで初期構築した場合は運用開始後、そうでなければ構築当初からSandboxを作成することになります。

Sandboxを使う場合の注意点

Sandboxを作成すること自体は元となる本番環境があれば簡単にできますが、実際にSandboxを使う際には、本番環境との絡みで言うと注意するべき点がいくつかあります。

Sandboxで運用する場合、本番へのリリース作業が必要となる

Sandboxで運用する場合、その環境で設定したり開発をした内容は本番環境に移送する必要があり、これをリリース作業と言います。 具体的には「送信変更セット」をSandbox側から送信し、「受信変更セット」として本番環境側で受信するという作業を実施します。 また、変更セットを受信した本番環境側では「検証」という作業を行ったうえで「リリース」という作業を行い、本番環境に正式にリリースされます。

本番リリース時の注意点

本番リリース時の注意点としては「設定」と「開発」を分けて行うことです。 「設定」で起きるエラーはコンポーネントが不足しているなどの理由が多いですが、「開発」で起きるエラーはコードカバー率など「設定」とは全く理由が違います。 ApexやVisualforceで開発したプログラムは「開発」として別個に分け、それ以外の内容を「設定」として別々に検証・リリースを行うことで、検証・リリース時に発生したエラーを切り分けることが容易になります。

本番リリースで反映されないこと

本番リリースを行っても反映されないことがある点にも注意が必要です。 (1)標準オブジェクトの選択リストの項目 標準オブジェクトの選択リストの内容は手作業で追加編集したものである場合は、リリースしても反映されませんので、Sandboxで追加編集したものは本番環境でも手動で追加編集しないといけません。但し、「グローバル選択リスト値」を設定した場合はその必要がなくなります。 (2)非公開レポート Sandboxにある非公開レポートは本番環境にはリリースされませんので、公開レポートにしておく必要があります。 (3)プロセスビルダーのバージョン違い プロセスビルダーはフローの中でリリースすることが可能ですが、「どれを有効化するか」というところまではフォローされないため、リリース後に個別で見直して最新バージョンを有効化するように手動設定しなくてはなりません。

Sandboxを作成してSalesforceの開発を効率的に

Salesforceの構築運用においてSandboxを作成することは作業の効率化につながります。 本記事では本番環境とテスト環境という2つの軸でしかお伝えしておりませんでしたが、開発用テスト環境としてのSandbox、お客様確認用のSandbox、バックアップ用のSandboxなど、目的に応じてSandboxを増やして使い分けることは非常に重要です。 きちんと目的を整理して、必要に応じてSandboxを作成して管理をすることで、Salesforceの開発は効率的になります。]]>