Salesforce Scratch Orgの深掘り：使い捨て環境で開発を加速

日付:

背景とアプリケーションシナリオ

今日の複雑なSalesforce開発環境において、効率性と品質を両立させることは開発チームにとって常に挑戦です。従来のSalesforce開発では、開発者が共有のサンドボックス（Sandbox）を使用することが一般的でした。しかし、このアプローチにはいくつかの課題が存在します。

例えば、複数の開発者が同時に同じサンドボックスで作業する場合、メタデータ（Metadata）の競合が発生しやすく、意図しない変更が他の開発者の作業に影響を与える可能性があります。また、新しい機能開発やバグ修正のために環境をセットアップするのに時間がかかり、再現性の低い問題のデバッグが困難になることも少なくありません。さらに、CI/CD（継続的インテグレーション/継続的デプロイメント - Continuous Integration/Continuous Deployment）パイプラインへの統合も、サンドボックスの性質上、一定の制約がありました。

これらの課題を解決するために、SalesforceはSalesforce DX（開発者エクスペリエンス - Developer Experience）という新しい開発パラダイムを導入しました。Salesforce DXの核となる概念の一つが、本稿のテーマであるScratch Org（スクラッチ組織）です。Scratch Orgは、開発者がいつでもオンデマンドで作成できる、使い捨てのSalesforce環境（Disposable Salesforce Environments）です。

Scratch Orgは、その名の通り「スクラッチから」作成され、定義ファイルに基づいて特定の機能や設定を持つ完全に独立した環境を提供します。これにより、開発者は他の開発者の作業に影響を与えることなく、自身の作業に集中できます。ソースコード管理システム（Version Control System: VCS - バージョン管理システム）を唯一の真実の源（Single Source of Truth）として使用し、メタデータをバージョン管理下に置くことで、開発プロセス全体の再現性と一貫性が大幅に向上します。

Scratch Orgの主なアプリケーションシナリオは以下の通りです：

  • 新機能開発： 各開発者が完全に独立した環境で新機能を実装し、他の開発者との競合を最小限に抑えます。
  • バグ修正と再現： 特定のバグを隔離された環境で再現し、修正した後、安全にテストできます。
  • 単体テストと統合テスト： テスト実行のためのクリーンな環境を迅速にプロビジョニングし、自動化されたテストプロセスに組み込みます。
  • パッケージ開発： アンマネージドパッケージ（Unmanaged Package）やマネージドパッケージ（Managed Package）の開発において、クリーンなインストール環境やテスト環境を提供します。
  • CI/CDパイプライン： 自動テストの実行、検証デプロイ、パッケージのビルドなど、CI/CDプロセスにおいて一時的かつ再現性のある環境として活用されます。
  • トレーニングとデモンストレーション： 特定の機能セットを持つOrgを簡単に作成し、トレーニングや顧客へのデモンストレーションに使用します。

Scratch Orgは、現代のSalesforce開発において不可欠なツールとなっており、開発の俊敏性、品質、そしてチーム全体の生産性を飛躍的に向上させる可能性を秘めています。

原理説明

Scratch Orgは、Salesforce DXの中核をなす概念であり、開発者がコードファーストのアプローチでSalesforceアプリケーションを構築するための基盤を提供します。その原理は、従来のサンドボックスとは大きく異なります。

Scratch Orgとは

Scratch Orgは、一時的（Ephemeral）、ソース追跡可能（Source-tracked）、かつ高度に設定可能なSalesforce組織です。これらは特定の開発プロジェクトのために作成され、役割を終えると簡単に破棄できます。開発者は自身のローカル環境にSalesforce CLI（コマンドラインインターフェース - Command Line Interface）をインストールし、そこからDev Hub（開発ハブ）と呼ばれる特別なSalesforce組織を通じてScratch Orgを管理します。

Dev HubとScratch Orgの連携

Scratch Orgを作成するには、まずDev Hubが有効になっている組織が必要です。Dev Hubは、Salesforce CLIを通じてScratch Orgを作成、管理、追跡するための「親」組織の役割を果たします。通常、Dev Hubは本番組織（Production Org）または長期的な開発に使用される組織（例：特定の開発チームの共有Dev Hub）に設定されます。

定義ファイルによるOrgのプロビジョニング

Scratch Orgは、project-scratch-def.jsonという定義ファイルに基づいて作成されます。このJSONファイルは、作成されるScratch OrgのEdition（エディション）、有効にする機能（Features）、組織の設定（Settings）、名前空間（Namespace - パッケージ開発の場合）などを詳細に定義します。これにより、開発チームはプロジェクトに必要な特定のSalesforce環境を、誰でも、どこでも、一貫した方法で再現できるようになります。

ソースの真実の源としてのバージョン管理システム

