進行状況の追跡を始めよう
Trailhead のホーム
Trailhead のホーム

新しい情報源を思い描く

学習の目的

この単元を完了すると、次のことができるようになります。
  • 変更セットおよび組織開発モデルとモジュール形式のパッケージ開発の違いを説明する。
  • パッケージ開発の利点を挙げる。
  • パッケージの主要な特性を説明する。

全世界は 1 つの組織

かつて、ある有名な役者 (あるいは Salesforce の先見者だったかもしれません) がこう言いました。「全世界は 1 つの組織である。」従来、この世界の中心は本番組織であり、開発の大部分は、Sandbox または本番組織の範囲内で行われていました。(AppExchange パートナーの場合は、世界が少し異なりますが、この単元で紹介するツールは同じように使用できます。)

従来の変更管理方法

「アプリケーションのライフサイクルと開発モデル」モジュールを修了した方は、Zephyrus Relocation Services のシステム管理者である Calvin Green を覚えているでしょう。Zephyrus が成長するにつれて、本番組織の複雑度も増してきました。増加する変更を管理するために、Calvin は健全なアプリケーション管理ライフサイクルを採用し、管理セットを使用して新しい機能、カスタマイズ、アプリケーションを本番組織にリリースしました。変更セットとは、差分を組織から別の組織へと移動するリリースアーティファクトです。Calvin はまず宣言型変更セット開発を採用し、次にプログラム型変更セット開発への移行を先導しました。

変更セット開発モデルで開発チームがどのように作業するかを見てみましょう。

あなたは、変化の速いハイテク企業の開発リーダーです。リリースのために、CRM コアアプリケーションをカスタマイズする必要があり、さらに社内アプリケーションも構築したいと考えています。開発の最初のステップは、本番組織の最新のスナップショットがあることを確認することです。組織ベースのモデルでは、本番組織がすべてのコード、設定、カスタマイズの情報源です。

何を作成しているかに関係なく、リリースの最終的な対象は本番組織です。次の図に示すとおり、複数のチームが別々の開発プロジェクトに取り組んでいたとしても、各々の更新の開発とリリースは同じリリースに対して行われます。すべてが 1 つの package.xml に集約されます。

組織ベースの開発フローの開発、ビルド、1 つのリリース


最初のリリースで、2 つの新しいプロジェクトに取り組んでいるとします。

(1) プロジェクト (1) 開発 (2) メタデータ API (package.xml)
CRM 拡張機能/カスタマイズ (最初のリリース) カスタムオブジェクト (追加)

カスタム項目 (追加)

ページレイアウト (追加)

ワークフロー (追加)

Apex クラス: 1

Visualforce ページ: 1

カスタムオブジェクト: 2

カスタム項目: 2

ページレイアウト: 1

ワークフロー: 1
休暇管理アプリケーション (最初のリリース) カスタムオブジェクト (追加)

カスタム項目 (追加)

Apex クラス (追加)

Visualforce ページ (追加)
(3) - すべてが本番組織で一緒にリリースされます。

2 回目のリリースでは、マイナー更新を行います。ただし、その場合も両方のプロジェクトを同時に本番組織にリリースします。

(1) プロジェクト (1) 開発 (2) メタデータ API (package.xml)
CRM 拡張機能/カスタマイズ (最初のリリース) カスタムオブジェクト (更新)

ワークフロー (更新)

Visualforce ページ: 1

カスタムオブジェクト: 2

ワークフロー: 1
休暇管理アプリケーション (最初のリリース) カスタムオブジェクト (更新)

Visualforce ページ (更新)

(3) - すべてが本番組織で一緒にリリースされます。

開発者やリリースマネージャは、組織を一連のコードやカスタマイズが混ざり合ったものとして考えます。要点を理解するために、もう一度、図を見てください。最終的なリリースには、休暇管理アプリケーションや CRM 拡張機能のみではなく、組織に対するすべての変更が含まれています。

開発中には、本番組織に何をリリースするかがわかるように変更内容を追跡する必要があります。あなたが行った変更は、他のユーザが行った変更と混ざり合うため、このような追跡は複雑で、ある程度手動での作業になる場合があります。このプロセスでソース制御を使用する場合は、ソース制御システムで同じようにコードとカスタマイズが混ざり合うことになります。ソースリポジトリは、組織の一部 (休暇管理アプリケーションなど) ではなく組織に連携します。

けれども、混ざり合ったスープが複雑になりすぎて、変更を管理するためのもっと良い方法が必要な場合はどうすればよいでしょうか? 従来の開発モデルに従ってアプリケーションやソリューションを配信してリリースしたいと考えていますか?

パッケージ開発による変更の管理

