コードのアップグレードとカスタマイズ upgrading-code-and-customizations

アップグレードを計画するときは、実装の次の領域を調査して対処する必要があります。

概要 overview

アップグレードに進む前に、アプリケーションコードベースを AEM のターゲットバージョンに対して十分テストし、安定したものにしておく必要があります。 テストで得られた見解に基づいて、様々な方法でカスタムコードを最適化できます。 例えば、リポジトリの走査を回避するためのコードのリファクタリング、検索を最適化するカスタムインデックス作成、JCR での順序なしノードの使用などが含まれます。

コードベースのアップグレードや、新しい AEM バージョンに合わせたカスタマイズを行うオプションに加えて、6.5 では AEM 6.5 における後方互換性に記載された後方互換性機能を使用して、より効率的にカスタマイズを管理できます。

上記の説明および下の図に示したように、最初の手順でパターン検出を実行することで、アップグレードの全体的な複雑性を評価できます。 また、互換モードで実行するか、すべての新しい AEM 6.5 の機能を使用するようにカスタマイズを更新するかを決定することもできます。 詳しくは、AEM 6.5 における後方互換性のページを参照してください。

コードベースのアップグレード upgrade-code-base

バージョン管理で6.5 コードの専用ブランチを作成する create-a-dedicated-branch-for-6.5-code-in-version-control

AEM 実装に必要なすべてのコードおよび設定は、何らかの形式のバージョン管理を使用して管理する必要があります。 AEM のターゲットバージョンのコードベースに必要な変更を管理するために、バージョン管理に専用ブランチを作成する必要があります。 AEM のターゲットバージョンに対するコードベースの繰り返しテストとその後のバグ修正は、このブランチで管理されます。

AEM Uber Jar バージョンの更新 update-the-aem-uber-jar-version

AEM Uber Jar では、すべての AEM API を単一の依存関係として Maven プロジェクトの pom.xml に含めます。 個々の AEM API の依存関係を含めるのではなく、Uber Jar を単一の依存関係として含めることが常にベストプラクティスです。 コードベースをアップグレードするときは、AEM のターゲットバージョンを指すように Uber Jar のバージョンを変更します。 Uber Jar が存在する以前の AEM のバージョンで開発されたプロジェクトについては、個々の AEM API のすべての依存関係を削除します。 AEM のターゲットバージョン用の単一の Uber Jar を含めることで置き換えます。 Uber Jar の新しいバージョンに対してコードベースを再コンパイルします。 AEM のターゲットバージョンとの互換性を確保するために、廃止された API またはメソッドを更新します。

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.5.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

管理リソースリゾルバーの使用の段階的廃止 phase-out-use-of-administrative-resource-resolver

SlingRepository.loginAdministrative()およびResourceResolverFactory.getAdministrativeResourceResolver()を通じた管理セッションの使用は、AEM 6.0以前のコードベースで一般的でした。 これらのメソッドは、幅広いレベルのアクセスを与えすぎるため、セキュリティ上の理由から非推奨になりました。 Sling の今後のバージョンで、これらのメソッドは削除されます。 代わりにサービスユーザーを使用するようにコードをリファクタリングすることを強くお勧めします。 サービスユーザー、および管理セッションを段階的に廃止する方法について詳しくは、Adobe Experience Manager（AEM）のサービスユーザーを参照してください。

クエリと Oak インデックス queries-and-oak-indexes

コードベースでクエリを使用する場合は、コードベースのアップグレードの一環として詳細にテストする必要があります。 Jackrabbit 2（6.0 より前のバージョンの AEM）からアップグレードするお客様の場合、Oak ではコンテンツのインデックスが自動的に作成されず、カスタムインデックスを作成する必要があるので、このテストは特に重要です。 AEM 6.x バージョンからアップグレードすると、デフォルトの Oak インデックス定義が変更され、既存のクエリに影響を与える可能性があります。

クエリのパフォーマンスを分析および検査するには、次のツールを使用できます。

クラシック UI オーサリング classic-ui-authoring

クラシック UI オーサリングは、AEM 6.5 で引き続き利用できますが、廃止される予定です。 詳しくは、廃止される機能および削除された機能を参照してください。 アプリケーションがクラシック UI オーサー環境で実行されている場合は、AEM 6.5 にアップグレードして、引き続きクラシック UI を使用することをお勧めします。 タッチ UI への移行は、複数の開発サイクルを行う個別プロジェクトとして計画できます。 AEM 6.5 でクラシック UI を使用するには、複数の OSGi 設定をコードベースにコミットする必要があります。 この設定方法について詳しくは、クラシック UI へのアクセスの有効化を参照してください。

6.5 のリポジトリ構造との整合 align-repository-structure

アップグレードを容易にし、アップグレード中に設定が上書きされることを防ぐため、6.4 ではリポジトリの構造が見直され、コンテンツと設定が分離されました。

そのため、これまでのように /etc に存在しないように、いくつかの設定を移動する必要があります。 AEM 6.4 に更新する際に確認および対応が必要になる、リポジトリの再構築に関する一連の注意事項については、AEM 6.4 におけるリポジトリの再構築を参照してください。

AEM のカスタマイズ aem-customizations

AEM のソースバージョンでの AEM オーサリング環境に対するすべてのカスタマイズを特定する必要があります。 特定した後は、各カスタマイズをバージョン管理に保存するか、少なくともコンテンツパッケージの一部としてバックアップすることをお勧めします。 すべてのカスタマイズは、実稼動環境のアップグレード前に AEM のターゲットバージョンを実行する QA 環境またはステージング環境にデプロイして、検証する必要があります。

