Salesforce DXをマスターする：開発者向けモダンアプリケーションライフサイクル管理ガイド

日付:

背景と応用シーン

こんにちは、Salesforce開発者の皆さん。日々の開発業務、お疲れ様です。もしあなたが長年Salesforce開発に携わっているなら、「変更セット (Change Set)」を使ってメタデータを本番環境にリリースしていた時代を覚えているでしょう。手作業でのコンポーネント選択、依存関係の追跡、そしてデプロイ後の手動設定...。これらは非常に時間のかかる、エラーの起きやすいプロセスでした。

しかし、現代のソフトウェア開発は、より高速で、より信頼性が高く、より協調的なアプローチを求めています。この要求に応えるためにSalesforceが提供するのが、Salesforce DX (Salesforce Developer Experience, セールスフォース・デベロッパーエクスペリエンス) です。Salesforce DXは、単なるツールセットではなく、最新の開発手法をSalesforceプラットフォームに持ち込むための思想であり、フレームワークです。

Salesforce DXの核心は「ソース駆動開発 (Source-Driven Development)」にあります。これは、Salesforce組織（本番やSandbox）を信頼できる唯一の情報源（Source of Truth）とするのではなく、Gitなどのバージョン管理システム (Version Control System, VCS) を中心に据える開発モデルです。これにより、開発チームは以下のような多くの恩恵を受けることができます。

  • チームコラボレーションの向上: 各開発者が独立した環境で作業し、コードレビューやマージを通じて変更を統合できます。
  • 変更履歴の追跡: いつ、誰が、何を、なぜ変更したのかを正確に追跡できます。
  • 自動化の促進: CI/CD (継続的インテグレーション/継続的デリバリー) パイプラインを構築し、テスト、パッケージング、デプロイを自動化できます。
  • 品質の向上: 機能ごとに分離された環境で開発・テストを行うことで、バグの混入を早期に発見できます。

Salesforce DXは、特に以下のようなシナリオでその真価を発揮します。

  • 複数の開発者が関わる大規模なプロジェクト
  • AppExchangeアプリを開発するISVパートナー
    • * CI/CDパイプラインを導入し、アジャイルな開発プロセスを実現したい企業
  • アプリケーションのメタデータをモジュール化し、再利用性を高めたい場合

この記事では、Salesforce開発者の視点から、Salesforce DXの主要な概念を解き明かし、具体的なコマンド例を交えながら、その強力な機能を最大限に活用する方法を解説していきます。

原理説明

Salesforce DXは、いくつかの重要なコンセプトとツールで構成されています。これらを理解することが、DXを使いこなすための第一歩です。

Salesforce CLI (SFDX CLI)

Salesforce DXの中心的なツールが Salesforce CLI (Command Line Interface, コマンドラインインターフェース) です。sfdx というコマンドを通じて、開発ライフサイクルのほぼすべての操作をターミナルから実行できます。これまでブラウザのUIから行っていた多くの作業、例えば組織へのログイン、メタデータの取得・デプロイ、Apexテストの実行、データのインポート・エクスポートなどを、コマンド一つで実行できるため、スクリプト化や自動化が非常に容易になります。

開発ハブ (Dev Hub) とスクラッチ組織 (Scratch Orgs)

開発ハブ (Dev Hub) は、Salesforce DXの管理拠点となる特別な本番組織またはDeveloper Edition組織です。このDev Hubから、開発やテストに使用する一時的なSalesforce環境であるスクラッチ組織 (Scratch Orgs) を作成・管理します。

スクラッチ組織は、Salesforce DXの最も革新的な機能の一つです。これらは以下のような特徴を持っています。

  • 使い捨て可能: 必要な時に作成し、不要になったら破棄できます。デフォルトの有効期間は7日間ですが、最大30日まで延長可能です。
  • 設定可能: JSON形式の設定ファイル（project-scratch-def.json）を使って、エディション、有効化する機能、設定などを細かく定義できます。これにより、チーム全員が同じ構成の環境で開発できます。
  • ソース追跡: ローカルのファイルとスクラッチ組織内のメタデータとの差分を自動的に追跡してくれるため、変更したコンポーネントだけを効率的に同期できます。

