提供内容の決定

学習の目的

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

  • パッチとアップグレードとは何かを定義し、それぞれの例を挙げる。
  • パッケージバージョン番号の意義を説明する。
  • パッチとアップグレードの作成方法を説明する。

ビジネスは好調! 次のステップ

PartnerX の主任開発者であるあなたは、AppX が AppExchange で大成功したことに誇りを感じています。お客様からフィードバックが寄せられており、次のステップについてブレインストーミングをしています。AppX の改善方法についてのアイデアには事欠きません。

では何を優先し、改善項目をどう提供すればよいのでしょうか? これらの質問への答えを出すには計画が必要です。お客様はすでにソリューションを使用しているので、導入が難しい変更もあります。理想は、AppX の他の操作性と同様、アップグレードプロセスをお客様にとって常に満足のいくものにすることです。

更新の計画

製品に加える更新には次の 2 種類があります。

  • パッチ — ユーザエクスペリエンスの外見的な更新や、バグ修正など、製品の動作に影響しない軽微な変更。
  • アップグレード — 製品の動作や顧客の操作方法が変わる機能の新規追加や大幅な変更。

たとえば、一貫性のない表示ラベルを見つけて修正したり、お客様のデータを更新する数式の不具合を修正したりする場合があります。こうした変更にはパッチが適しています。

お客様に約束した素晴らしい新機能の場合は、アップグレードを使用します。アップグレードでは、ワークフローの改善やデータモデルの変更など、大幅な変更ができます。

先に進む前に、変更に関する情報を伝えるためのシンプルなツールである、バージョン番号について確認しましょう。

パッケージのバージョン

私たちは多くのソフトウェアバージョン番号を見てきました。大まかに言えば、番号が大きいほどよい製品であることを意味します。そこを目指しましょう!

Salesforce には、製品のパッケージをバージョン管理するための明快で使いやすい形式があります。最新バージョンの AppX を見てみましょう。

AppX バージョン 2.1.3

このバージョンには 3 つの部分があります。

  • メジャーバージョン番号 (2)。メジャーバージョン番号の変更は、製品に対する大規模で抜本的な変更を示します。
  • マイナーバージョン番号 (1)。マイナーバージョン番号は、製品に機能を追加したり、目に見える変更を加えたりするものの、基本的な動作は以前と同じ場合に変更されます。
  • パッチバージョン番号 (3)。パッチバージョン番号は、製品をパッチで更新するたびに変更されます。

パッチバージョン番号は容易に管理できます。パッケージのパッチを作成するたびに、自動的に変更されます。

メジャーおよびマイナーバージョン番号は、製品をアップグレードすると変更されます。メジャーバージョンとマイナーバージョンの最大の違いは、マイナーバージョンのアップグレードを実施しても、通常、お客様はアプリケーションの使用方法を変える必要がない点です。

アップグレードの変更がメジャーかマイナーかは、パートナーが決めます。バージョン番号を使用して、お客様の期待を管理してください。

実際にはどのようにパッケージを変更するのでしょうか? まず最も簡単なパッチから確認しましょう。

パッチの作成

基礎となるデータモデルやビジネスロジックに影響を与えない変更を加える場合は、パッチを使用します。パッチは、メジャーリリースからのみ、また、管理パッケージに対してのみ作成できます。

パッチを作成するときには、パッチ開発組織で作業します。これは、既存のインストール環境に影響を与えない変更のみが許可される特殊な組織です。AppExchange パートナーは、Salesforce パートナーコミュニティでケースを登録して適切な権限を取得すると、パッチ開発組織を作成できます。

パッチ開発組織で作業する場合、次の操作を実行できません。

  • パッケージコンポーネント、Web サービス、連動関係の新規追加
  • 既存のパッケージコンポーネントの削除、Apex メソッドの非推奨化
  • API または動的 Apex アクセス制御の変更

すべての制限のリストについては、『ISVforce ガイド』を参照してください。

パッチ開発組織は、環境ハブではなく、パッケージ組織を使用して作成します。作成したパッチ組織を環境ハブに接続できます。

パッチ組織を作成する手順は、次のとおりです。

  1. パッケージ組織の [設定] から、[クイック検索] ボックスに「パッケージ」と入力し、[パッケージ] を選択します。
  2. 管理パッケージ、[パッチ組織] タブ、[新規] の順にクリックします。
  3. [メジャーリリースへのパッチ適用] 選択リストから、パッチを適用するパッケージバージョンを選択します。リリースの種類は、「管理-リリース済み」である必要があります。
  4. パッチ組織へのログイン用のユーザ名と、関連付けられたメールアドレスを入力します。ユーザ名は、バージョンを選択すると生成されますが (下記スクリーンショットを参照)、変更できます。メールアドレスは、組織のログイン情報とパスワードリセットを受信するメインのメールアドレスにする必要があります。これらは、パッチ開発組織固有です。 パッケージマネージャの [パッチ開発組織の作成] セクションで新しいパッチ開発組織のユーザ名とメールアドレスを入力します。
  5. [保存] をクリックします。

パッチ開発サイクル

たとえば、アプリケーションのバージョン 2.0 を変更するとします。パッチ組織を作成し、そこで 2 つのパッチ (バージョン 2.0.1 と 2.0.2) を作成します。後で、これらのパッチをバージョン 3.0 としてマージし、アップグレードとして配布します。

パッチはメジャーバージョンから作成され、パッチ開発組織内で開発され、メジャーまたはマイナーアップグレードでメインの開発組織に再びマージされます。

パッチをバージョン 3.0 にマージしたら、このパッチ組織での作業は終了です。バージョン 3.0 へのパッチ用に別のパッチ組織を作成します。