Salesforce DXの哲学は、すべてのメタデータがバージョン管理システム（VCS）にあるべきだというものです。Scratch Orgは、ローカルファイルシステム上のソースコードとメタデータを同期するために設計されています。開発者はSalesforce CLIコマンドを使用して、ローカルの変更をScratch Orgにプッシュ（Deploy）したり、Scratch Orgで行われた変更をローカルにプル（Retrieve）したりできます。この双方向の同期はソーストラッキング（Source Tracking）機能によって実現され、どのファイルが変更されたかをCLIが自動的に追跡します。

Scratch Orgのライフサイクル

Scratch Orgの典型的なライフサイクルは以下のステップで構成されます：

  1. 作成（Create）： sf org create scratchコマンドとproject-scratch-def.jsonファイルを使用してScratch Orgを作成します。
  2. 開発（Develop）： ローカルのソースコードをScratch Orgにデプロイし、Apexクラス（Apex Class）、Visualforceページ（Visualforce Page）、Lightning Web Components（LWC）などの開発を進めます。Salesforce UI（ユーザーインターフェース）上での設定変更も行えます。
  3. 同期（Sync）： 開発中にScratch Orgで行われた変更をsf project retrieve startコマンドでローカルにプルバックし、ローカルでコードを修正した後、sf project deploy startコマンドでScratch Orgにプッシュします。
  4. テスト（Test）： 開発した機能をScratch Org上でテストし、必要に応じてテストデータ（Test Data）を投入します。
  5. 削除（Delete）： 機能開発が完了し、変更がバージョン管理システムにコミットされたら、sf org delete scratchコマンドでScratch Orgを削除します。これにより、リソースが解放され、クリーンな状態を保てます。

このプロセス全体を通じて、Scratch Orgは開発者がクリーンで独立した環境で効率的に作業できることを保証します。また、CI/CDパイプラインに組み込むことで、ビルド、テスト、デプロイメントの各ステージで一貫した環境を提供し、自動化された開発フローを強力にサポートします。

サンプルコード

ここでは、Salesforce CLIを使用してScratch Orgを作成、管理、および操作するための主要なコマンドと、関連する設定ファイルの例を示します。これらのコマンドは、Salesforce DXプロジェクトの基盤となります。

1. Salesforce DXプロジェクトの作成

まず、新しいSalesforce DXプロジェクトを作成します。これは、すべてのメタデータと設定ファイルを保持するローカルディレクトリです。

sf project generate --name MyScratchOrgProject --output-dir .

説明：
sf project generate: 新しいSalesforce DXプロジェクトを生成するコマンドです。
--name MyScratchOrgProject: プロジェクトの名前を指定します。
--output-dir .: 現在のディレクトリにプロジェクトを作成します。このコマンドを実行すると、MyScratchOrgProjectという新しいフォルダが作成され、その中にsfdx-project.json、project-scratch-def.jsonなどのSalesforce DXプロジェクトファイルが配置されます。

2. sfdx-project.json の例

プロジェクトのルートディレクトリにあるsfdx-project.jsonファイルは、プロジェクトに関する基本的な情報、特にパッケージの定義を保持します。以下は基本的な例です。

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "59.0"
}

説明：
packageDirectories: メタデータソースファイルが配置されるディレクトリを指定します。デフォルトではforce-appが設定されます。
namespace: マネージドパッケージを開発する場合に名前空間を指定します。アンマネージドパッケージや通常の開発では空のままです。
sfdcLoginUrl: 認証に使用するSalesforceログインURLです。
sourceApiVersion: プロジェクトで使用するAPIバージョンを指定します。

3. project-scratch-def.json の例

Scratch Orgの定義ファイルです。これにより、作成されるScratch Orgの特性を詳細に指定できます。

{
  "orgName": "My Scratch Org",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
      }
    },
  "objectSettings": {
    "account": {
      "sharingModel": "Private"
    }
  }
}

説明：
orgName: Scratch Orgに割り当てられる表示名です。
edition: Orgのエディション（例: Developer, Enterprise, Group）を指定します。
features: Scratch Orgで有効にする特定の機能のリストです。例えば、EnableSetPasswordInApiはAPI経由でのパスワード設定を許可します。
settings: Lightning Experienceなどの特定の組織設定を構成します。
objectSettings: 特定のオブジェクトに対する共有モデルなどの設定を行います。

4. Scratch Orgの作成

Dev Hubに認証されていることを確認した後、このコマンドでScratch Orgを作成します。

sf org create scratch --definition-file config/project-scratch-def.json --alias my-scratch-org --set-default --duration-days 7

説明：
sf org create scratch: Scratch Orgを作成するコマンドです。
--definition-file config/project-scratch-def.json: 使用するScratch Org定義ファイルのパスを指定します。
--alias my-scratch-org: 新しいScratch Orgに割り当てるエイリアス（短い識別子）を指定します。これにより、コマンドで長いOrg IDを入力する代わりにエイリアスを使用できます。
--set-default: 作成されたScratch Orgを、現在のプロジェクトのデフォルトOrgとして設定します。これにより、以降のCLIコマンドで--target-orgフラグを省略できます。
--duration-days 7: Scratch Orgの有効期間を日数で指定します（最大30日）。

5. Scratch Orgを開く

作成したScratch Orgをブラウザで開きます。

sf org open --target-org my-scratch-org

説明：
sf org open: 指定されたOrgをデフォルトのWebブラウザで開きます。
--target-org my-scratch-org: 開くScratch Orgのエイリアスを指定します。--set-defaultで設定している場合は省略可能です。

6. ローカルソースをScratch Orgにデプロイする

ローカルプロジェクトのメタデータをScratch Orgにプッシュします。

sf project deploy start

説明：
sf project deploy start: ローカルのソースファイルをデフォルトのScratch Orgにデプロイします。変更されたファイルのみがデプロイされるため、非常に高速です。

7. Scratch Orgからの変更を取得する

Scratch Orgで行われた変更（例：UIからの設定変更、カスタムオブジェクトの作成）をローカルプロジェクトにプルします。

sf project retrieve start

説明：
sf project retrieve start: デフォルトのScratch Orgで行われた変更をローカルのソースファイルにプルします。これにより、UI上での変更もバージョン管理下に置くことができます。

8. 接続されているOrgの一覧を表示する

Salesforce CLIに認識されているすべての組織（Dev Hub、Scratch Org、Sandboxなど）のリストを表示します。

sf org list

説明：
sf org list: 現在のCLIが管理しているすべての組織のリストを表示します。これにより、有効なScratch Orgとその有効期限を確認できます。

9. Scratch Orgを削除する

開発が完了し、変更がVCSにコミットされたら、Scratch Orgを削除します。

sf org delete scratch --target-org my-scratch-org --no-prompt

説明：
sf org delete scratch: 指定されたScratch Orgを削除します。
--target-org my-scratch-org: 削除するScratch Orgのエイリアスを指定します。
--no-prompt: 削除の確認プロンプトを表示せずに削除を実行します。

注意事項

Scratch Orgは非常に強力なツールですが、その効果を最大限に引き出し、予期せぬ問題を避けるためにはいくつかの重要な注意事項があります。

1. Dev Hubの認証と権限

Scratch Orgを作成するには、まずSalesforce CLIがDev Hub組織に認証されている必要があります。Dev Hubユーザーには、「Scratch Orgの作成と管理（Create and Manage Scratch Orgs）」権限セットまたはプロファイル権限が付与されている必要があります。この権限がない場合、Scratch Orgの作成は失敗します。

2. Scratch Org定義ファイル（project-scratch-def.json）の正確性

project-scratch-def.jsonファイルはScratch Orgの「設計図」です。必要な機能（Features）、エディション、設定（Settings）が正確に定義されていることを確認してください。例えば、Field Service Lightningのような特定の機能が必要な場合、それを定義ファイルに明示的に含める必要があります。定義ファイルに存在しない機能や設定はScratch Orgでは有効になりません。また、エディションによってはサポートされていない機能もあるため、互換性にも注意が必要です。

3. ソーストラッキングの活用

Salesforce CLIのソーストラッキング機能は、ローカルとScratch Org間のメタデータ同期を効率化するために不可欠です。sf project deploy startとsf project retrieve startコマンドは、変更されたファイルのみを扱うため、高速な開発サイクルを可能にします。しかし、ソーストラッキングが何らかの理由で失われた場合（例：手動でファイルを大量にコピーした場合）、変更の追跡が不正確になる可能性があります。常にCLIコマンドを通じてメタデータを同期する習慣をつけましょう。

4. データとメタデータの分離

Scratch Orgは主にメタデータ開発のために設計されています。デフォルトでは、新しいScratch Orgにはユーザーデータ（User Data）は含まれていません。テストデータが必要な場合は、Apexスクリプト、Salesforce CLIのsf data tree importコマンド、またはData Loader CLIなどを使用して明示的にデータを投入する必要があります。重要なテストデータをバージョン管理下に置き、Scratch Orgのセットアッププロセスで自動的に投入できるようにすることがベストプラクティスです。

5. 組織の制限（Org Limits）と有効期間

Dev Hubには、作成できるアクティブなScratch Orgの数と、1日に作成できるScratch Orgの数に制限があります。これらの制限は、Dev Hubの種類（開発者版、Enterprise版など）によって異なります。また、Scratch Orgは一時的なものであり、最大30日間の有効期間があります（デフォルトは7日）。この期間を過ぎると、自動的に削除されます。長期的な環境が必要な場合は、Scratch OrgではなくSandboxを検討する必要があります。

