Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

管理 2GP パッケージ開発の利点を理解する

学習の目的

この単元を完了すると、次のことができるようになります。

  • パッケージ開発に管理 2GP を使用する利点を説明する。
  • パッケージ系図とブランチの両方で俊敏なパッケージ開発がどのようにサポートされているかを説明する。

ソース制御と継続的インテグレーションを使用した業界のベストプラクティスに従う

Get Cloudy は Salesforce パートナーです。Get Cloudy のエンジニアは以前管理 1GP パッケージを公開したことがありますが、今度の Expense Manager アプリケーションでは、管理 2GP を使用してパッケージを作成することにしました。管理 2GP はソース駆動型開発モデルを使用するため、Get Cloudy のパッケージメタデータはバージョン管理システムに保存されます。これが管理 2GP が管理 1GP より大きく優れている点です。管理 1GP の場合、パッケージ化組織にリリースされたメタデータが信頼できる情報源になります。管理 2GP を使用すると、確実に時系列に沿って変更を追跡しやすくなります。 

管理 1GP 開発者の方へ: 管理 2GP にはパッケージ化組織やパッチ組織は必要ありません。パッケージごとに一意の組織を維持する必要がなくなりました。

管理 2GP では API ファーストで CLI 指向の開発モデルが使用されることがわかっているため、Get Cloudy のエンジニアは Salesforce CLI を使用してすべてのパッケージ化操作を自動化しています。継続的インテグレーション (CI) ジョブを使用してエンドツーエンドの自動化を作成する予定です。 

CI ジョブは、ソースリポジトリに対するプルリクエストが作成されたときに起動します。このジョブでパッケージバージョンが作成され、スクラッチ組織が作成され、パッケージが組織にインストールされます。次に、インストールされたパッケージが正しく機能することを検証する自動テストが実行され、テスト結果がメールでリリースマネージャーに送信されます。Get Cloudy の開発者は、こうしたステップを自動化することで節約した時間を、パッケージの他の側面に取り組むために使うことができます。 

小さなモジュール式パッケージ間でコードを共有する

すべての管理 2GP に同じ名前空間を割り当てることができます。実際、1 つの名前空間を使用すると、パッケージ間のインタラクションが容易になることがわかると思います。その理由は次のとおりです。

名前空間を共有する管理 2GP は、名前空間内のすべてのパッケージで公開 Apex クラスとメソッドを共有できます。@namespaceAccessible アノテーションを Apex クラスに追加すると、その名前空間内のすべてのパッケージでそのクラスが使用可能になります。また、公開 Apex を使用することで、グローバル API を公開してグローバル Apex フットプリントが大きくなることはありません。

管理 2GP では、相互に連動する小さなパッケージを簡単に作成してパッケージ間でロジックを共有できます。小さなモジュール式のパッケージを利用するようにアプリケーションを設計すると、パッケージの作成とパッケージのインストールが高速化され、制限に達する可能性も低くなります。 

このアプローチでは、アプリケーション間でのコードの再利用もサポートされます。共通のユーティリティコードを使用するパッケージを、複数の公開済みパッケージで使用することができます。アプリケーションごとにコードを繰り返す必要はありません。

メモ: 名前空間を後で変更することはできません。将来的にパッケージを売却することを考えている場合、パッケージ名前空間を一意にする必要があります。このシナリオでは、すべてのパッケージに 1 つの名前空間を使用することは適切なアプローチではありません。

管理 2GP パッケージの柔軟なバージョン管理

管理 2GP がソース駆動型開発モデルであることと、管理 2GP ではパッケージ間で Apex コードを共有できることについて説明しましたが、管理 2GP の素晴らしさはパッケージバージョン管理の柔軟性にあります。

上位パッケージとは、管理 2GP で使用されるツリー状のバージョン構造を表す用語です。上位パッケージは管理 2GP バージョン管理が柔軟である理由の 1 つで、不要になったパッケージバージョンを破棄することができます。

上位パッケージツリーの例

この図を使って上位パッケージの利点を説明していきます。図を単純化するために、パッケージバージョン番号の最初の 2 桁 (メジャー値とマイナー値) のみを表示しています。

2 つのパッケージバージョンが破棄されている上位パッケージツリーの図。1.1 から 1.3、1.4 から 1.5 にスキップし、1.2 と 1.5 が破棄されている。

