Salesforce Developer Sandbox 徹底解説：効果的なALMのためのベストプラクティス

日付:

背景と利用シーン

Salesforce の開発において、本番環境（Production Environment）を直接変更することは、ビジネスに深刻な影響を与えるリスクを伴います。そのため、安全な開発・テストプロセスを確立することが不可欠です。このプロセスの中核をなすのが Sandbox (サンドボックス) という、本番環境のコピーです。Salesforce は複数の種類の Sandbox を提供していますが、その中でも最も基本的かつ頻繁に使用されるのが Developer Sandbox です。

Developer Sandbox は、主に開発者個人の開発・テスト作業のために設計された、隔離された環境です。本番組織の Metadata (メタデータ) 、つまり Apex クラス、トリガー、Visualforce ページ、Lightning Web Components (LWC)、カスタムオブジェクト、項目設定などをコピーして作成されます。

主な利用シーン:

  • 新規機能の開発： 新しい Apex ロジック、LWC コンポーネント、フローなどの開発と単体テストを行います。
  • バグ修正： 本番環境で発生した問題の再現と修正作業を行います。
  • 技術検証 (PoC)： 新しい AppExchange アプリケーションの試用や、Salesforce の新機能の動作確認など、小規模な検証作業に利用されます。
  • 個人の学習・トレーニング： 開発者が新しいスキルを習得するための練習環境として活用できます。

Developer Sandbox は、データストレージが 200MB と小規模で、本番のデータはコピーされません。この特性から、大規模なデータセットを必要としない、コード中心の開発タスクに最適です。

原理説明

Developer Sandbox は、作成または更新（リフレッシュ）の時点で、ソースとなる本番組織のメタデータの完全なコピーとしてプロビジョニングされます。

主要な特徴:

  • メタデータのコピー: 上述の通り、アプリケーションの構成情報（コード、オブジェクト定義、レイアウト、権限セットなど）がすべてコピーされます。これにより、本番と同一の構成で開発を開始できます。
  • データの非コピー: 取引先、商談、ケースといった本番のレコードデータは一切コピーされません。開発やテストに必要なデータは、手動で作成するか、データローダや Apex のテストデータファクトリを使用して投入する必要があります。
  • ストレージ制限: データストレージとファイルストレージは、それぞれ 200MB に制限されています。これは、個人の開発作業には十分ですが、大量のデータを扱うテストには不向きです。より多くのデータが必要な場合は、Developer Pro Sandbox や Partial Copy Sandbox を検討します。
  • 更新間隔: Developer Sandbox は、1日に1回リフレッシュが可能です。これにより、最新の本番メタデータ環境を素早く手に入れることができます。ただし、リフレッシュを行うと Sandbox 内の既存の変更はすべて破棄されるため、注意が必要です。
  • メール送信の制限: デフォルトでは、Sandbox からのメール送信は「システムメールのみ」に設定されており、意図しないメールが外部の顧客などに送信されるのを防ぎます。テストでメール送信機能を確認する場合は、設定を「すべてのメール」に変更する必要があります。
  • 一意のユーザ名: Sandbox のユーザ名は、すべての Salesforce 組織で一意である必要があります。通常、本番のユーザ名の末尾に `.sandbox名` が自動的に付与されます (例: `user@example.com.dev1`)。

示例代码

Developer Sandbox は、Apex コードを記述し、単体テストを実行するための主要な環境です。以下に、取引先責任者(Contact)とリード(Lead)を名前で検索する簡単な Apex クラスと、そのテストクラスの公式ドキュメントの例を示します。

Apex クラス: ContactAndLeadSearch.cls

このクラスは、指定されたキーワードに一致する取引先責任者とリードのリストを返す `searchContactsAndLeads` メソッドを提供します。

public class ContactAndLeadSearch {
    public static List<List<SObject>> searchContactsAndLeads(String searchName) {
        // SOSL (Salesforce Object Search Language) を使用して複数のオブジェクトを横断検索
        // FIND句で検索キーワードを指定し、IN句で検索対象の項目を指定
        // RETURNING句で検索対象オブジェクトと、取得したい項目を指定
        List<List<SObject>> searchList = [FIND :searchName IN NAME FIELDS
                                        RETURNING Contact(Name), Lead(Name)];
        return searchList;
    }
}

Apex テストクラス: ContactAndLeadSearch_Test.cls

このテストクラスは、上記の `ContactAndLeadSearch` クラスが正しく動作することを検証します。テストデータを作成し、メソッドを呼び出し、結果が期待通りであることを `System.assertEquals` を用いてアサーションします。

