第二世代管理パッケージをビルドする準備をする
学習の目的
この単元を完了すると、次のことができるようになります。
- パッケージの作成に必要な Salesforce DX ツールを挙げる。
- Dev Hub の役割を説明する。
開発環境の設定
この単元では、管理 2GP を初めてビルドするための準備として、主要なツールと概念について説明します。
管理 2GP で使用する主なツールは次のとおりです。
- Salesforce CLI。パッケージの作成やインストールなど、さまざまなパッケージ化操作を実行するための豊富なコマンドセットです。
- 任意のソース管理システム
- Dev Hub 組織
- Visual Studio Code 向け Salesforce 拡張機能 (オプション)。Salesforce コンポーネントの開発を容易にするために設計された IDE です。
管理 2GP パッケージ開発とその他の Salesforce DX 開発の両方に上記のツールを使用します。
このモジュールを完了するために管理 2GP ツールを設定する必要はありません。早く使用してみたい方は、『Second-Generation Managed Packaging Developer Guide (第二世代管理パッケージ開発者ガイド)』の「Before You Create Second-Generation Managed Packages (第二世代管理パッケージを作成する前に)」で開発環境を設定する手順を参照してください。
Dev Hub を使用してパッケージ開発を追跡する
Salesforce 開発ライフサイクルを開始するときには、作成したパッケージ、使用した名前空間、開発が行われるスクラッチ組織を追跡する必要があります。ご想像のとおり、Dev Hub 組織はまさにそれを行う場所です。
開発者ハブ (Dev Hub) は、すべての管理 2GP パッケージ、スクラッチ組織、名前空間を見つけて管理するために指定された場所です。Salesforce 組織で Dev Hub 設定を有効にすると、その組織が Dev Hub 組織になります。また、その Dev Hub は、作成するすべての管理 2GP パッケージの所有者になります。
すべての Salesforce ISV パートナーと OEM パートナーは、パートナービジネス組織を Dev Hub 組織として指定することが推奨されます。パートナービジネス組織 (PBO) は、Salesforce パートナーがビジネスを行う本番組織です。
管理 2GP パッケージを設定する
パッケージ設定の要素を理解するために、Get Cloudy の Expense Manager パッケージを見てみましょう。
Get Cloudy の Expense Manager パッケージのプロジェクトディレクトリを次に示します。
Get Cloudy のパッケージは上位の Salesforce プロジェクトディレクトリから始まり、その中に exp-core (1) と util (2) という 2 つのパッケージディレクトリがあります。Salesforce DX プロジェクトは開発用のコンテナであり、プロジェクトディレクトリには 1 つ以上のパッケージがあります。
sfdx-project.json (3) プロジェクトファイルには、プロジェクトディレクトリ内の各パッケージの設定が記述されています。
プロジェクト設定ファイルを理解する
Expense Manager パッケージの sfdx-project.json ファイルを次に示します。このプロジェクト設定ファイルでは、パッケージの名前空間が exp-mgr (1) で、API バージョンが 47 (2) であることが指定されています。
このプロジェクトには、Expense Manager - Util (3) と Expense Manager (4) という 2 つのパッケージディレクトリがあります。各パッケージディレクトリでは、そのパッケージのパス、バージョン名、説明、定義ファイルが指定されています。
Expense Manager パッケージには、2 つのパッケージ連動関係 (5)、Cloudy が作成した Expense Manager - Util というパッケージ (これも exp-mgr 名前空間に関連付けられている)、External Apex Library という外部パッケージがリストされています。
ここで注目すべき点は、sfdx-project.json ファイル内の連動関係の明示的な宣言は、管理 2GP の主な利点の 1 つであるということです。あなたやアプリケーションの開発者は、パッケージと連動するすべての管理 1GP または管理 2GP を見ることができます。そのため、複数のモジュール式パッケージの開発と管理はそれほど難しいことではありません。
パッケージの別名セクション (6) で、わかりやすい文字列 (別名) がパッケージ ID に対応付けられます。長くて暗号のようなパッケージ ID 番号ではなく、パッケージを説明する別名を使用することで、sfdx-project.json ファイルの残りの部分が読みやすくなります。
パッケージを設計するときには、AppExchange の各リスティングは 1 つのパッケージに対応付けられることに留意してください。したがって、モジュール式パッケージを開発する場合は、インストールする順序など、連動パッケージのインストール方法を登録者に説明してください。また現在、Salesforce では関連パッケージのインストールをバンドル化する機能を開発しています。
管理 2GP のバージョン番号付けを理解する
このプロジェクトファイルの 2 つのパッケージ (4.7.0.NEXT と 3.2.0.NEXT) のバージョン番号を詳しく見てみましょう。パッケージバージョン番号は、次のパターンに従います。
|
メジャーバージョン |
マイナーバージョン |
パッチバージョン |
ビルド番号 |
|
4 |
7 |
0 |
NEXT |
管理 2GP のバージョン番号形式は、セマンティックバージョン管理の形式に似ています。大幅な変更を行うときはメジャーバージョン番号を増やし、漸進的な改良を行うときはマイナーバージョン番号を増やし、バグ修正にはパッチバージョンを使用します。メジャー更新とマイナー更新のどちらに該当するかの判断は開発者に委ねられます。
この例では、ビルド番号が明示的に設定されていません。代わりに、パッケージビルドの値を自動的に増やすキーワードである NEXT が使用されています。
パッケージ連動関係セクションにリストされているバージョン番号を見ると、バージョン番号 4.7.0.LATEST には別のキーワードが使用されていることがわかります。
"dependencies": [
{
"package": "Expense Manager - Util",
"versionNumber": "4.7.0.LATEST"
}
]
LATEST というキーワードを使用することで、Get Cloudy の開発者は Expense Manager - Util パッケージの最新パッケージバージョンを使用することを示しています。これにより、sfdx-project.json ファイルにリストされているバージョン番号を手動で増やすことなく、パッケージ開発で繰り返し処理を実行しやすくなります。パッケージでは、ユーティリティパッケージの最新バージョンが自動的に参照されます。
使用できる 3 つ目のキーワードとして、RELEASED があります。このキーワードは、パッケージの最新のリリース済みバージョンと連動するシナリオで使用します。各キーワードは、作成するパッケージとパッケージ連動関係の両方の所有者が同じ Dev Hub である場合にのみ使用してください。
プロジェクト設定ファイルを使用すると、パッケージ連動関係の視覚化と明示的な宣言が容易になります。プロジェクトファイルで指定されているその他のパラメーターについての詳細は、『Second-Generation Managed Packaging Developer Guide (第二世代管理パッケージ開発者ガイド)』の「Project Configuration File for Packages (パッケージのプロジェクト設定ファイル)」を参照してください。
管理 2GP を作成するためのツールと基礎を学びました。次はパッケージ開発ワークフローを見てみましょう。
