モダンなCI/CDのためのSalesforceスクラッチ組織マスターガイド（開発者向け）

日付:

背景と適用シナリオ

Salesforce 開発者として、私たちは常に開発プロセスの効率化と品質向上を追求しています。従来の Sandbox ベースの開発モデルは、多くのプロジェクトで成功を収めてきましたが、いくつかの課題も抱えていました。例えば、複数の開発者が同じ共有 Sandbox で作業することによる変更の競合、環境の不整合、そして本番環境からの乖離などです。これらの課題は、特に大規模なチームや、アジャイル開発、CI/CD (継続的インテグレーション/継続的デリバリー) を実践するプロジェクトにおいて、大きなボトルネックとなり得ました。

この課題を解決するために登場したのが、Salesforce DX (Salesforce Developer Experience) という新しい開発手法と、その中核をなす Scratch Org (スクラッチ組織) です。Scratch Org は、ソースコード駆動で作成・破棄が可能な、一時的な Salesforce 組織です。これは、バージョン管理システム (VCS) 、特に Git を中心としたモダンな開発ワークフローに完全に統合されるように設計されています。

Scratch Org の主な適用シナリオは以下の通りです：

  • 機能開発とバグ修正： 各開発者が、新しい機能やバグ修正ごとに独立したクリーンな Scratch Org を作成し、他の開発者の作業と完全に分離された環境で開発を進めることができます。
  • 自動テスト： CI/CD パイプライン内で、コードがリポジトリにプッシュされるたびに新しい Scratch Org を自動的に作成し、Apex テストや UI テストを実行します。これにより、変更が既存の機能に与える影響を即座に検知できます。
  • パッケージ開発： AppExchange で配布する管理パッケージや非管理パッケージの開発において、パッケージのインストールやアップグレードのテストをクリーンな環境で繰り返し行うことができます。
  • チームでの共同作業： 各自が同じ定義ファイルから Scratch Org を作成するため、チームメンバー全員が同じ設定・機能を持つ一貫した開発環境を簡単に再現できます。

私たち開発者にとって、Scratch Org は単なる新しいタイプの Sandbox ではありません。それは、開発のあり方を根本から変え、より迅速で、信頼性が高く、コラボレーティブなプロセスを実現するための強力なツールなのです。

原理説明

Scratch Org の魔法を理解するためには、Salesforce DX のいくつかの重要な概念を把握する必要があります。これらはすべて連携して、ソース駆動型の開発ライフサイクルを支えています。

1. Dev Hub (開発ハブ)

Dev Hub は、すべての Scratch Org とそのライフサイクルを管理する中心的な Salesforce 組織です。通常、本番組織またはトライアル用の Developer Edition 組織で Dev Hub 機能を有効にします。Dev Hub がなければ、Scratch Org を作成することはできません。Dev Hub は、チームが作成した Scratch Org の数、有効期限、ステータスなどを追跡します。

2. Salesforce CLI (SFDX CLI)

Salesforce Command Line Interface (Salesforce コマンドラインインターフェース)、通称 SFDX CLI は、開発者がコマンドラインから Salesforce 組織と対話するための主要なツールです。Scratch Org の作成、ソースコードのプッシュ/プル、テストの実行、データのインポート/エクスポートなど、開発ライフサイクルのほぼすべての操作を SFDX CLI を通じて行います。

3. Salesforce DX プロジェクト

これは、ローカルマシン上に存在する特定のディレクトリ構造を持つフォルダです。このプロジェクトには、すべてのソースコード (Apex クラス, Visualforce ページ, Lightning Web Components など)、設定メタデータ、テスト、そして Scratch Org の設定を定義するファイルが含まれています。中心的な設定ファイルは sfdx-project.json です。

4. Scratch Org 定義ファイル

project-scratch-def.json という名前の JSON ファイルが、作成される Scratch Org の「形」を定義します。このファイルで、Salesforce のエディション (Developer, Enterprise など)、有効化する機能 (Person Accounts, Multi-Currency など)、そして特定の設定 (Chatter の有効化など) を指定します。このファイルをバージョン管理下に置くことで、チーム全員が全く同じ構成の Scratch Org を作成できるのです。

5. ソース追跡 (Source Tracking)