詳細は、『ISVforce ガイド』を参照してください。

アップグレードの作成

製品に大幅な変更 (新しいオブジェクトとビジネスロジック、Lightning コンポーネント) があり、お客様に配布する必要がある場合、パッケージのアップグレードを作成します。アップグレードできるのは管理パッケージのみです。

一部のコンポーネントはアップグレードできません。アップグレード可能なコンポーネントについての詳細は、『ISVforce ガイド』を参照してください。

パッケージの新バージョンの作成

開始する前に、アップグレードがメジャーまたはマイナーのどちらのバージョン変更に該当するかを決定します。これにより、変更に対する注意をお客様に促します。

パッケージからコンポーネントを削除する場合は、Salesforce パートナーコミュニティでサポートケースを登録し、パッケージ組織で「コンポーネントの削除」権限を有効にします。削除できるのは特定のコンポーネントのみです。詳細は、『ISVforce ガイド』を参照してください。

新規管理パッケージを作成するのと同じ方法でアップグレードを作成します。

  1. 開発組織の [設定] から、[クイック検索] ボックスに「パッケージ」と入力し、[パッケージマネージャ] を選択します。次に、使用可能なパッケージのリストからパッケージを選択します。 [パッケージ] の [パッケージマネージャ] ページでパッケージを選択します。
  2. [コンポーネント] サブタブに、変更するコンポーネントが新しい連動関係と一緒に表示されます。コンポーネントを手動で追加するには、[追加] をクリックします。 [パッケージの詳細] ページでパッケージにコンポーネントを追加します。
  3. 適切なコンポーネントの種類を選択し、目的のコンポーネントの横にあるチェックボックスをオンにし、[パッケージに追加] をクリックします。以下では [Active (有効)] および [Customer Priority (顧客優先度)] カスタム項目を追加しています。 [パッケージの詳細] ページでパッケージにカスタムコンポーネントとカスタム項目を追加します。
  4. パッケージを作成する準備ができたら、[アップロード] をクリックしてパッケージの新バージョンを作成します。[パッケージのアップロード] ページが表示されます。 [パッケージのアップロード] ページでアップロード前にパッケージの詳細を入力します。
  5. [バージョン名] 項目で、パッケージのバージョンに名前を付けて以前のバージョンと一貫性を持たせます。[バージョン番号] 項目には、推奨バージョン番号が含まれていますが、上書きできます。
  6. [アップロード] を再度クリックして、パッケージの作成を完了します。
  7. AppExchange のパッケージへのリンクが記載されたメールが送信されてきます。このアップグレードを手動でインストールするお客様には、このリンクを共有します。情報の伝達には、ライセンス管理アプリケーション (LMA) にあるインストール済みユーザのリストを使用します。

とにかくシンプルに

パッケージマネージャでは、パッケージの以前のバージョンを非推奨にできます。これにより、お客様が以前のバージョンをインストールするのを防ぐことができますが、既存のインストール環境は引き続き機能します。こうすることでメンテナンスが容易になります。

[パッケージの詳細] ページでアプリケーションの旧バージョンを非推奨にできます。

次の単元では、メンテナンスに戻ります。

最後の仕上げ

予定していた変更をすべて加え、厳密にテストし、管理パッケージをアップロードしました。もう少しで完了です。製品をお客様に提供する前にしなければならないことも残りわずかです。

セキュリティレビュー

AppExchange で製品を提供しているならば、Salesforce では信頼が最優先事項であることをご存じでしょう。アプリケーションは Salesforce のセキュリティレビュープロセスに合格しなければなりません。パッチとアップグレードもアプリケーションと同じセキュリティ標準を満たす必要があります。

幸い、パッチやアップグレードのすべてで完全なセキュリティレビューが必要というわけではありません。製品のリストを更新すると、Salesforce セキュリティ業務チームが 24 時間以内にコードをレビューします。

セキュリティレビュープロセスについて再確認するには、「AppExchange セキュリティレビュー」モジュールを参照してください。

アプリケーションリストの更新

ピカピカの新製品が準備できたら、次は AppExchange のリストを更新します。

  1. Salesforce パートナーコミュニティから、[公開中] に移動します。リストを選択します。 公開コンソールの [リスト] タブでアプリケーションのリストを選択します。
  2. [アプリケーション] タブに移動します。[このリストにリンクするパッケージは?] で、[パッケージを選択] をクリックします。 公開コンソールの [アプリケーション] タブでアプリケーションのリストを更新します。
  3. リストからパッケージを選択します。 選択可能なパッケージのリスト。
  4. [保存] をクリックします。 公開コンソールの [アプリケーション] タブ。[保存] ボタンが赤枠で囲まれています。

無料トライアルの更新

機能制限トライアルや Trialforce を使用してお客様に製品の無料トライアルをそれでは進みましょう。同時にトライアルも更新しましょう。方法は、提供するトライアルの種別によって異なります。

  • インストール可能トライアル — お客様はそれぞれの組織にトライアルをインストールします。リストが最新であることを確認します。お客様は新しいバージョンをインストールできます。
  • 機能制限トライアルまたは Trialforce — 新しいバージョンをトライアルソース組織にインストールし、新しいトライアルテンプレートを作成します。テストデータの更新と、テンプレートのセキュリティレビュー申請を忘れずに行ってください。

お客様に無料トライアルを提供していない場合は、「AppExchange アプリケーションのトライアル管理」モジュールを参照してください。

これで終了です。製品の新バージョンを使用できる状態になりました。次は、お客様に SaaS スタイルで更新を配布する方法を見てみましょう。

リソース

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる