検証：複数パッケージのSalesforceプロジェクトで変更をpullするとどうなるのか

SalesforceのISVならともかく、組織でSalesforceを使う人たちで複数パッケージで開発しているところは、調べた限り少ないです。

組織でロック解除済みパッケージを使うとして、複数プロジェクト分割時にどういう開発プロセスになるのか知りたくて、検証してみます。

準備

自分で複数プロジェクトのソースを用意するのが大変だったので、サンプルを持ってきました。

github.com

とっても助かります。

また、Salesforce組織はTrailhead Playgroundを使います。「Dev Hubを有効化」と「ロック解除済みパッケージと第二世代管理パッケージを有効化」をどちらも有効にします。その他クライアント環境は以下の通りです。

環境	バージョンなど
OS	Windows10
Editor	Visual Studio Code
SFDX	sfdx-cli/7.63.0-c897e8bb1a
shell	Powershell7.0.1*1

手順

既に、SFDXでTrailhead Playgroundには接続しているものとします。

組織起動、ソース等のpush

sfdx force:org:create -f .\config\project-scratch-def.json -a easylwc
sfdx force:org:open -u easylwc

スクラッチ組織を起動するところまでは上記です。

sfdx force:source:push -u easylwc

組織へのpushです。結構時間かかるので待ちましょう。権限付与などは、GitHubリポジトリの説明にあるので、そちらを参照ください。

これで、開発環境が整います。開発中はパッケージに固めたものを使いません。（たぶん）

変更を加える

新規オブジェクトを足してみます。Salesforce組織上で行います。

変更を確認します。

sfdx force:source:status -u easylwc

=== Source Status
STATE       FULL NAME                  TYPE          PROJECT PATH
──────────  ─────────────────────────  ────────────  ────────────
Remote Add  Admin                      Profile
Remote Add  Custom: Sales Profile      Profile
Remote Add  Custom: Marketing Profile  Profile
Remote Add  Custom: Support Profile    Profile
Remote Add  House__c-Houseレイアウト        Layout
Remote Add  House__c                   CustomObject

pullする

sfdx force:source:pull -u easylwc

=== Pulled Source
STATE  FULL NAME            TYPE          PROJECT PATH
─────  ───────────────────  ────────────  ──────────────────────────────────────────────────────────────────────
Add    House__c             CustomObject  es-space-mgmt\main\default\objects\House__c\House__c.object-meta.xml
Add    House__c-Houseレイアウト  Layout        es-space-mgmt\main\default\layouts\House__c-Houseレイアウト.layout-meta.xml

ふむ。es-space-mgmtディレクトリに入ってきたようです。

なぜこのディレクトリなのか

おそらくですが、sfdx-project.jsonの定義上、es-space-mgmtがデフォルトパッケージとなっているから、です。

// 略
{
    "path": "./es-space-mgmt",
    "package": "ESSpaceMgmtLWC",
    "versionName": "Space Management App - Spring '20",
    "versionNumber": "4.0.0.NEXT",
    "default": true,
// 略
}

もし、特定のパッケージにこのソースを含めたい（今回ならes-base-objectsパッケージに入れる）場合は、ローカルでソースを移動させた後に、パッケージを作成して動作確認、という手順を踏むのでしょう。

つまり、開発中はある程度の整理ができていれば十分そうです。

なお、既存のメタデータに対する変更は、元のパッケージディレクトリに反映されます。

例：Market__cにカスタムフィールド追加（権限セットも変更）

statusはこうなります。

sfdx force:source:status -u easylwc

=== Source Status
STATE           FULL NAME          TYPE           PROJECT PATH
──────────────  ─────────────────  ─────────────  ────────────────────────────────────────────────────────────────────────────────────
Remote Add      Market__c.Memo__c  CustomField
Remote Changed  EasySpacesObjects  PermissionSet  es-base-objects\main\default\permissionsets\EasySpacesObjects.permissionset-meta.xml

pullします。

=== Pulled Source
sfdx force:source:pull -u easylwc

=== Pulled Source
STATE    FULL NAME          TYPE           PROJECT PATH
───────  ─────────────────  ─────────────  ────────────────────────────────────────────────────────────────────────────────────
Add      Market__c.Memo__c  CustomField    es-base-objects\main\default\objects\Market__c\fields\Memo__c.field-meta.xml
Changed  EasySpacesObjects  PermissionSet  es-base-objects\main\default\permissionsets\EasySpacesObjects.permissionset-meta.xml

ちゃんと、元あったオブジェクト部分に変更が反映されています。

軽いまとめ

sfdx force:source:pushは、パッケージとして定義されていたら組織にpushされる

sfdx force:source:pullは、組織の変更をデフォルトパッケージに取り込む。必要ならそこから移動させる

パッケージ分割は、あくまでリリース時に考慮することで、開発中はそこまで考えなくてもいい。（ただし双方向参照とかを作ってしまった場合はそれらを同一パッケージに含める必要があるなど、設計段階で考慮する事項はある）

おわりに

今回の記事、ほとんど自分用のメモです。SFDXのpushやpullがどういう挙動か知らないと、いざというときに困りそうなので調査しています。特に複数パッケージを扱う時のドキュメントが見当たらず状態だったので、手探りでやっています。

また何か試したら記事にします。

*1:Windows Terminalから使用