Checklist for Upgrading to Liferay DXP

Liferay DXP（7.0、7.1、7.2、または7.3）へのアップグレードは主要なプロジェクトであり、そのように扱うべきです。この記事は、アップグレードプロセスの概要を説明することを目的としており、お客様に一般的なチェックリストを提供します。これは、公式ドキュメントおよびサポートナレッジベース記事の補足です。最も重要なこととして、管理者は常に環境固有のドキュメント（Tomcat用のApache、WebSphere用のIBMなど）を確認する必要があります。

この記事の範囲は、Liferay Portal 6.2 以降からLiferay DXP 7.xにアップグレードするお客様に限定されます。

全体的なプロジェクト管理
アップグレード環境を準備する
ドキュメントを参照する
バックアップを作成する
レガシー環境の問題を解決する
カスタマイズの更新
アップグレードシミュレーションの実行
「アップグレードプロセス中にエラーが発生した場合、どうすればよいですか？」
アップグレード後

1.全体的なプロジェクト管理

アップグレードする前に、システム管理者は次のことを行う必要があります。

関係する人員とリソースを特定します。
リスクを特定し、リスクを軽減するための計画をします。
ロールバック戦略を作成します。
Liferayの営業担当者に問題の可能性について通知するか、Liferay Global Servicesに最初にアップグレードの分析を実施させます。
問題が発見されたら、ヘルプセンターのチケットを開きます。

2.アップグレード環境を準備する

必要な環境を選択する前に、 Liferay DXP 互換性マトリックス ( DXP 7.0 | DXP 7.1 | DXP 7.2 | DXP 7.3) を参照して、サポートされているかどうかを確認してください。

各Liferay DXP JVMの最小要件については、デプロイメントのホワイトペーパーを参照してください。

以下を入手します。

Java JDK 1.8または同等のもの
最新のLiferay DXP .war または最新のサービスパックのバンドル
適切なElasticsearch環境
データベースおよび関連するJDBCドライバーの最新バージョン
Liferay Connected Services（LCS）アクティベーションキーと最新のLCSクライアント（LCSが必要な場合）
DXP 7.0または7.1アクティベーションキー

重要な構成上の注意点：

Liferay DXPでは、更新されたDocuments and Mediaモジュールを活用するために、Documents and Mediaの構成を別の.configファイルで構成する必要があります。詳細については、Introduction to Upgrading to Liferay DXPを参照してください。
ドキュメントを管理するためのAdvanced File Store方式を計画している管理者は、com.liferay.portal.store.file.system.configuration.AdvancedFileSystemStoreConfiguration.cfgというファイルを作成して/osgi/configフォルダに配置する必要があります。
同時に、portal-ext.propertiesファイルにdl.store.impl=com.liferay.portal.store.file.system.AdvancedFileSystemStoreを設定します。
詳細につきましては、Document Repository Configurationをご参照ください。
ステージングを利用する環境の場合：管理者は、アップグレードする前に変更を本番サイトに公開する必要があります。このステップを行わなかった場合、アップグレードされたシステムは最後の公開以降に発生したコンテンツの変更を認識しないため、全コンテンツの公開（または手動変更による公開）を実行する必要があります。

3.ドキュメントを参照する

オフィシャルドキュメントはこちらです:

4.バックアップを作成する

アップグレードはデータベースの変更を実行し、すべてのアップグレードが正常に完了するわけではありません。バックアップの作成は必須であるため、ロールバックが必要な場合に使用できます。Liferayポータルのどのバージョンを使用していても、バックアップをオンデマンドで起動できるようにすることで、環境のダウンタイムを短縮できます。

以下のバックアップを作成します（ただし、これらに限定されません）： portal-ext.properties 、データベース、ドキュメントライブラリファイルシステム（Sharepoint、Documentum、Nuxeoなど）リポジトリなどの構成ファイル。環境の復元を容易にするために、アプリケーションサーバーをバックアップすることもお勧めします。アップグレード後に検索インデックスが再構築されるため、検索インデックスを保存する必要はありません。

Liferay DXPでは、アップグレードツールは 、コアアップグレードではなく、モジュール のアップグレードプロセスの失敗した各ポイントでアップグレードを再開できることに注意してください。ただし、アップグレードプロセスに論理的な停止点がある場合（Liferay Portal 5.2からPortal 6.1 EE GA2へ、次にPortal 6.2、最後にDXP 7.0、7.1、7.2、または7.3）、管理者が既知の適切なポイントのバックアップを作成することを強くお勧めします。

5.レガシー環境の問題を解決する

従来のLiferayポータルバージョンに現在問題がないことを確認してください。従来のLiferayポータルバージョンで見つかった例外や問題（データ付き）は、アップグレードを試みる前に解決する必要があります。これは、ポータルの機能または使用を妨げる問題にまで及びます。

いくつかの問題を見つけて解決するために、検証プロセスを使用して起動時に実行し、データベース内で見つかった整合性の問題を修正できます。

