コードのアップグレードとカスタマイズ

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

コードベースのアップグレード
6.5 のリポジトリ構造への準拠
AEM のカスタマイズ
手順のテスト

概要

パターン検出 — アップグレード計画で説明されているとおりにパターン検出を実行し、詳細はこのページ. Target バージョンのAEMで使用できない API/バンドルに加えて対処する必要がある領域の詳細を含む、パターン検出レポートが表示されます。パターン検出レポートに、コード内の非互換性が示されます。存在しない場合は、デプロイメントは既に 6.5 と互換性があります。 6.5 の機能を使用するために新しい開発を行うこともできますが、互換性を維持するためだけに必要なわけではありません。互換性が報告されない場合は、互換モードで実行を選択し、新しい 6.5 機能または互換性に対する開発を遅らせることができます。または、アップグレード後に開発を行うことにし、手順 2 に進むこともできます。詳しくは、 AEM 6.5 の後方互換性を参照してください。
6.5 のコードベースの開発 - Target バージョンのコードベース専用のブランチまたはリポジトリを作成します。アップグレード前の互換性の情報を使用して、更新するコードの領域を計画します。
6.5 Uber jar でコンパイル - 6.5 uber jar を指すようにコードベース POM を更新し、それに対してコードをコンパイルします。
AEM カスタマイズの更新* - *AEM のカスタマイズまたは拡張を更新して、6.5 で機能することを検証し、6.5 コードベースに追加する必要があります。UI 検索フォーム、Assets のカスタマイズ、/mnt/overlay を使用するすべてのものを含みます。
6.5 環境へのデプロイ - AEM 6.5 のクリーンなインスタンス（オーサー + パブリッシュ）を開発環境と QA 環境で立ち上げる必要があります。更新したコードベースと、現在の実稼動環境にある代表的なコンテンツのサンプルをデプロイする必要があります。
QA 検証とバグ修正 - QA では、6.5 のオーサーインスタンスとパブリッシュインスタンスの両方でアプリケーションを検証する必要があります。検出されたすべてのバグを修正して、6.5 コードベースにコミットする必要があります。必要に応じて、すべてのバグが修正されるまで、Dev-Cycle を繰り返します。

アップグレードを続行する前に、AEMのターゲットバージョンに対して完全にテストされた、安定したアプリケーションコードベースが必要です。テストでの観察に基づいて、カスタムコードを最適化する方法が存在する場合があります。例えば、リポジトリの走査、検索を最適化するためのカスタムインデックス作成、JCR での順序なしノードの使用などを避けるために、コードのリファクタリングを含めることができます。

新しいAEMバージョンで動作するようにコードベースとカスタマイズをオプションでアップグレードする以外に、 6.5 は、このページ.

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

コードベースのアップグレード

バージョン管理での 6.5 コード用の専用ブランチの作成

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

AEM Uber Jar バージョンの更新

AEM Uber Jar では、すべての AEM API を単一の依存関係として Maven プロジェクトの pom.xml に含めます。AEM API の依存関係を個々に含めるのではなく、Uber Jar を単一の依存関係として含めることが常にベストプラクティスです。コードベースをアップグレードする場合、AEMのターゲットバージョンを指すように Uber Jar のバージョンを変更します。 Uber Jar が存在する前のバージョンのAEMでプロジェクトが開発された場合は、個々のAEM API の依存関係をすべて削除します。 AEMのターゲットバージョン用の Uber Jar を 1 つ含めて置き換えます。新しいバージョンの 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>

管理リソースリゾルバーの使用を停止します

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

クエリと Oak インデックス

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

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

クラシック UI オーサリング

クラシック UI のオーサリングは、AEM 6.5 で引き続き利用できますが、非推奨（廃止予定）となっています。詳細はこちらをご覧くださいここ. アプリケーションがクラシック UI オーサー環境で実行されている場合は、AEM 6.5 にアップグレードして、引き続きクラシック UI を使用することをお勧めします。その後、複数の開発サイクルにわたって完了するために、タッチ UI への移行を個別のプロジェクトとして計画できます。 AEM 6.5 でクラシック UI を使用するには、複数の OSGi 設定をコードベースにコミットする必要があります。設定の実行方法の詳細については、を参照してください。ここ.

6.5 のリポジトリ構造との整合

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

したがって、複数の設定を移動して、の配下にないようにする必要があります。 /etc 過去の事件と同じように AEM 6.4 への更新で確認および対応が必要な、リポジトリの再構築に関する懸念の完全なセットを確認するには、 AEM 6.4 におけるリポジトリの再構築.

