Salesforce 第二世代パッケージ (2GP) の徹底解説：開発者向けガイド

日付:

背景と応用シナリオ

Salesforce 開発者として、この記事を執筆します。Salesforce プラットフォームでのアプリケーション開発と配布の歴史において、パッケージングは常に中心的な役割を果たしてきました。従来の First-Generation Packaging (1GP) (第一世代パッケージ)、つまり管理パッケージや未管理パッケージは、長年にわたり AppExchange パートナーや多くの企業で利用されてきましたが、いくつかの課題を抱えていました。

1GP の主な課題は、その開発モデルが「組織駆動型」である点です。つまり、パッケージの「信頼できる唯一の情報源 (Single Source of Truth)」は、特定の開発組織（通称、パッケージング組織）でした。これにより、バージョン管理システム（Gitなど）との連携が複雑になり、チーム開発や自動化された CI/CD (継続的インテグレーション/継続的デプロイメント) パイプラインの構築が困難でした。すべての変更は、まずその組織にデプロイされ、そこからパッケージバージョンがアップロードされるという手間のかかるプロセスが必要でした。

こうした課題を解決するために登場したのが、Second-Generation Packaging (2GP) (第二世代パッケージ) です。2GP は、Salesforce DX (Developer Experience) ツールセットを基盤とし、Source-Driven Development (ソース駆動開発) モデルを採用しています。これにより、開発の源泉は Salesforce 組織ではなく、Git のようなバージョン管理システムになります。開発者は、ソースコードをリポジトリで管理し、そこから直接パッケージバージョンを作成・管理できるようになりました。

2GP の主な応用シナリオは以下の通りです。

  • ISV (独立系ソフトウェアベンダー) アプリケーション開発： AppExchange で配布される複雑なアプリケーションを、モジュール化された依存関係を持つ複数のパッケージとして構築し、開発ライフサイクル全体を自動化する。
  • 大規模な企業内開発： 企業の基幹システムを Salesforce 上で構築する際、機能ごとにパッケージを分割（Unlocked Packages を利用）し、チーム間の依存関係を管理しながら、迅速かつ安全にリリースサイクルを回す。
  • コンサルティングパートナーによるソリューション提供： 複数の顧客に共通のソリューションを導入する際、基本機能をパッケージ化しておくことで、迅速なデプロイと一貫した品質を保証する。

原理説明

2GP の仕組みを理解するには、Salesforce DX の中核をなすいくつかの概念を把握する必要があります。これらは相互に連携し、モダンな開発プロセスを実現します。

Dev Hub とスクラッチ組織

Dev Hub (開発ハブ) は、2GP の管理と運用の中心となる特別な Salesforce 組織です。通常、本番組織やビジネス組織で有効化します。Dev Hub は、開発やテストに使用する一時的な Salesforce 組織であるScratch Orgs (スクラッチ組織) の作成と管理、そして 2GP パッケージ自体のライフサイクル（作成、バージョン管理、プロモートなど）を統括します。

開発者は、Dev Hub に認証後、コマンドラインから数分でクリーンなスクラッチ組織を作成できます。このスクラッチ組織は、設定ファイルに基づいて構成され、開発や機能テストに最適な使い捨ての環境を提供します。開発が完了すれば、スクラッチ組織は破棄できるため、常にクリーンな状態で開発を開始できます。

sfdx-project.json ファイル

Salesforce DX プロジェクトのルートディレクトリには、sfdx-project.json という重要な設定ファイルが存在します。このファイルが、2GP の定義と管理の中心となります。ここでは、プロジェクト内のどのディレクトリがどのパッケージに対応するのか、パッケージ間の依存関係、ネームスペースなどを定義します。

例えば、複数のパッケージ（`core-library` と `feature-module` など）を一つのリポジトリで管理する場合、このファイルでそれぞれのパスと依存関係を明示的に指定します。これにより、Salesforce CLI はどのソースコードがどのパッケージに属するのかを正確に認識できます。

パッケージとパッケージバージョン

