執筆者:Salesforce 開発者
背景と適用シナリオ
Salesforce 開発者として、私たちは常に効率的で、スケーラブルかつ信頼性の高い開発プロセスを模索しています。従来の開発モデル、特に多くの開発者が共有のサンドボックスで作業し、変更セット(Change Sets)を使ってリリースを管理する手法は、多くの課題を抱えていました。例えば、変更の競合、手動でのデプロイ作業によるヒューマンエラー、そして開発環境の一貫性の欠如などです。これらの課題は、開発のスピードを遅らせ、品質を低下させる原因となっていました。
このような背景から、Salesforceは最新の開発手法を取り入れたSalesforce DX (Developer Experience) を発表しました。Salesforce DXは、単なるツールではなく、開発ライフサイクル全体をモダナイズするための思想と一連のツールセットです。その中核にあるのがソース駆動開発 (Source-Driven Development) という考え方です。
ソース駆動開発では、Salesforce組織(Org)が「信頼できる唯一の情報源(Source of Truth)」ではなく、Version Control System (VCS、バージョン管理システム)、例えばGitがその役割を担います。すべてのメタデータ(コード、設定、オブジェクト定義など)はVCSで管理され、開発者はそこから自分専用のクリーンな環境を構築して作業を行います。これにより、チーム開発が劇的に改善され、継続的インテグレーション/継続的デプロイメント(CI/CD)の実現も容易になります。
Salesforce DXの主な適用シナリオ
- チームでの協業開発: 各開発者が独立した環境で作業し、変更をVCSにマージすることで、コンフリクトを最小限に抑え、スムーズな共同作業を実現します。
- CI/CDパイプラインの構築: Gitへのプッシュをトリガーに、自動テストの実行、ビルド、そして後続環境への自動デプロイメントを構築できます。
- パッケージベースの開発: アプリケーションをモジュール化されたUnlocked Packages (ロック解除済みパッケージ) として開発・配布することで、再利用性と管理性を高めます。
- 再現性の高いテスト環境: 毎回同じ設定のクリーンな環境でテストを実行できるため、テストの信頼性が向上します。
原理説明
Salesforce DXの魔法は、いくつかのコアコンポーネントの連携によって実現されています。開発者としてこれらのコンポーネントの役割を理解することは、SFDXを最大限に活用する上で不可欠です。
1. Dev Hub (開発ハブ)
Dev Hubは、Salesforce DXの中心的な管理機能を持つ特別な本番組織またはビジネス組織です。Dev Hubの主な役割は、Scratch Orgs (スクラッチ組織) の作成と管理です。開発チームが使用するスクラッチ組織や、関連付けられた名前空間レジストリ、Unlocked Packagesなどを一元管理します。通常、本番組織をDev Hubとして有効化します。
2. Scratch Orgs (スクラッチ組織)
スクラッチ組織は、Salesforce DXの最も強力な機能の一つです。これは、ソースコードやメタデータを含まない、一時的で使い捨て可能なSalesforce組織です。開発者は、VCSにあるソースコードから、機能開発やテストに必要な設定(エディション、有効化する機能、サンプルデータなど)を定義した設定ファイルに基づいて、数分で自分専用のスクラッチ組織を作成できます。作業が終われば、この組織は破棄できます。これにより、常にクリーンな環境で開発を開始でき、「自分の環境では動くのに…」といった問題を回避できます。
3. Salesforce CLI (コマンドラインインターフェース)
Salesforce CLI (SFDX CLI) は、開発者がターミナルやコマンドプロンプトからSalesforce DXのほぼすべての操作を行うための強力なツールです。スクラッチ組織の作成・削除、組織へのソースコードのプッシュ/プル、テストの実行、データのインポート/エクスポート、パッケージの作成・インストールなど、開発ライフサイクルのあらゆる側面をコマンドで自動化できます。CI/CDパイプラインのスクリプトにも、このCLIが広く利用されます。
4. DXプロジェクト形式 (DX Project Format)
Salesforce DXでは、メタデータをより管理しやすく、VCSと親和性の高いディレクトリ構造でローカルに保存します。これはDXプロジェクト形式と呼ばれます。例えば、カスタムオブジェクトは、オブジェクト定義、項目、入力規則、レイアウトなどがそれぞれ別のファイルに分解(decomposed)されて保存されます。これにより、複数人での同時変更時のコンフリクトが起きにくくなります。
標準的な開発ワークフロー
開発者としての日々の作業は、以下のような流れになります。
- VCSから最新のソースを取得: `git pull` コマンドで、リポジトリの最新の状態をローカルに反映します。
- スクラッチ組織の作成: 担当する機能や修正のための新しいスクラッチ組織をCLIで作成します。(`sfdx force:org:create`)
- ソースコードのプッシュ: ローカルのソースコードをスクラッチ組織にデプロイします。(`sfdx force:source:push`)
- 開発作業: VS CodeなどのIDEでコードを記述したり、スクラッチ組織にログインして宣言的な変更(例:項目追加)を行ったりします。
- 変更のプル: スクラッチ組織上で行った宣言的な変更をローカルのファイルに反映させます。(`sfdx force:source:pull`)
- テストの実行: 作成した機能に対する単体テストを実行し、品質を担保します。(`sfdx force:apex:test:run`)
- VCSへのコミットとプッシュ: 作業が完了したら、変更をVCSにコミットし、リモートリポジトリにプッシュします。(`git commit`, `git push`)
- スクラッチ組織の削除: 不要になったスクラッチ組織を削除します。(`sfdx force:org:delete`)
このサイクルを繰り返すことで、クリーンで独立した環境での高品質な開発が可能になります。
示例代码
ここでは、Salesforce DXを使った典型的な開発フローをSalesforce CLIコマンドの例と共に示します。これらのコマンドはSalesforceの公式ドキュメントに基づいています。
1. DXプロジェクトの作成
まず、開発の基盤となるDXプロジェクトをローカルマシンに作成します。
# "MyAwesomeProject" という名前で新しいDXプロジェクトを作成します sfdx force:project:create --projectname MyAwesomeProject
これにより、`sfdx-project.json`(プロジェクト設定ファイル)や、`config`、`force-app`(ソースコードの格納場所)といった標準的なディレクトリ構造が生成されます。
2. スクラッチ組織定義ファイル
スクラッチ組織を作成する前に、どのような組織にするかを定義するJSONファイル(通常は `config/project-scratch-def.json`)を編集します。以下はEnterprise Editionで、いくつかの機能を有効化した例です。
{ "orgName": "My Company - Dev Scratch Org", "edition": "Enterprise", "features": ["EnableSetPasswordInApi", "PersonAccounts"], "settings": { "lightningExperienceSettings": { "enableS1DesktopEnabled": true }, "mobileSettings": { "enableS1EncryptedStoragePref2": false } } }
注釈:
- orgName: スクラッチ組織の名前を定義します。
- edition: Salesforceのエディション(Developer, Enterprise, etc.)を指定します。
- features: 有効化したい特定の機能を配列で指定します。
- settings: 有効化したい組織設定を詳細に定義します。
3. Dev Hubへの認証とスクラッチ組織の作成
次に、Dev Hub組織にCLIを接続し、上記の設定ファイルに基づいてスクラッチ組織を作成します。
# Dev Hub組織にブラウザ経由でログインし、エイリアス "MyDevHub" を設定します # -d: この組織をデフォルトのDev Hubとして設定 sfdx auth:web:login --setalias MyDevHub --setdefaultdevhubusername # config/project-scratch-def.json を使用してスクラッチ組織を作成 # -a: スクラッチ組織のエイリアスを設定 # -s: このスクラッチ組織をデフォルトの組織として設定 # 期間は7日間 (デフォルト) sfdx force:org:create -f config/project-scratch-def.json -a MyScratchOrg -s
4. ソースコードのプッシュと組織へのアクセス
ローカルにあるソースコードを、作成したばかりのスクラッチ組織にデプロイします。
# ローカルのソースコードとスクラッチ組織のメタデータを同期します sfdx force:source:push # デフォルトのスクラッチ組織をブラウザで開きます sfdx force:org:open
5. Apexテストの実行
開発が完了したら、品質を保証するためにApexテストを実行します。
# デフォルト組織で全てのApexテストを実行し、結果を人間が読みやすい形式で表示します sfdx force:apex:test:run --resultformat human --wait 10
注意事項
Salesforce DXを導入・運用する際には、いくつかの点に注意が必要です。
権限
Dev Hubを有効化するには、本番組織の「システム管理者」プロファイル、または「Dev Hubを有効化」というシステム権限が必要です。また、スクラッチ組織を作成する開発者はDev Hub組織の有効なユーザーである必要があります。
API制限
Salesforce CLIによる操作は、バックグラウンドでSalesforce APIをコールしています。そのため、Dev Hub組織のAPIコール数の制限に影響を与えます。大規模なチームが頻繁にスクラッチ組織を作成・削除する場合や、CI/CDで大量のコマンドを実行する場合には、API使用量をモニタリングすることが重要です。
スクラッチ組織の制限
スクラッチ組織には有効期間(1〜30日、デフォルトは7日)があります。期間が過ぎると自動的に削除されます。また、Dev Hubごとに同時に有効にできるスクラッチ組織の数や、一日あたりに作成できる数には上限があります。これらの上限はSalesforceの契約によって異なります。
サポートされていないメタデータタイプ
Salesforce DXのソース追跡機能(`push`/`pull`コマンド)は、全てのメタデータタイプに完全に対応しているわけではありません。一部の古い設定や特殊なメタデータは、ソース追跡の対象外となることがあります。その場合、従来のメタデータAPI形式(`mdapi`コマンド)でのデプロイが必要になることがあります。常にメタデータカバレッジレポートを確認することをお勧めします。
プロファイルと権限セットの管理
DXプロジェクト形式ではプロファイルが細かく分解されますが、その管理は依然として複雑です。ベストプラクティスとして、プロファイルの変更は最小限に留め、機能ごとの権限はPermission Sets (権限セット) および Permission Set Groups (権限セットグループ) で管理することが強く推奨されます。権限セットの方がモジュール化されており、ソース管理に適しています。
まとめとベストプラクティス
Salesforce DXは、現代的なソフトウェア開発プラクティスをSalesforceプラットフォームにもたらす、開発者にとって非常に強力なツールセットです。ソース駆動開発への移行は、単なるツールの変更ではなく、開発文化そのものの変革を意味します。最初は学習コストがかかりますが、その見返りは非常に大きいものです。
最後に、Salesforce開発者としてSFDXを成功させるためのベストプラクティスをいくつか紹介します。
- VCSを常に中心に置く: GitなどのVCSを「信頼できる唯一の情報源」とし、すべての変更履歴をそこで管理します。サンドボックスや本番組織で直接変更を加えることは避けるべきです。
- スクラッチ組織を使い捨てる文化を醸成する: スクラッチ組織は一時的なものです。一つの機能、一つのバグ修正ごとに新しいスクラッチ組織を作成することを習慣づけましょう。これにより、環境の依存関係の問題を排除できます。
- CI/CDを積極的に導入する: 開発プロセスの自動化は、品質向上とリリースサイクルの短縮に直結します。Salesforce CLIをJenkins、GitLab CI、GitHub Actionsなどのツールと組み合わせて、テストとデプロイのパイプラインを構築しましょう。
- Unlocked Packagesの採用を検討する: 大規模なアプリケーションや、複数のチームで開発を進める場合、機能をUnlocked Packagesに分割することで、モジュール性が高まり、依存関係の管理やリリースが容易になります。
- Salesforce CLIの能力を最大限に引き出す: CLIにはここで紹介した以外にも多くのコマンドがあります。データのインポート・エクスポート(`force:data:tree:export/import`)、Apexの匿名実行(`force:apex:execute`)など、日々の作業を効率化する便利な機能を積極的に探求しましょう。
Salesforce DXを使いこなすことで、私たちはより迅速に、そしてより高い品質で価値をビジネスに届けられるようになります。ぜひこのモダンな開発体験を取り入れて、開発者としてのスキルを次のレベルへと引き上げてください。
コメント
コメントを投稿