Scratch Org の最大の特徴の一つがソース追跡機能です。SFDX CLI を使ってローカルのソースコードを Scratch Org にデプロイ (プッシュ) したり、Scratch Org 上で宣言的に行った変更 (例: オブジェクトに新しい項目を追加) をローカルのプロジェクトに反映 (プル) したりする際、CLI は変更差分を自動的に追跡します。これにより、開発者はどのファイルが変更されたかを意識することなく、コマンド一つでローカルと組織の状態を同期させることができます。

これらの要素が組み合わさることで、以下のような開発フローが実現します：

  1. 定義： project-scratch-def.json で組織の構成を定義する。
  2. 作成： SFDX CLI を使い、Dev Hub に接続して新しい Scratch Org を作成する。
  3. 開発： ローカルでコードを書き、SFDX CLI で Scratch Org にプッシュする。または、Scratch Org 内で UI を使って変更を行い、ローカルにプルする。
  4. テスト： 自動テストを実行し、品質を担保する。
  5. 統合： 作業が完了したら、変更をバージョン管理システム (Git) にコミットし、プルリクエストを作成する。
  6. 破棄： 不要になった Scratch Org は削除する。

このサイクルは非常に高速で、数分で新しい環境を立ち上げ、作業を終えたらクリーンアップできます。これが Scratch Org の力です。

示例代码

ここでは、Salesforce DX プロジェクトをセットアップし、Scratch Org を作成して使用するための具体的なコード例を見ていきましょう。これらのコードは Salesforce の公式ドキュメントに基づいています。

1. sfdx-project.json (プロジェクト設定ファイル)

これは DX プロジェクトのルートに配置される中心的なファイルです。パッケージディレクトリや API バージョンなどを定義します。

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

注釈:

  • packageDirectories: ソースコードが格納されるディレクトリを指定します。force-app が標準です。
  • sfdcLoginUrl: Dev Hub や本番組織へのログイン URL を指定します。
  • sourceApiVersion: このプロジェクトが使用する Salesforce API のバージョンを定義します。

2. project-scratch-def.json (Scratch Org 定義ファイル)

config ディレクトリ内に配置し、作成する Scratch Org の詳細な構成を定義します。

{
  "orgName": "Dreamhouse Realty",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    },
    "quoteSettings": {
        "enableQuote": true
    }
  }
}

注釈:

  • orgName: 作成される Scratch Org の組織名を指定します。
  • edition: 組織のエディション (Developer, Enterprise, Unlimited など) を指定します。
  • features: 有効化したい特定の Salesforce 機能を配列で指定します。この例では、API経由でのパスワード設定を有効にしています。
  • settings: より詳細な組織設定をオブジェクト形式で指定します。ここでは Lightning Experience の有効化、モバイル設定、そして見積もり機能の有効化を行っています。

3. SFDX CLI コマンドシーケンス

以下は、開発者が日常的に使用する一連の SFDX CLI コマンドです。

ステップ 1: Dev Hub 組織にログインする (初回のみ)

// Webベースの認証フローを開始します。
// -d フラグでこの組織をデフォルトのDev Hubとして設定し、
// -a フラグで「DevHub」というエイリアス（別名）を付けます。
sf org login web --set-default-dev-hub --alias DevHub

ステップ 2: Scratch Org を作成する

// config/project-scratch-def.json ファイルの定義に基づいて新しいScratch Orgを作成します。
// --set-default フラグで、この組織を今後のSFDXコマンドのデフォルトターゲットにします。
// --alias フラグで「MyScratchOrg」というエイリアスを付けます。
// --duration-days で有効期限を1から30日の間で指定できます (デフォルトは7日)。
sf org create scratch --definition-file config/project-scratch-def.json --set-default --alias MyScratchOrg --duration-days 7

ステップ 3: ローカルのソースコードを Scratch Org にプッシュする

// プロジェクト内のソースコード（force-appディレクトリ以下）を
// デフォルトのScratch Orgにデプロイします。
// ソース追跡機能により、変更があったファイルのみがプッシュされます。
sf project deploy start

ステップ 4: 必要な権限セットをユーザに割り当てる

// アプリケーションに必要な権限セットをデフォルトユーザに割り当てます。
// -n フラグで権限セットの名前を指定します。
sf org assign permset --name MyCustomAppPermissionSet

ステップ 5: Apex テストを実行する

// 組織内のすべてのApexテストを実行します。
// --result-format human で結果を人間が読みやすい形式で表示します。
// --wait 10 で最大10分間テストの完了を待ちます。
sf apex test run --result-format human --wait 10

