Force.com上のアプリケーションをアップデートするには2種類の方法があります。

ひとつは、ユーザー組織の管理者が自ら行う手動アップデートです。もうひとつは、開発側がプッシュ型でユーザー組織に適用する自動アップデートです。Force.comでは、自動アップデートのことを「転送アップグレード（Push Upgrades）」と呼んでいます。
※参考資料：転送アップグレード運用手順（Version:Spring’12）

アプリケーションの利用者によっては、「クラウドベースのアプリケーションなのにアップデート作業が必要なの？」と思われるかもしれません。利用者にとっての手間が少なくなるよう、アプリケーション開発・提供者としては特別な理由のない限り転送アップグレードの活用が望ましいでしょう。

この転送アップグレード、Summer’12まではパッケージの「パッチバージョン」しか転送アップグレードができませんでした。これでは、コンポーネントの追加など重要な変更をした場合は、ユーザー組織の管理者による手動のアップデートが必要になります。

ですが、Winter’13ではこの仕組みが改善・強化され、「メジャーバージョン」の転送アップグレードがサポートされています。
※参考資料：Winter’13リリース「メジャーアップグレードのPUSH（転送アップグレード）」
※メジャーとパッチの違いについては「パッケージバージョンについて」をご参照ください。

アップグレードの手順

さて、アップグレードの手順を見て行きましょう。ご存じの方もいらっしゃるかも知れませんが、おさらいがてら、読み進めていただければと思います。

まず、下図のとおり、パッケージを開発している組織（以後、「開発組織」と呼びます）にログインしてから、[アプリケーションの設定] | [作成] | [パッケージ] | [（パッケージ名）] | [バージョン]を選びます。

画面中央部に「転送アップグレード」ボタンが表示されます。Salesforce.comパートナーになっている場合は、ボタンが表示されるはずです。表示されない場合は、パートナーの契約が必要になりますので、画面の説明に沿って登録を行いましょう。

次に、「転送アップグレード」をクリックしてスケジュール画面に遷移します。ここではアップグレードする「バージョン」と「開始日（時刻）」を選びます。

初期状態で現在の時刻になっていますので、すぐにアップグレードしたい場合はそのままにしておきます。ユーザの利用時間帯を避けて、深夜などの時間帯にアップグレードする場合、ここにスケジュールしたい時刻を入力します。

その後、下図のように「バージョン」を選ぶと、そのバージョンのアップグレード対象の組織がリストボックスで表示されます。たとえばバージョン2.1の対象は、それより古いバージョンの組織すべてになります。

あとはアップグレードしたい組織を選んでください。リストボックスは、組織IDや環境、バージョンでフィルタすることができます。組織を選んだらあと、「スケジュール」ボタンをクリックします。下図のように、「状況」が「処理中」になって、アップグレードが始まりました。

アップグレードをスケジューリングした場合、一旦「スケジュール済み」の状態になってから、予定時間がきたらアップグレードが開始されることになります。

以上が転送アップグレードの手順です。作業としては1分程度、ほんの2、3ステップでアップグレードを実施・スケジューリングすることができます。アップグレードが完了すると、下図のように、開発組織の管理者にメールが送信されます。これで一度に複数の組織をアップグレードしたときに、それらのうちどのくらいが成功したのかがすぐにわかります。

 

転送アップグレードを運用する際の注意点

さて、ここからは、私が転送アップグレードを運用するにあたっての注意点をポイント形式で挙げます。

1. メジャーバージョンの転送アップグレードを行う際は、パートナーポータルサイトからケースを登録し、セールスフォース・ドットコムに機能のアクティベーションを実施してもらう必要があります。これには通常2、3営業日をみておけばよいでしょう。
2. 組織のアップグレードが常に成功するとは限りません。対象組織がロックされている場合、アップグレードは失敗します。転送アップグレードの画面にはアップグレードの結果を表示する項目がありますが、ロック状態の組織がアップグレードに失敗してもここには何も表示されません（これは将来改善される予定だそうです）。
3. 組織によっては失敗することも考慮して、アップグレードは利用者がシステムにログインすることの少ない深夜帯に行い、また、アップグレードを実施する際は、失敗した組織の再実行を行う分も含めて、時間的余裕をもたせて計画するべきです。
4. 転送アップグレードのスケジュールおよび実行が利用者に通知されることはありません。必要であれば、事前・事後にアナウンスメントを行ったほうがよいでしょう。
5. 転送アップグレードでタブの設定を変更することはできません。これは、利用者の感知していないところでいきなりタブが増えたり消えたりすることを避けるため、あえて引き継がない仕様にしているのかもしれません。アップグレードによりタブの設定を変更する場合、管理者による設定が必要な旨を利用者に事前に通知するべきです。その他Winter’13のリリースノート（2018年4月現在、非公開になっています）にさらに詳しく転送アップグレードの留意点がまとめられています。
6. Sandboxと本番環境は分けてアップグレードした方がよいでしょう。リフレッシュや変更セットによって、組織がロックされていることが考えられるからです。
7. 利用者によっては自動的なバージョンアップを好まない組織もあるかもしれません。そのためにも事前にバージョンアップ内容のアナウンスを行い、必要に応じて転送アップグレードの対象から外しておくべきでしょう。

以上、注意しなければいけないことが何点かありますが、転送アップグレードを避けるべき大きな理由はないと私たち「Synergy!LEAD Engineering Team」は考えています。Force.com上のアプリケーションを運用する上で、転送アップグレードはほぼMustの機能ではないでしょうか。

※参考資料：ISVforceガイド

※記載されている内容は掲載当時のものであり、一部現状とは内容が異なる場合があります。ご了承ください。