2GP では、「パッケージ」はメタデータの集合を定義する論理的なコンテナです。実際に組織にインストールされるのは、「パッケージバージョン」です。開発プロセスでは、Git のブランチやタグと連動させて、不変（イミュータブル）なパッケージバージョンを次々と作成していきます。

例えば、バージョン `1.0.0.1` を作成した場合、このバージョンに含まれるメタデータは永久に固定されます。バグ修正や機能追加を行う場合は、新しいバージョン（例: `1.0.1.0`）を作成する必要があります。この不変性により、どの環境にどのバージョンのコードがデプロイされているかが明確になり、リリース管理の信頼性が大幅に向上します。

パッケージバージョンは、まずベータ版として作成されます。十分なテスト（特に Apex テストコードカバー率 75% 以上）が完了した後、そのバージョンを「プロモート」してリリース版に昇格させることができます。一度リリースされたバージョンは、本番組織にインストール可能となります。

示例代码

ここでは、Salesforce CLI を使用して 2GP パッケージを作成し、バージョンを生成し、スクラッチ組織にインストールするまでの一般的なワークフローを示します。これらのコマンドは、Salesforce DX プロジェクトのルートディレクトリで実行することを前提としています。

1. パッケージの作成

最初に、sfdx-project.json 内でパッケージを定義します。このコマンドは、その定義に基づき、Dev Hub 組織にパッケージレコードを作成します。

sfdx force:package:create --name "My Awesome App" --description "Core functionality package" --package-type Unlocked --path force-app --target-dev-hub MyDevHubAlias

詳細な解説：

  • --name "My Awesome App": パッケージの表示名を指定します。
  • --description "...": パッケージの説明です。
  • --package-type Unlocked: パッケージの種別を指定します。ISV 向けには Managed を、企業内開発やモジュール化には Unlocked を使用します。
  • --path force-app: パッケージに含めるメタデータが格納されているディレクトリのパスを指定します。
  • --target-dev-hub MyDevHubAlias: このパッケージを所有する Dev Hub 組織のエイリアスを指定します。

このコマンドが成功すると、sfdx-project.json が更新され、パッケージ ID (0Ho...) が追記されます。

2. パッケージバージョンの作成

次に、現在のソースコードの状態から不変のパッケージバージョンを作成します。このプロセスは非同期で実行され、数分から数十分かかることがあります。

sfdx force:package:version:create --package "My Awesome App" --installation-key mysecretkey --wait 10 --target-dev-hub MyDevHubAlias --code-coverage

詳細な解説：

  • --package "My Awesome App": sfdx-project.json で定義したパッケージのエイリアスまたは名前を指定します。
  • --installation-key mysecretkey: パッケージのインストール時に要求されるパスワードを設定します。これにより、意図しないインストールを防ぎます。
  • --wait 10: コマンドの完了を最大 10 分間待機します。指定しない場合、コマンドはすぐに制御を返しますが、バックグラウンドで処理が続行します。
  • --target-dev-hub MyDevHubAlias: Dev Hub 組織のエイリアスです。
  • --code-coverage: パッケージ内の Apex コードのカバレッジを計算し、75% 未満の場合はバージョン作成を失敗させます。リリース版を作成する際には事実上必須のオプションです。

成功すると、パッケージバージョン ID (04t...) が出力されます。この ID は、インストールやプロモートの際に使用します。

3. パッケージバージョンのインストール

作成したパッケージバージョンを、テスト用のスクラッチ組織や他の組織にインストールします。

sfdx force:package:install --package 04t... --target-org MyScratchOrgAlias --installation-key mysecretkey --wait 10 --publish-wait 5

詳細な解説：

  • --package 04t...: インストールするパッケージバージョンの ID を指定します。`My Awesome App@1.0.0-1` のようなエイリアスも使用可能です。
  • --target-org MyScratchOrgAlias: インストール先の組織のエイリアスを指定します。
  • --installation-key mysecretkey: バージョン作成時に設定したインストールキーを入力します。
  • --wait 10: インストールの完了を最大 10 分間待機します。
  • --publish-wait 5: パッケージバージョンが利用可能になるまでの待機時間（分）です。バージョン作成直後は、Salesforce の内部的なレプリケーションに時間がかかることがあります。