この仕組みにより、開発者はクリーンで独立した環境で新しい機能開発に集中でき、「私の環境では動いたのに」といった問題を未然に防ぐことができます。

Salesforce DX プロジェクト構造

Salesforce DXでは、メタデータを特定のディレクトリ構造を持つ「DXプロジェクト」として管理します。sfdx force:project:create コマンドで生成されるこの構造の中心は sfdx-project.json ファイルで、プロジェクト全体の設定を定義します。メタデータは、デフォルトでは force-app ディレクトリに格納され、従来のメタデータ形式とは異なり、オブジェクトなどの大きなコンポーネントが複数のファイルに分割されたソース形式 (Source Format) で管理されます。これにより、バージョン管理システムでの差分確認やマージが格段に行いやすくなります。

ロック解除済みパッケージ (Unlocked Packages)

Salesforce DXは、メタデータを論理的な単位に分割し、ロック解除済みパッケージ (Unlocked Packages) として管理・デプロイする手法を推奨しています。これにより、アプリケーションをモノリシック（一枚岩）な構造から、独立して開発・バージョン管理・デプロイが可能なモジュールの集合体へと変えることができます。例えば、「請求管理パッケージ」「在庫管理パッケージ」のように機能を分割することで、開発の並行性を高め、リリースのリスクを低減できます。

示例代码

ここでは、Salesforce開発者が日常的に行うであろう一連のワークフローを、Salesforce CLIのコマンド例とともに紹介します。これらのコードはSalesforceの公式ドキュメントに基づいています。

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

まず、開発を始めるためのDXプロジェクトをローカルマシンに作成します。

# 'MyNewProject' という名前のDXプロジェクトを作成する
sfdx force:project:create --projectname MyNewProject

このコマンドを実行すると、MyNewProject というディレクトリが作成され、その中にDXプロジェクトの標準的なフォルダ構成と設定ファイル sfdx-project.json が生成されます。

2. Dev Hub組織への認証

スクラッチ組織を作成するためには、まずDev Hubを有効化した組織にCLIからログインする必要があります。

# Webブラウザ経由でログインし、この組織をデフォルトのDev Hubとして設定する
# -d: この組織をデフォルトのDev Hubとして設定する
# -a: MyDevHub というエイリアス（別名）を付ける
sfdx auth:web:login --setdefaultdevhubusername --setalias MyDevHub

コマンド実行後、ブラウザが開き、Salesforceのログイン画面が表示されます。Dev Hub組織の認証情報でログインすれば、CLIとの連携が完了します。

3. スクラッチ組織の定義と作成

次に、作成するスクラッチ組織の仕様を定義ファイルに記述します。このファイルは通常 config/project-scratch-def.json に配置されます。

{
  "orgName": "My Company - Feature X",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    }
  }
}

この定義ファイルを使用して、実際にスクラッチ組織を作成します。

# config/project-scratch-def.json を元にスクラッチ組織を作成する
# -f: 使用する定義ファイルのパス
# -s: この組織をデフォルトの組織として設定する
# -a: feature-x-org というエイリアスを付ける
# -d: 期間を30日間に設定する (デフォルトは7日)
sfdx force:org:create --definitionfile config/project-scratch-def.json --setalias feature-x-org --durationdays 30 --setdefaultusername

4. ソースコードのプッシュとプル

ローカルのDXプロジェクトでApexクラスやLightning Web Componentを作成・変更した後、その変更をスクラッチ組織に同期します。この操作を「プッシュ」と呼びます。

# ローカルの変更（新規作成、更新、削除）をデフォルトのスクラッチ組織にプッシュする
sfdx force:source:push

逆に、スクラッチ組織のUI（例えば、オブジェクトマネージャで項目を作成）で変更を加えた場合、その変更をローカルのプロジェクトに同期します。これを「プル」と呼びます。

# デフォルトのスクラッチ組織からの変更をローカルにプルする
sfdx force:source:pull

5. Apexテストの実行

開発したコードの品質を担保するため、Apexテストを実行します。