6. 名前空間（Namespace）の管理

マネージドパッケージを開発している場合、sfdx-project.jsonとproject-scratch-def.jsonの両方で正しい名前空間を設定することが重要です。これにより、Scratch Orgが正しい名前空間プレフィックスで作成され、パッケージ開発中に名前空間の競合を防げます。

7. 既知の制限とエラー処理

Salesforce DXとScratch Orgは常に進化していますが、いくつかの既知の制限や一般的なエラーに遭遇する可能性があります。例えば、一部のレガシーなメタデータタイプはまだソーストラッキングが完全にサポートされていない場合があります。一般的なエラーメッセージ（例: "invalid orgId"、"missing feature"）に遭遇した場合は、Salesforce CLIのドキュメントやSalesforce開発者フォーラムを参照してトラブルシューティングを行ってください。多くの場合、project-scratch-def.jsonの構成ミスやDev Hubの権限不足が原因です。

これらの注意事項を理解し、適切に対処することで、Scratch Orgを効果的かつ安全に利用し、開発プロセスをよりスムーズに進めることができます。

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

Salesforce Scratch Orgは、現代のSalesforce開発ワークフローを根本から変革する強力なツールです。使い捨て（Disposable）で再現性の高い環境を提供することで、開発者はより迅速に、より安全に、そしてより協力的に作業できるようになります。本稿で説明したように、Scratch Orgは、隔離された開発、効率的なテスト、そして堅牢なCI/CDパイプラインの構築に不可欠な要素です。

Scratch Orgの主な利点を再確認しましょう：

  • 隔離性： 各開発者が独自の環境で作業できるため、メタデータの競合が減少し、他の開発者の作業への影響が最小限に抑えられます。
  • 再現性： project-scratch-def.jsonファイルによって、プロジェクトの特定の機能セットを持つOrgをいつでも再作成できるため、バグの再現や環境のセットアップが容易になります。
  • 速度： 必要に応じて迅速にOrgを作成・破棄できるため、開発サイクルが加速します。ソーストラッキングにより、変更のデプロイと取得も高速です。
  • CI/CDとの統合： 自動化されたテストとデプロイメントのクリーンな環境を提供し、継続的インテグレーション/デプロイメントの基盤を築きます。

Scratch Orgを最大限に活用するためのベストプラクティス

  1. Scratch Orgを使い捨てと見なす： 重要なデータや設定はScratch Orgに残さず、常にバージョン管理システム（VCS）にコミットするか、スクリプトで生成できるように準備してください。
  2. 常にソースコードを最新の状態に保つ： 他のチームメンバーが変更をプッシュした場合は、自分のローカルプロジェクトを最新の状態にプルし、その後に自分の変更をScratch Orgにプッシュする習慣をつけましょう。これにより、競合のリスクを減らせます。
  3. 一貫した命名規則を使用する： Scratch Orgのエイリアスには、プロジェクト名、機能名、開発者の名前などを組み合わせたわかりやすい命名規則を採用することで、複数のOrgを管理しやすくなります。
  4. Scratch Orgのセットアップを自動化する： 基本的なメタデータ（例：カスタムオブジェクト、フィールド）をデプロイし、テストデータを挿入し、パーミッションセットを割り当てるためのスクリプト（例：bashスクリプト、Node.jsスクリプト）を作成し、sf org create scratch後に自動実行するようにしましょう。これにより、開発者がすぐに作業を開始できる状態になります。
  5. CI/CDパイプラインへの統合： Jenkins、GitHub Actions、Azure DevOpsなどのCI/CDツールとSalesforce CLIを連携させ、ビルド、テスト、デプロイの各ステップで自動的にScratch Orgを作成、設定、テスト、破棄するように構成します。
  6. 不要になったScratch Orgは定期的に削除する： アクティブなScratch Orgの制限に達するのを防ぎ、リソースを解放するため、使用しないOrgはsf org delete scratchコマンドで積極的に削除してください。
  7. project-scratch-def.jsonを正確に定義する： 必要なすべての機能、設定、権限セットライセンスなどを定義ファイルに含めることで、チーム全体の開発環境の一貫性を保てます。
  8. パッケージ開発モデルを採用する： 長期的には、第二世代管理パッケージ（2GP）などのパッケージ開発モデルへの移行を検討しましょう。Scratch Orgは、パッケージのビルドとテストのための理想的な環境を提供します。

Salesforce DXとScratch Orgを効果的に活用することで、Salesforce開発はよりモダンで、アジャイルなプロセスへと進化します。これらのベストプラクティスを実践することで、チームは開発のボトルネックを解消し、高品質なソリューションを迅速に提供できるようになるでしょう。

コメント

コメントを投稿