一般的なオーバーレイ overlays-in-general

AEM の標準機能を拡張する場合は、/libs の下のノードやファイルを /apps の下の追加ノードでオーバーレイすることが一般的です。 これらのオーバーレイは、バージョン管理で追跡し、AEM のターゲットバージョンに対してテストする必要があります。 ファイル（JS、JSP、HTL）をオーバーレイする場合は、AEM のターゲットバージョンでの回帰テストを容易にするために、拡張した機能に関するコメントを残しておくことをお勧めします。 一般的な情報については、オーバーレイを参照してください。 特定の AEM のオーバーレイの手順については、以下を参照してください。

カスタム検索フォームのアップグレード upgrading-custom-search-forms

カスタム検索ファセットを正しく機能させるには、アップグレード後に手動での調整が必要です。 詳しくは、カスタム検索フォームのアップグレードを参照してください。

Assets UI のカスタマイズ assets-ui-customizations

カスタマイズされた Assets デプロイメントを含むインスタンスを、アップグレード用に準備する必要があります。 これは、カスタマイズされたすべてのコンテンツに 6.4 の新しいノード構造との互換性を持たせるために必要なアクションです。

Assets UI のカスタマイズを準備するには、次の手順を実行します。

既存アセットのアセット ID の生成 generating-asset-ids-for-existing-assets

既存のアセットのアセット IDを生成するには、AEM インスタンスをアップグレードしてAEM 6.5を実行する際に、アセットをアップグレードします。 この手順は、Assets インサイト機能を有効にするために必要です。 詳しくは、埋め込みコードの追加を参照してください。

アセットをアップグレードするには、JMX コンソールで Associate Asset IDs パッケージを設定します。 リポジトリ内のアセットの数によっては、migrateAllAssets に長い時間がかかることがあります。 TarMK に 125,000 のアセットがある場合は、アドビの内部テストに約 1 時間かかります。

アセット全体のサブセットに対してアセット ID が必要な場合は、migrateAssetsAtPath API を使用します。

その他すべての目的には、migrateAllAssets() API を使用してください。

InDesign スクリプトのカスタマイズ indesign-script-customizations

Adobe では、カスタムスクリプトを /apps/settings/dam/indesign/scripts に配置することを推奨しています。 InDesign スクリプトのカスタマイズについて詳しくは、Adobe Experience Manager Assets と Adobe InDesign Server の統合を参照してください。

ContextHub 設定の復元 recovering-contexthub-configurations

ContextHub 設定は、アップグレードの影響を受けます。 既存の ContextHub 設定の復元方法については、ContextHub の設定を参照してください。

ワークフローのカスタマイズ workflow-customizations

必要な機能を追加したり、必要のない機能を削除したりするには、標準のワークフローを編集することが一般的な方法です。 カスタマイズ対象として一般的なワークフローは、DAM アセットの更新ワークフローです。 カスタム実装に必要なすべてのワークフローは、アップグレード中に上書きされる可能性があるので、バックアップしてバージョン管理に保存する必要があります。

編集可能なテンプレート editable-templates

AEM 6.2と6.3の間で、編集可能テンプレートの構造が変更されました。 6.2以前からアップグレードする場合で、サイトのコンテンツが編集可能なテンプレートを使用して構築されている場合は、​ レスポンシブノードクリーンアップツール ​を使用する必要があります。 このツールは、アップグレード​ 後 ​に実行して、コンテンツをクリーンアップすることを目的としています。 このツールは、オーサー層とパブリッシュ層の両方に対して実行します。

CUG 実装の変更 cug-implementation-changes

AEM の以前のバージョンのパフォーマンスおよびスケーラビリティの制限に対処するために、閉じられたユーザーグループの実装が大幅に変更されました。 CUG の以前のバージョンは 6.3 で廃止され、新しい実装はタッチ UI でのみサポートされます。

手順のテスト testing-procedure

アップグレードをテストするための包括的なテスト計画を準備する必要があります。 アップグレードされたコードベースおよびアプリケーションのテストは、最初に下位レベルの環境で実行する必要があります。 コードベースが安定するまで、検出されたすべてのバグを繰り返し修正します。より上位レベルの環境は、その後にアップグレードする必要があります。

アップグレード手順のテスト testing-the-upgrade-procedure

ここで説明されているアップグレード手順は、カスタマイズしたランブックに記載されているとおりに開発環境および QA 環境でテストする必要があります（アップグレードの計画を参照してください）。 アップグレード手順は、すべてのステップがアップグレードランブックに記載され、アップグレードプロセスが問題なく実行されるようになるまで繰り返す必要があります。

実装テスト領域 implementation-test-areas-

環境がアップグレードされ、アップグレードされたコードベースがデプロイされた後のテスト計画でカバーする必要がある AEM 実装の重要な領域を次に示します。

テスト計画の作成および結果 document-test-plan-and-results

前述の実装テスト領域をカバーするテスト計画を作成する必要があります。 多くの場合、テスト計画をオーサーのタスクリストとパブリッシュのタスクリストに分けることをお勧めします。 このテスト計画は、本番環境をアップグレードする前に、開発環境、QA 環境およびステージング環境で実行する必要があります。 ステージング環境および本番環境をアップグレードするときに比較できるように、下位レベルの環境でテスト結果およびパフォーマンス指標を取得する必要があります。