# デフォルトのスクラッチ組織で全てのApexテストを実行する
# -r: 結果の出力形式を human（人間が読みやすい形式）に指定
# -c: コードカバレッジの結果も表示する
sfdx force:apex:test:run --resultformat human --codecoverage

注意事项

Dev Hubの有効化

Dev Hubは、本番組織またはDeveloper Edition組織で一度有効にすると、無効にすることはできません。そのため、多くの企業では、本番組織とは別のビジネス組織（通常は有料）をDev Hub専用として契約するか、開発者向けに用意されたDeveloper Edition組織を使用します。本番組織で有効化する際は、その影響を十分に検討してください。

スクラッチ組織の制限

スクラッチ組織は無制限に作成できるわけではありません。Dev Hub組織ごとに、同時にアクティブにできるスクラッチ組織の数や、24時間以内に作成できる数に上限があります。これらの上限はSalesforceのエディションによって異なります。大規模なチームで開発を行う場合は、これらの制限を念頭に置いた運用ルールを設ける必要があります。

ソース形式とメタデータ形式の違い

Salesforce DXプロジェクトが使用するソース形式は、開発とバージョン管理に最適化されています。一方、変更セットや従来のAnt移行ツールが使用していたのはメタデータ形式です。この二つは互換性がありません。
Sandboxや本番組織など、ソース追跡が有効でない組織にメタデータをデプロイする場合は、sfdx force:source:push ではなく、まずソース形式をメタデータ形式に変換し、それからデプロイするコマンドを使用します。

# 1. ローカルのソースをメタデータ形式に変換する
sfdx force:source:convert --outputdir mdapi_output

# 2. 変換したメタデータを指定した組織（例: UAT_Sandbox）にデプロイする
sfdx force:mdapi:deploy --deploydir mdapi_output --targetusername UAT_Sandbox

この違いを理解し、デプロイ対象の組織に応じて適切なコマンドを使い分けることが非常に重要です。

プロファイルと権限セットの管理

プロファイル (Profile) は多くの設定を含む巨大なメタデータであり、ソース管理下ではコンフリクトが発生しやすく、管理が煩雑になりがちです。ベストプラクティスとしては、プロファイルの権限設定は最小限に留め、機能ごとのアクセス権限は権限セット (Permission Set) と権限セットグループ (Permission Set Group) を使って管理することが推奨されます。権限セットはより小さな単位で管理できるため、DXとの親和性が高いです。

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

Salesforce DXは、現代的な開発プラクティスをSalesforceの世界にもたらす、強力なフレームワークです。ソース駆動開発、Salesforce CLI、スクラッチ組織といったコンセプトを導入することで、開発チームの生産性、コード品質、そしてリリースの俊敏性を劇的に向上させることができます。

Salesforce開発者として成功するために、以下のベストプラクティスを心掛けることを強くお勧めします。

  1. バージョン管理の徹底: すべてのメタデータ変更は、GitなどのVCSを通じて管理します。ブランチ戦略（Git Flowなど）を定義し、プルリクエストによるコードレビューを必須としましょう。
  2. CI/CDパイプラインの構築: GitHub Actions, Jenkins, CircleCIなどのツールを活用し、コミットをトリガーとした自動テスト、パッケージバージョンの作成、検証環境への自動デプロイなどのパイプラインを構築しましょう。
  3. アプリケーションのモジュール化: アプリケーションを機能単位でロック解除済みパッケージに分割しましょう。これにより、依存関係が明確になり、独立した開発とリリースが可能になります。
  4. スクラッチ組織の積極的な活用: 新機能の開発、バグ修正、プルリクエストの検証など、あらゆるタスクで新しいスクラッチ組織を作成する習慣をつけましょう。「使い捨て」の思想を徹底することが、クリーンな開発環境を維持する鍵です。
  5. CLIコマンドの効率化: sfdx-project.json ファイル内の "scripts" セクションを活用して、よく使う長いコマンドに短いエイリアス（別名）を定義し、日々の作業を効率化しましょう。

Salesforce DXへの移行は、単なるツールの変更ではなく、開発文化そのものの変革を伴います。学習コストはかかりますが、その先にある開発体験の向上とビジネス価値の迅速な提供は、その労力に見合うだけの価値があると確信しています。

コメント

コメントを投稿