検証プロセスは、 verify.frequency portal-ext.propertiesファイルを介して有効にできます。

 ＃データベースの整合性を検証する頻度を指定します。
 ＃
 ＃VerifyProcessの定数：
 ＃public static final int ALWAYS = -1;
 ＃public static final int NEVER = 0;
 ＃public static final int ONCE = 1;
 ＃
 verify.frequency = 1

新しいバージョンでは、アップグレード中にデータが失われないように、以前のバージョンのレガシープロパティと値の一部を活用する必要があります。
具体的な問題は次のとおりです。

ドキュメントライブラリ
最も重要なことは、Liferayポータル6.1以降、ドキュメントとメディアポートレットの実装に dl.store.implがdl.hook.implに置き換わることです。Liferay Portal 6.1では他のフックを使用できますが、以降のバージョンでは使用できなくなります。
Webコンテンツ
ストラクチャに重複した名前を付けることはできません。DXPにアップグレードする前にこの既知の問題を解決する方法については、 Structures With Duplicate Element Names Fail DDM Verification When Upgradingを参照してください。

6. Liferayのすべての公式アプリとカスタマイズされたアプリを更新する

Liferayポータルのレガシーバージョンで開発されたカスタマイズされたポートレットとアプリは、特定のポータルバージョンでのみ動作します。新しいバージョンでは、APIおよびクラスの変更が更新されます。これらの変更を確認し、Liferay DXP 7.0、7.1、7.2、または7.3のすべてのポートレット、プラグイン、またはテーマにコードの変更を組み込む必要があります。
これらのコードの変更は、Liferayプラットフォームの各バージョンのリリースノートのドキュメントに記載されています。Liferayの Java Doc は、非推奨のメソッドと変更を見つけるのにも非常に役立ちます。DTDファイルも参照できます。詳細については、 Breaking Changes を参照してください。

また、ユーザーは、Liferayポータル用のLiferay SDKの特定のバージョンに更新し、カスタマイズされたアプリを再コンパイルして、アップグレードが完了した直後に利用できるようにする必要があります。SDKは、ヘルプセンターからダウンロードできます。中断しないように、 Liferay Marketplace からアプリの最新バージョンを必ずダウンロードしてください。Liferayサポートは、Liferay内のこれらの更新された変更へのリソースの提供を支援できる場合があります。ただし、カスタマイズまたはカスタムコードの変更のレビューのサポートは制限されています。

7.アップグレードシミュレーションの実行

実際のアップグレードを実行する前に、管理者がシミュレートされたアップグレードを実行することをお勧めします。1つの方法は、運用データベースとデータディレクトリのコピーを使用して、最終アップグレードをシミュレートすることです。これにより、データベースに対してアップグレードプロセスがテストされ、古いデータ、破損したデータ、または無効なデータが検出されるために失敗することがあります。アップグレードシミュレーションの実行はデータをクリーンアップするために使用されるため、最終的な本番アップグレードは問題なく実行されます。
また、アップグレードシミュレーションでは、アップグレードツールをテストして、環境に対して機能することを確認します。ツールに問題がある場合は、最終的な本番アップグレードの途中で停止する前に、ヘルプセンターで問題を見つけて報告することをお勧めします。
アップグレードシミュレーションにより、チームはさまざまなコマンドを実行してアップグレードエクスペリエンスを完了し、アップグレード中に特定された問題を解決し、最後にアップグレードを正常に完了することができるという自信を与えます。

ドライランの価値を過小評価しないでください。データベースのアップグレードは完了するのに時間がかかり、アップグレードの実行時間を見積もることは不可能ではないにしても困難です。顧客データの量やカスタマイズなどの要因は、実行時間に影響します。
運用データベースとデータディレクトリのコピーに対してドライランアップグレードを実行し、最終的なアップグレードにかかる時間を特定します。

8.「アップグレードプロセス中にエラーが発生した場合はどうすればよいですか？」

プロセスのいずれかの時点でアップグレードが「スタック」しているように見える場合は、これが発生するステップに注意してください。
Liferayサポートチームに、プロセスの「スタック」ポイントに影響を与える可能性のある完全なアップグレードログ、スレッドダンプ、および関連するデータベースクエリを提供します。アップグレードプロセスに影響を与える可能性のあるカスタマイズやカスタムアプリに関する情報を提供します。
アップグレードがいずれかの例外で失敗した場合、レガシーポータル内で問題に対処し、プロセスを再起動します。これは、アップグレードが最新の失敗ポイントから再起動する準備が整っているためです (注: DXP 7.0または7.1に関するアップグレード処理で、バックアップの復元が必要な場合を除く)。これは、問題を診断または修正に十分な時間がある非本番環境に役立ちます。
インクリメンタルアップグレードは、アップグレードの問題のトラブルシューティングに役立つ場合があります（たとえば、6.1ポータルからDXP 7.1にアップグレードする場合、6.1から6.2、6.2から7.0、そして最後に7.0から7.1にアップグレードすると、問題の切り分けに役立ちます）

9.アップグレード後

アップグレード後の考慮事項については、このオフィシャルドュメントを参照してください。

Liferay DXPへのアップグレードのチェックリスト

目次