注意事項

2GP を利用する際には、以下の点に注意する必要があります。

権限と設定

2GP を利用するには、まず Dev Hub 機能を有効にした組織が必要です。また、コマンドを実行するユーザーには、Dev Hub 組織で「第二世代パッケージの作成と更新」システム権限が必要です。さらに、管理パッケージ (Managed Package) を作成する場合は、AppExchange パートナーとして登録し、Dev Hub に関連付けられたネームスペースを登録する必要があります。

API 制限

パッケージバージョンの作成は、リソースを消費する非同期プロセスです。Salesforce は、24 時間以内に作成できるパッケージバージョンの数に制限を設けています。CI/CD パイプラインで頻繁にバージョンを作成する場合、この制限に達しないように設計する必要があります。例えば、すべてのコミットでバージョンを作成するのではなく、特定ブランチへのマージ時やタグ付け時にのみ作成するなどの工夫が考えられます。

依存関係の管理

2GP の強力な機能の一つは、パッケージ間の依存関係を明示的に定義できることです。sfdx-project.json ファイル内で、あるパッケージが別のパッケージの特定バージョンに依存することを宣言できます。依存関係を正しく管理しないと、バージョン作成の失敗やインストール時のエラーにつながります。循環参照（パッケージ A が B に依存し、B が A に依存する）は許可されないため、アーキテクチャ設計が非常に重要です。

Apex コードカバー率

管理パッケージ (Managed Package) のバージョンをベータからリリース版にプロモートするには、パッケージ内の Apex コードが 75% 以上のテストカバー率を満たしている必要があります（トリガー、クラスなどすべての Apex コードが対象）。この条件を満たさない限り、本番組織へのインストールが可能なリリース版を作成することはできません。--code-coverage オプションを付けてバージョンを作成することで、この要件を早期に確認できます。

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

Second-Generation Packaging (2GP) は、Salesforce 開発を従来の組織駆動型からモダンなソース駆動型へと進化させる、画期的なフレームワークです。Salesforce DX との統合により、開発者はバージョン管理、自動化、モジュール化といった現代的なソフトウェア開発プラクティスを Salesforce の世界に持ち込むことができます。

以下に、2GP を最大限に活用するためのベストプラクティスをまとめます。

  1. Git を唯一の信頼できる情報源とする： すべての変更は、まず Git リポジトリにコミットされるべきです。Salesforce 組織は、あくまで開発やテストのための一時的な環境と捉えましょう。
  2. CI/CD パイプラインを構築する： GitHub Actions, Jenkins, CircleCI などのツールを活用し、パッケージバージョンの作成、テスト、デプロイを自動化しましょう。これにより、手動エラーが減り、リリースサイクルが高速化します。
  3. アプリケーションをモジュール化する： 巨大なモノリシックなアプリケーションを、機能単位で複数の小さなパッケージに分割しましょう。これにより、各チームが独立して開発を進めやすくなり、依存関係も明確になります。
  4. スクラッチ組織を積極的に利用する： 新機能の開発やバグ修正は、必ずクリーンなスクラッチ組織で開始しましょう。これにより、他の開発者の作業や既存の設定からの予期せぬ影響を防ぐことができます。
  5. Unlocked Packages を社内開発に活用する： 2GP は ISV だけのものではありません。Unlocked Packages を利用すれば、企業内の大規模開発プロジェクトにおいても、ソース駆動開発の恩恵を享受できます。

2GP への移行は、学習コストや設計の見直しが必要ですが、その投資は、開発の効率性、品質、およびスケーラビリティの向上という形で、間違いなく大きなリターンをもたらすでしょう。開発者として、この強力なツールを使いこなし、より高度な Salesforce アプリケーション開発を目指すべきです。

コメント

コメントを投稿