パッケージ開発を使用した柔軟性の高いリリース

学習の目的

この単元を完了すると、次のことができるようになります。
  • パッケージ開発と変更セット開発の主な相違点を挙げる。
  • パッケージバージョンとはどのようなもので、組織の変更の管理にどのように役立つのかを説明する。
  • パッケージ開発モデルを使用する場合は、設定の変更を手動で追跡する必要がない理由を簡潔に説明する。

この単元では、Calvin と同僚が、変更セット開発モデルからパッケージ開発モデルに移行することにする理由を説明します。チームによってパッケージ開発のどの点にメリットがあるかが異なります。この単元を読み進めながら、あなたのチームに役立つ選択肢や、パッケージ開発のどの点にメリットがあるかを検討します。このモジュールの末尾に記載されているモジュールを受講してプロセスのハンズオン練習を行えば、習得した知識を基に自身に何が適しているのかを判断できます。

変更セットによる変更管理の課題

Zephyrus では、本番組織へのリリースごとにプロジェクト数や担当者数が増え続けています。ユーザにとっては嬉しいことです。同社では ALM の手順を一貫して実施しているため、機能強化を依頼した場合の処理時間が短く、中断が最小限に抑えられています。

けれども Calvin にとっては、こうした変更、特に複数のチームが行う関連性のない数々の変更を調整することが頭痛の種になっています。リリースの規模も複雑さも増大し続けています。リリースの全プロジェクトの変更をまとめてテストすることが困難になっていることから、Zephyrus の従業員に欠かせない機能がいつしか壊れるのではないかと懸念しています。

Calvin は毎回リリースで調整して追跡すべき変更があまりにも多いため、変更自体にもっと多くの時間を費やしたいと感じています。また、Zephyrus で Salesforce のカスタマイズを行っているチームが、その変更を他のプロジェクトの変更と調整するために費やす時間が減少すれば、生産性が向上するのではないかと考えています。

1 つのコンテナか複数のコンテナか?

Calvin は Salesforce Trailblazer Community の他のメンバーに、毎回リリースのプロジェクト数が多すぎる場合の管理法についてアドバイスを求めます。そして、Salesforce の新しい開発モデルによってリリース管理の柔軟性が向上するという話を聞きます。パッケージ開発というモデルです。

パッケージ開発では、各種のカスタマイズを、組織に対する変更の 1 つの大きなリリースではなく、個々のパッケージとして管理します。前述のとおり、変更セット開発では、複数のプロジェクトの変更セットを、1 つのコンテナにまとめるかのごとく管理していました。リリースが極めて複雑になり、組織を複数のコンテナにして管理したほうがよいと感じた時点で、パッケージ開発モデルへの移行を検討します。チームがすでに他のプラットフォームでモジュール式のリリースアーティファクトをビルドしている場合は、パッケージ開発での作業といくつかの類似点があることに気が付きます。

たとえば、Zephyrus では次のカスタマイズからなるパッケージを構成することが考えられます。

  • 社内でビルドしたカスタムの Force.com アプリケーション
  • Sales Cloud、Service Cloud などの拡張機能
  • AppExchange アプリケーションの拡張機能
  • 共有ライブラリや機能の更新

パッケージ開発モデルで作業する場合は、リリースアーティファクトをビルドする際、他のプロジェクトのアーティファクトとは関係なくテストやリリースできるようにします。チームは、本番組織にあるメタデータからの変更部分の集合体ではなく、関連するすべてのメタデータを含むパッケージを作成します。つまり、パッケージのメタデータに、変更済みと未変更の両方のコンポーネントが含まれます。

メタデータの更新をパッケージに整理すれば、組織のメタデータがどのような構造になっているかを認識しやすくなります。組織を複数のコンテナにして管理する場合、1 つのパッケージが 1 つのコンテナで表されます。

パッケージバージョンは、パッケージの中身と関連するメタデータの固定スナップショットです。パッケージバージョンを使用すると、パッケージに追加された特定の変更セットのリリース時に、その変更内容を追跡できます。メタデータの変更をリリース済みのパッケージに取り込むときは、現在のパッケージバージョンを新しいパッケージバージョンにアップグレードします。

Calvin は、パッケージ開発に移行すれば生産性が向上するだろうと意気込んでいます。Ernesto と CEO、そして Salesforce のカスタマイズを作成している他部門の部長に移行のメリットを説明します。その際、次の 3 点を強調します。

  • 組織のメタデータの経時的な変化を明示する変更履歴を作成する。
  • 現在設定の変更の追跡に費やしている時間を生産性の向上に充てる。
  • 各パッケージを、他のプロジェクトのパッケージとは関係なく、開発、テスト、リリースできるようにして、リリースの柔軟性を向上させる。

信頼できる情報源はソースのメタデータ

パッケージ開発では、パッケージプロジェクトのメタデータが信頼できる情報源になります。このため、VCS に容易に統合でき、チームが実施したプロジェクトの変更を管理しやすくなります。

変更セット開発の場合、信頼できる情報源は、環境内に既存のメタデータと、変更セットの最新ビルドを合わせたものです。変更セットには変更箇所 (差分など) しか含まれないため、それ自体が全体像を表すことはできません。

設定の変更の手動追跡の排除

パッケージ開発では、スクラッチ組織という開発環境を使用できます。Calvin とそのチームが各リリースで追跡しなければならない変更を大幅に減らそうとする場合、スクラッチ組織が重要な役割を果たします。

スクラッチ組織は空の組織で (メタデータもデータもありません)、必要に応じて簡単に作成や破棄できます。この組織を、機能や設定の異なるさまざまな Salesforce エディションに仕立てることができます。さらに、スクラッチ組織の定義ファイルは、VCS に統合されたプロジェクトの一部であるため、再利用や他のチームメンバーとの共有が可能です。このように、各人に独自の開発環境がありながら、全員がごく簡単に同じ組織設定で作業できます。

開発にスクラッチ組織を使用する場合は、最初にプロジェクトのソースを VCS に転送して、スクラッチ組織を同じメタデータに同期させます。開発に設定を使用する予定の場合は、実行した変更が自動的に追跡されます。実施した変更を取得してプロジェクトに含めることや、VCS を使用してすべての変更をコミットすることができます。

ヒント

ヒント

Calvin が、ソース追跡でどのコンポーネントがサポートされているのかを知るにはどうすればよいでしょうか? メタデータカバー率レポートを使用します。このレポートには、ソース追跡、メタデータ API、その他のメタデータチャネルでメタデータ型がサポートされているかどうかが表示されます。動的に生成されるこのレポートは、メタデータカバー率の最適な情報源です。メタデータカバー率レポートにアクセスするには、https://developer.salesforce.com/docs/metadata-coverage に移動します。

各パッケージは独立独歩

パッケージ開発では、パッケージごとに個別のリリーススケジュールを設定できます。組織のメタデータがパッケージにセグメント化されるため、各プロジェクトに独自のパッケージと連動パッケージが存在します。パッケージバージョンが新しくなるたびに個々のセグメントのアップグレードを独立して管理できるため、個々のリリーススケジュールを維持することが可能になります。

パッケージ連動関係とは? メタデータコンポーネントは、一度に 1 つのパッケージ内にしか存在できません。複数のパッケージで同じコンポーネントが必要な場合は、そのコンポーネントのモジュール式パッケージ戦略を考案します。パッケージ連動関係とは、複数のパッケージで共有される 1 つ以上のメタデータコンポーネントを含むパッケージです。

各パッケージ (とパッケージ連動関係) は、組織内の他のすべてのメタデータと切り離してテストすることができます。このようなメタデータを複数のパッケージに分離することで、特定のメタデータの集合体 (パッケージ) にのみ柔軟にバージョンを設定できます。また、特定のパッケージのみを柔軟にリリースすることも可能です。

次のステップ

Trailhead には、3 種類の開発モデルに対応するモジュールがあります。各モジュールを受講すれば、その開発モデルを使用して Salesforce のカスタマイズを作成する方法を習得できます。