たとえば、チームがバージョン 1.0、1.1、1.2 を順に作成します。ところが、1.2 で 1.1 を台無しにしてしまいました。でも大丈夫です。新しいパッケージバージョンを作成するときには、どのパッケージバージョンが上位パッケージであるかを指定することになっているため、1.2 を破棄して、1.1 を 1.3 の親パッケージに指定します。これであなたの猫が入力しためちゃくちゃなコードをすべて無視できます! また、このプロセスは繰り返すことができます。たとえば、この図では 1.5 を破棄して、1.4 から 1.6 をビルドしています。

メモ

パッケージバージョンを破棄できるのは、お客様をそのバージョンにまだアップグレードしていない場合のみです。 

管理 2GP では、新しいパッケージバージョンごとに上位パッケージを指定する必要があります。上位パッケージを指定する柔軟性は、パッケージの変更と拡張を時系列的に整理するのに役立ちます。

上位パッケージとその利点については、このモジュールでは説明しきれません。詳細については、『Second-Generation Managed Packaging Developer Guide (第二世代管理パッケージ開発者ガイド)』の「Package Ancestors (上位パッケージ)」を参照してください。 

ソース駆動型開発と上位パッケージの組み合わせにより、ソース制御で基盤となるバージョンを選択し、不要になったパッケージバージョンを破棄するという両方の柔軟性が得られます。線形バージョン管理モデルである管理 1GP を使用してパッケージを開発したことがある方にとっては、この新しいモデルで開発プロセスがより俊敏になり、脆弱性が軽減されます。

ソース管理システムのブランチに基づいてパッケージバージョンを開発する

開発チームがソース管理システムでブランチを使用している場合は、特定のブランチのメタデータに基づいてパッケージバージョンをビルドできます。パッケージバージョンを作成するときに、ソース管理システムのブランチの名前でタグ付けします。このタグ付けにより、特定のブランチに基づいたパッケージバージョンを簡単に識別できます。  

複数の作業ストリームを並行して開発できる

柔軟なパッケージバージョン管理により、管理 2GP では複数の開発チームが容易に同じパッケージで並行して新しい機能を作成し、適宜マージすることができます。Get Cloudy の開発者たちが管理 2GP を使用してパッケージをどのように並行開発するかを見てみましょう。 

Get Cloudy は、お客様に 3 つのパッケージバージョンをリリースしています。

  • バージョン 1.0.0.0
  • バージョン 1.1.0.0
  • バージョン 1.2.0.0

アプリケーションの新機能を開発するために、Get Cloudy は 2 つの開発チーム (開発 A チームと開発 B チーム) を作ります。最新のリリース済みパッケージバージョン 1.2.0.0 のコードを使用して、開発 A と開発 B の両チームがソース管理システムにそれぞれ独自のブランチを作成します。ブランチを作成することで、他のチームをブロックしたり、メインブランチに干渉したりすることなく、各チームで機能の開発とテストを行います。 

図が示すように、機能開発は、2 つのチームの作業をマージしてバージョン 1.3.0 が作成されるインテグレーションフェーズまで、並行して行われます。

パッケージ開発の柔軟なバージョン管理アプローチでは、以下がサポートされます。

  • メインブランチを引き継がずにビルドとテストを行う
  • 未リリースバージョンを容易に破棄する
  • チームの俊敏性と開発速度が向上する

また、新しいことを試すことへの不安が取り除かれ、アプリケーションの品質向上と市場投入までの時間短縮につながります。 

なぜ管理 1GP から管理 2GP に移行するのか?

管理 1GP パッケージを開発している場合、管理 2GP のソース駆動型開発モデルは、これまで使用してきた組織ベースの開発モデルとは大きく異なります。管理 2GP には管理 1GP にはない利点が多くあります。 

管理 2GP を使用すると、多くのパッケージ化組織やパッチ組織で作業するときに発生する退屈な作業や混乱が解消されます。管理 2GP では、組織とのインタラクションはほとんどありません。代わりに、Salesforce CLI と開発環境での開発に時間を費やします。また、ご存じかもしれませんが、Salesforce は管理 1GP パッケージを管理 2GP に移行する機能の開発にも取り組んでいます。ただし、この機能を導入したとしても、管理 1GP パッケージとそれを使用しているお客様を管理 1GP から管理 2GP に移行するための作業があります。新しいパッケージに管理 2GP を今採用することで、将来的に移行の手間を省くことができます。

管理 2GP を使用してパッケージを開発する利点について説明しました。次は管理 2GP パッケージ開発で使用するツールを見てみましょう。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む