@isTest
private class ContactAndLeadSearch_Test {
    @isTest static void testSearch() {
        // テスト用のデータを作成
        // このデータはテスト実行時のみ存在し、組織のデータベースには保存されない
        Contact testContact = new Contact(LastName = 'Smith');
        insert testContact;
        Lead testLead = new Lead(LastName = 'Smith', Company = 'Test Co');
        insert testLead;

        // テストのガバナ制限をリセットするために Test.startTest() を呼び出す
        Test.startTest();

        // テスト対象のメソッドを呼び出す
        List<List<SObject>> searchResults = ContactAndLeadSearch.searchContactsAndLeads('Smith');
        
        // テストを終了
        Test.stopTest();

        // 結果を検証する
        // 検索結果は2つのリスト（ContactとLead）を含むはず
        System.assertEquals(2, searchResults.size());
        
        // 最初のリスト（Contact）には1件のレコードが含まれていることを確認
        System.assertEquals(1, searchResults[0].size());
    }
}

このようなコードとテストを Developer Sandbox で開発・実行し、コードカバレッジが 75% 以上であることを確認した上で、次のステージ（例えば、統合テスト用の Sandbox）にデプロイします。

注意事項

Developer Sandbox を効果的に活用するためには、いくつかの注意点を理解しておく必要があります。

  • ソース管理との連携: Sandbox は一時的な環境であり、「信頼できる唯一の情報源（Source of Truth）」ではありません。すべての開発成果物（Apex、LWC、メタデータ）は、Git などの Source Control (ソース管理) システムで管理することが強く推奨されます。リフレッシュする前には、必ずすべての変更をリポジトリにコミットしてください。
  • データローディング: テストにはデータが必要です。少量のデータは手動で作成できますが、より現実的なテストを行うためには、データローダや Salesforce DX のデータコマンド (`sfdx force:data:tree:export/import`) を使用してテストデータを投入する戦略を立てましょう。
  • ハードコードされたIDやURLの回避: Sandbox で開発したコード内に、特定のレコードIDや `cs123.salesforce.com` のようなインスタンス固有のURLをハードコードしないでください。これらは本番環境では無効です。カスタムメタデータ型、カスタム設定、または動的なURL解決メソッド（例: `URL.getSalesforceBaseUrl()`）を使用して、環境に依存しないコードを記述してください。
  • リフレッシュのタイミング: Sandbox のリフレッシュは、本番の最新のメタデータを取り込むために重要ですが、進行中の作業をすべて消去します。リフレッシュは、新しい開発スプリントの開始時や、大規模な変更を本番から取り込む必要がある場合など、計画的に実行してください。
  • 権限と可視性: Sandbox のユーザは、本番と同じプロファイルと権限セットを持ちますが、データがないため、アクセス権のテストが難しい場合があります。テストを行う際は、適切なテストデータとユーザを作成し、期待通りに権限が機能するかを確認してください。

まとめとベストプラクティス

Developer Sandbox は、Salesforce の Application Lifecycle Management (ALM) (アプリケーションライフサイクル管理) における出発点であり、開発者が安全かつ効率的に作業を行うための不可欠なツールです。その特性と制限を正しく理解し、ベストプラクティスに従うことで、開発プロセス全体の品質を向上させることができます。

ベストプラクティス:

  1. 一人一つの Sandbox:

     開発者間のコンフリクトを避けるため、原則として開発者一人につき一つの Developer Sandbox を割り当てます。

  2. ソース管理を徹底する:

     すべての変更は Git で管理し、Sandbox は使い捨ての作業環境と位置づけます。これにより、リフレッシュや環境の再作成が容易になります。

  3. 明確な命名規則:

     Sandbox には目的がわかるような明確な名前を付けます（例: `dev_takahashi_caseproj`, `hotfix_sato_case123`）。

  4. 定期的なリフレッシュ:

     開発が長期化すると、Sandbox のメタデータが本番から乖離し、デプロイ時に予期せぬエラーが発生する可能性があります。定期的に（ただし計画的に）リフレッシュを行い、環境を最新の状態に保ちましょう。

  5. 自動化されたテストデータ生成:

     Apex のテストデータファクトリクラスを作成し、再利用可能で一貫性のあるテストデータをプログラムで生成できるようにします。これにより、テストの信頼性が向上します。

  6. 適切な Sandbox を選択する:

     開発タスクには Developer Sandbox を、複数の開発者の変更を統合してテストする際には Developer Pro や Partial Copy Sandbox を、本番に近いデータで負荷テストや最終リハーサルを行う際には Full Sandbox を、というように、目的に応じて適切な種類の Sandbox を使い分けることが重要です。

これらのプラクティスを遵守することで、Developer Sandbox の価値を最大限に引き出し、堅牢で高品質な Salesforce アプリケーション開発を実現することができます。

コメント

コメントを投稿