ステップ 6: Scratch Org をブラウザで開く

// デフォルトのScratch Orgをブラウザで開きます。
// ユーザ名やパスワードを入力する必要はありません。
sf org open

ステップ 7: Scratch Org を削除する (作業完了後)

// 不要になったScratch Orgを削除します。
// -o フラグでターゲットとなる組織のエイリアスを指定します。
// -p フラグで確認プロンプトをスキップします。
sf org delete scratch -o MyScratchOrg -p

注意事項

Scratch Org を効果的に利用するためには、いくつかの制限と注意点を理解しておくことが重要です。

  • 権限： Dev Hub 組織で Scratch Org を作成するには、Dev Hub にログインするユーザに「Salesforce DX」権限セットが割り当てられている必要があります。
  • 組織の制限： Dev Hub ごとに、同時にアクティブにできる Scratch Org の数と、24時間以内に作成できる Scratch Org の数には上限があります。これらの上限は Salesforce のエディションによって異なります。SFDX CLI を使用して現在の上限と使用状況を確認できます。
    sf limits api display --target-org DevHub -n ScratchOrgInfo
  • 有効期限： Scratch Org は本質的に一時的なものであり、作成時に 1 日から 30 日の有効期限を設定する必要があります (デフォルトは 7 日)。有効期限が切れると、組織は自動的に削除され、復元はできません。これは「使い捨て」という設計思想の現れです。
  • データは含まれない： Scratch Org は、メタデータ（オブジェクト、項目、コードなど）は含みますが、デフォルトではレコードデータは一切含みません。テストデータは、SFDX CLI のデータコマンド (sf data tree import) を使用してインポートするか、Apex のテストデータファクトリや @TestSetup を使用して生成する必要があります。
  • 本番環境の完全なコピーではない： Scratch Org は、特定のエディションと機能をシミュレートしますが、本番組織のすべての設定やデータを完全にミラーリングするものではありません。本番に近いテストが必要な場合は、Full Sandbox や Partial Sandbox の利用も依然として重要です。
  • ソース追跡の例外： ほとんどのメタデータはソース追跡の対象となりますが、一部のコンポーネント（例：一部の標準項目設定）は追跡されない場合があります。開発者は、どのメタデータタイプがサポートされているかを意識する必要があります。

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

Scratch Org は、Salesforce 開発者にとって革命的なツールです。ソース駆動型のアプローチを可能にし、開発プロセス全体のアジリティ、信頼性、コラボレーションを大幅に向上させます。その使い捨ての性質は、クリーンで一貫性のある環境を保証し、CI/CD パイプラインとのシームレスな統合を実現します。

最後に、Scratch Org を最大限に活用するためのベストプラクティスをいくつか紹介します。

  1. タスクごとに Org を作成する： 1つの機能開発、1つのバグ修正など、小さな作業単位ごとに新しい Scratch Org を作成しましょう。これにより、作業の分離が徹底され、コンフリクトのリスクが最小限に抑えられます。
  2. 定義ファイルをバージョン管理する： project-scratch-def.json を Git リポジトリに含めることで、チーム全員が常に同じ構成の組織で作業できるようになります。
  3. セットアップを自動化する： Scratch Org 作成後の手動セットアップ（権限セットの割り当て、テストデータの投入など）は、スクリプト化しましょう。SFDX CLI コマンドをシェルスクリプトにまとめることで、誰でもワンコマンドで完全な開発環境を構築できるようになります。
  4. CI/CD パイプラインに組み込む： プルリクエストが作成されるたびに、CI ツール (GitHub Actions, Jenkins, CircleCI など) が自動的に Scratch Org を作成し、テストを実行し、結果をフィードバックする仕組みを構築しましょう。これにより、品質が継続的に保証されます。
  5. 定期的にクリーンアップする： 不要になった Scratch Org は積極的に削除する習慣をつけましょう。これにより、Dev Hub の制限に達するのを防ぎ、リソースを効率的に管理できます。有効期限を短め（例: 1〜3日）に設定することも有効な戦略です。

私たち Salesforce 開発者は、Scratch Org を使いこなすことで、よりモダンで効率的な開発スタイルへと進化することができます。ぜひ日々の開発業務に積極的に取り入れ、そのメリットを最大限に享受してください。

コメント

コメントを投稿