新しい情報源を思い描く

学習の目的

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

• 組織開発のモデルとモジュール形式のパッケージ開発の違いを説明する。
  
• パッケージ開発の利点を挙げる。
  
• パッケージの主要な特性を説明する。
  

全世界は 1 つの組織

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

従来の変更管理方法

「組織開発モデル」モジュールを修了した方は、Zephyrus Relocation Services のシステム管理者である Calvin Green を覚えているでしょう。Zephyrus が成長するにつれて、本番組織の複雑度も増してきました。こうした増大する変更を管理するために、Calvin は Salesforce の最新の開発ツールを導入して、チームのアプリケーションのライフサイクルを管理することにしました。

では、開発チームが組織開発モデルを使用してどのように作業するのか見てみましょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のリリースでも、前と同じように、本番組織とは独立して各パッケージバージョンをビルドし、リリースできます。これにより、各リリースアーティファクト (パッケージ) ごとに異なるバージョンを維持できます。

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

リソース

• 開発者ガイド: Salesforce CLI Command Reference (Salesforce CLI コマンドリファレンス)
• 開発者ガイド: Salesforce DX 開発者ガイド
• Trailhead: クイックスタート: Salesforce DX
• Trailhead: 顧客用ロック解除済みパッケージ