AEM のカスタマイズ

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

一般的なオーバーレイ

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

カスタム検索フォームのアップグレード

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

Assets UI のカスタマイズ

メモ

この手順は、AEM 6.2 より前のバージョンからのアップグレードに対してのみ必要です。

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

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

アップグレードしようとしているインスタンスで、次の場所に移動してCRXDE Liteを開きます： https://server:port/crx/de/index.jsp
次のノードに移動します。
- /apps/dam/content
コンテンツノードの名前をに変更します。 content_backup ウィンドウの左側にあるエクスプローラペインを右クリックし、を選択します。 名前を変更.
ノードの名前を変更したら、以下に content という名前のノードを作成します。 /apps/dam 名前付き コンテンツ ノードタイプをに設定します。 sling:Folder.
のすべての子ノードを移動 content_backup 新しく作成されたコンテンツノードに移動するには、エクスプローラーペインで各子ノードを右クリックし、「」を選択します。移動.
を削除します。 content_backup ノード。
/apps/dam の下にある、正しいノードタイプ sling:Folder で更新されたノードは、理想的にはバージョン管理に保存してコードベースでデプロイするか、少なくともコンテンツパッケージとしてバックアップする必要があります。

既存アセットのアセット ID の生成

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

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

1487758945977

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

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

InDesign スクリプトのカスタマイズ

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

ContextHub 設定の復元

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

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

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

編集可能なテンプレート

メモ

この手順は、AEM 6.2 の編集可能テンプレートを使用した Sites のアップグレードでのみ必要です。

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

CUG 実装の変更

閉じられたユーザーグループの実装は、以前のバージョンのAEMでのパフォーマンスと拡張性の制限に対処するために、大幅に変更されました。 CUG の以前のバージョンは 6.3 で廃止され、新しい実装はタッチ UI でのみサポートされます。 6.2 以前からアップグレードする場合は、新しい CUG 実装に移行する手順を確認できますここ.

手順のテスト

アップグレードのテストに関しては、包括的なテスト計画を準備する必要があります。アップグレードされたコードベースとアプリケーションのテストは、まず低レベルの環境でおこなう必要があります。見つかったバグは、コードベースが安定するまで繰り返し修正する必要があります。その後、上位レベルの環境をアップグレードする必要があります。

アップグレード手順のテスト

ここで説明するアップグレード手順は、カスタマイズした実行マニュアルに記載されているように、開発環境および QA 環境でテストする必要があります ( アップグレードの計画) をクリックします。アップグレード手順は、すべての手順がアップグレード実行のマニュアルに記載され、アップグレードプロセスがスムーズになるまで繰り返す必要があります。

実装テスト領域

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

機能テスト領域	説明
公開済みサイト	パブリッシュ層でのAEM実装および関連するコードのテスト Dispatcher を使用する。ページ更新の条件とキャッシュの無効化。
オーサリング	AEMの実装と関連するコードをオーサー層でテストする。ページ、コンポーネントオーサリング、ダイアログを含める必要があります。
Experience Cloudソリューションとの統合	Analytics、DTM、Target などの製品との統合の検証。
サードパーティシステムとの統合	オーサー層とパブリッシュ層の両方で、サードパーティ統合を検証します。
認証、セキュリティ、権限	LDAP/SAML などの認証メカニズムを検証する必要があります。権限とグループは、オーサーとパブリッシュの両方でテストする必要があります層。
クエリ	カスタムインデックスとクエリは、クエリパフォーマンスと共にテストする必要があります。
UI のカスタマイズ	オーサー環境でのAEM UI の拡張またはカスタマイズ。
ワークフロー	カスタムおよび/または標準搭載のワークフローと機能。
パフォーマンステスト	ロードテストは、実際のシナリオをシミュレートするオーサー層とパブリッシュ層の両方で実行する必要があります。

テスト計画と結果の文書化

上記の実装テスト領域をカバーするテスト計画を作成する必要があります。多くの場合、テスト計画を作成者タスクリストと発行タスクリストで区切ると効果的です。このテスト計画は、実稼動環境をアップグレードする前に、開発環境、QA 環境、ステージ環境で実行する必要があります。ステージ環境と実稼動環境をアップグレードする際に比較をおこなうために、低レベルの環境でテスト結果とパフォーマンス指標を取り込む必要があります。

Business.Adobe.com リソース

Multichannel Communication Content Insights Style System Content As A Service Dynamic Forms Digital Rights Management