パッケージへの移行の計画

学習の目的

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

モジュール形式 (パッケージ開発) のアプローチにシフトできる使用事例を識別する。
パッケージ開発に適していないシナリオを識別する。

次のステップ: パッケージへの移行の計画

パッケージ開発モデルの価値を理解したところで、先に進むことに関心をお持ちでしょう。では、どのようにして開始するのでしょうか? 次のステップは、本番組織とそれに関連する開発プロセスの複雑度と成熟度によって異なります。たとえば、次のような方法で始めることをお勧めします。

今がパッケージの採用に最適なタイミングである理由

以前は、パッケージは AppExchange でアプリケーションを作成して配布したいパートナーのためのものでした。ただし今では、企業と顧客のための新しいパッケージがあります。それがロック解除済みパッケージです。Salesforce のお客様、契約業者、コンサルタント、システムインテグレーターの皆さんにはロック解除済みパッケージがお勧めです。

機能の開発にロック解除済みパッケージを使用すれば、反復、スクリプト実行、追跡が可能な方法で、作業を整理し、変更を管理できます。

そして何よりも、Salesforce CLI と DX プロジェクトのおかげでロック解除済みパッケージの作成は簡単です。ロック解除済みパッケージは、あらゆる Salesforce 環境 (スクラッチ組織、Sandbox、トライアル組織、本番組織) にインストールできます。

詳細は、「顧客用ロック解除済みパッケージ」モジュールを参照してください。

チームの結成

「人はみな持ちつ持たれつ」という表現を聞いたことがあるでしょう。この格言は、チームにも当てはまります。多くの企業では、Salesforce の本番組織に多数の関係者がいます。パッケージ開発に乗り出す準備を整えるときに最初に行う作業の 1 つは、どのようにして組織のもつれを解くかということです。始める前に、チームに適切な人材を含めることが重要です。

「Package Development Readiness (パッケージ開発の準備状況)」に、パッケージ開発への移行準備を行うチーム結成のための戦略が含まれています。

組織からパッケージを分離する方法を探す

開発プロセスのすべての側面を評価して、モジュール形式のパッケージベースのアプローチに移行する方法を探します。本番組織で他から完全に分離されている個別のアプリケーションを探します。これらのアプリケーションの作成と保守を行う個別のチームがありますか? ある場合は、それらのアプリケーションを分離して独自のパッケージにすることができます。AppExchange には、ソースとメタデータのセットを 1 つのパッケージに分離するというこの考え方に沿ったスタンドアロンアプリケーションの良い例が数多くあります。

場合によっては、パッケージに分離できる個別のアプリケーションはないけれども、組織の中で長期にわたって使用されてきた個別の要素があることがあります。たとえば、1 つのコアアプリケーションの拡張機能をパッケージとしてリリースできます。会社のセールスプロセスをカスタマイズするときに行うすべての拡張を 1 つのパッケージに分離できます。これらの部分に固有のメタデータを分離できれば、それを使用してパッケージを開発できます。

また、他のチームとは別個にビルドと配信を行っているか、行うことを希望しているチームを探すこともできます。俊敏性と柔軟性を高める機会を探しているチームを見つけます。あるいは、チームの変更を本番組織の大規模な変更管理とは切り離したいと考えているチームもあるでしょう。そのようなチームはメタデータを分離して独自のパッケージに保存できます。

組織のメタデータを分離するのが非常に難しい場合は、組織連動ロック解除済みパッケージが適している可能性があります。組織連動ロック解除済みパッケージはロック解除済みパッケージのバリエーションですが、パッケージをインストールする組織 (インストール組織) のパッケージ化されていないメタデータに連動するパッケージを作成できます。

共有メタデータに注意

その過程で、共有メタデータコンポーネントがパッケージに含まれる可能性についてもすべて評価するようにします。特定のチームやアプリケーションが所有するパッケージに共有メタデータを誤って分離してしまわないようにする必要があります。メタデータコンポーネントが共有されている場合は、それらの共有コンポーネントを 1 つのベースパッケージにまとめることをお勧めします。こうすることで、すべてのパッケージが共有ベースパッケージ内のコンポーネントを参照できます。(メタデータコンポーネントは、同時に複数のパッケージ内に存在できません。)

パッケージプロジェクトの開始

可能性のあるパッケージを識別したら、メタデータ API を使用して、パッケージに関連するソースを取得します。Salesforce CLI とテスト組織を使用して、パッケージのコンポーネントを特定する package.xml を作成する手順を確認するには、「Salesforce DX を使用したアプリケーション開発」を参照してください。メタデータ形式でソースを取得したら、それをソース形式に変換します。

そして、各パッケージの VCS リポジトリを作成します。そこから、アプリケーション固有のパッケージを作成して、分離プロセスを続行します。

ローマは 1 日にして成らず

組織の中に成熟した組織や複雑な組織がある場合は、いずれ、パッケージに移行する必要がでてきます。本番組織は、かけがえのない大切なものですから、移行は慎重に計画しましょう。この単元のガイダンスを使用して、組織の中でパッケージに移行できる部分を識別します。一度に 1 つずつパッケージに移行し、継続的にプロセスを評価し、改善していきます。

パッケージ開発モデルについて理解を深めることができたので、次は実際に試してみましょう。