Zephyrus は成長を続けてきたために、リリースはますます複雑になっていました。複数の開発チームがあり、複数の Salesforce システム管理者がいる中で、Calvin は巨大なリリーストレインからプロジェクトを分離する方法を追及したいと考えていました。パッケージ開発モデルを使用すれば、開発ライフサイクル全体が合理化され、次のような利点があります。

  • チーム開発とコラボレーションの向上。
  • パッケージ間の連動関係の仕様に基づくモジュール形式開発プロセス。
  • 変更管理に役立つバージョン管理。
  • 自動テストと継続的インテグレーションの促進。
  • リリースサイクルの効率と俊敏性の向上。
  • 設定機能の変更追跡によるバージョン管理システム (VCS) 同期の改善
  • 本番組織の変更管理に対するより詳細な可視性と明確性

これはどういう意味でしょうか? 組織のコードやカスタマイズをビルドする代わりに、パッケージ (論理的なコードセット) を作成します。パッケージとは、関連するコードやカスタマイズのグループであるリリースアーティファクトです。

パッケージ内のコンポーネントのグルーピングによって、さまざまなことを表すことができます。パッケージを、営業チームをサポートするために作成されたカスタマイズのセットにすることができます。1 つのパッケージで、組織内で作成しているアプリケーションの Lightning コンポーネント、オブジェクト、およびワークフローを表すことができます。1 つのパッケージで、AppExchange からインストールした管理パッケージ用に開発中の複数の拡張機能を表すことができます。

この新しいプロセスを使用すれば、組織を一連のパッケージとして整理できます。ソースとメタデータをパッケージとして整理することで、組織内のメタデータコンポーネント間の関係が理解しやすくなります。組織が大きくなるほど、このプロセスが重要になるため、早い段階で計画し、組織をどのように整理するかについて常に考えましょう。

VCS は開発者にとって非常に便利なもので、パッケージ開発のライフサイクルにおいて不可欠な役割を担っています。パッケージのすべてのソースをソース制御リポジトリに保存します。ここで情報源が維持されます。スクラッチ (開発) 組織はそのソースからビルドされるため、ユーザはパッケージを特定して作業を行うことができます。変更追跡機能があり、ユーザが開発組織で作成、更新、削除した内容を監視できます。変更されたソースを簡単に自分のファイルシステムに取得し、VCS にチェックインできます。

パッケージ開発では、より柔軟にチームやリリースを管理できます。特定のパッケージを所有するチームを割り当てることができます。複数の開発チームが別々に開発を行い、組織への更新のリリースではなくパッケージのリリース用にビルドできます。次の開発、ビルド、リリースのフローからわかるように、このアジャイルなモデルでは、より頻繁に独立したリリースを行うことができます。

エンタープライズのお客様には、特殊なパッケージ種別である、ロック解除済みパッケージがあります。これは、特に社内用のビジネスアプリケーションに適しています。

ロック解除済みパッケージによる柔軟性の提供

ロック解除済みパッケージによって、CRM のカスタマイズと休暇管理アプリケーションのリリース方法がどのように変わるかを見てみましょう。

アーティファクトベースの開発フローの開発、ビルド、リリース


この例の最初のリリースでは 2 つの新しいプロジェクトを作成しています。どちらもバージョンは 1.0 で、メタデータ API を使用して別個にビルドし、本番組織にリリースできます。

(1) 開発 (2) ビルド (3) リリース (package.xml)
CRM 拡張機能/カスタマイズ v1.0 カスタムオブジェクト (追加)

カスタム項目 (追加)

ページレイアウト (追加)

ワークフロー (追加)
カスタムオブジェクト: 1

カスタム項目: 1

ページレイアウト: 1

ワークフロー: 1
休暇管理アプリケーション v1.0 カスタムオブジェクト (追加)

カスタム項目 (追加)

Apex クラス (追加)

Apex ページ (追加)
Apex クラス: 1

Apex ページ: 1

カスタムオブジェクト: 1

カスタム項目: 1

次のリリースでも、前と同じように、本番組織とは独立して各パッケージバージョンをビルドし、リリースできます。これにより、各リリースアーティファクト (パッケージ) ごとに異なるバージョンを維持できます。
(4) 開発 (5) ビルド (6) リリース (package.xml)
CRM 拡張機能/カスタマイズ v1.1 カスタムオブジェクト (更新)

ワークフロー (更新)
カスタムオブジェクト: 1

カスタム項目 (変更なし)

ページレイアウト (変更なし)

ワークフロー: 1
休暇管理アプリケーション v2.0 カスタムオブジェクト (更新)

Apex ページ (更新)
Apex クラス (変更なし)

Apex ページ: 1

カスタムオブジェクト: 1

カスタム項目 (変更なし)

このプロセスは、CI や CD にも適用されます。パッケージをビルドすることで、プロジェクト専用に設計されたテスト計画を作成できます。テスト計画を自動化し、ソースが VCS を通じて変更されたときに複数の環境でテストを実行することによって、品質レベルを維持できます。