現在表示中:

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

概要

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

コードベースをアップグレードする手順の概要
コードベースをアップグレードする手順の概要
  1. アップグレード前の互換性チェック - detectUsageOfUnavailableAPI タスクにより、AEM のターゲットバージョンで使用できない API /バンドルが示されます。
  2. 6.3 のコードベースの開発 - ターゲットバージョンのコードベース専用のブランチまたはリポジトリを作成します。アップグレード前の互換性の情報を使用して、更新するコードの領域を計画します。
  3. 6.3 Uber jar でのコンパイル - 6.3 uber jar を指すようにコードベース POM を更新し、これに対してコードをコンパイルします。
  4. AEM カスタマイズの更新AEM のカスタマイズまたは拡張を更新して 6.3 で機能することを検証し、6.3 コードベースに追加する必要があります。UI 検索フォーム、カスタマイズされているアセット、/mnt/overlay を使用するすべてのものを含めます。
  5. 6.3 環境へのデプロイ - AEM 6.3 のクリーンなインスタンス(オーサー + パブリッシュ)を開発/ QA 環境で使用できるようにする必要があります。更新されたコードベースおよび(現在の実稼動環境の)コンテンツの代表的なサンプルをデプロイする必要があります。
  6. QA 検証およびバグ修正 - QA では、6.3 のオーサーインスタンスとパブリッシュインスタンスの両方でアプリケーションを検証する必要があります。検出されたすべてのバグを修正して、6.3 コードベースにコミットする必要があります。すべてのバグが修正されるまで、必要に応じて開発サイクルを繰り返します。

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

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

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

アップグレード前の互換性チェック

アップグレード前の互換性チェックでは、6.3 と互換性がなくアップグレード後に動作しない可能性がある使用中の API を検出することによって、既存の AEM インスタンスがアップグレード可能かどうかをチェックできます。これにより、次のバージョンへの移行に必要となる可能性がある開発作業を評価できます。

この機能を使用するには、アップグレード元のインスタンスに最新バージョンの pre-upgrade-tasks-content コンテンツパッケージをインストールする必要があります。

パッケージ共有からパッケージをダウンロードするリンクは、アップグレード前のメンテナンスタスクにあります。

このチェックを呼び出すには、JMX コンソールの一部である PreUpgradeTasksMBean MBean を使用します。

1488281039321

アップグレード前の互換性チェックのために呼び出すメソッドは、次に示すようにチェック対象の AEM のターゲットバージョンがパラメーターとして渡された detectUsageOfUnavailableAPI です。

1487883026487

互換性のない API を使用していて、アップグレード後に動作しないインポート済みパッケージおよびバンドルのリストが、次のように応答で返されます。この結果は、upgrade.log ファイルにも追加されます。互換性のない各 API は、6.3 コードベースの一部として対処する必要があります。

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 を含めることで置き換える必要があります。さらに、Uber Jar の新しいバージョンに対してコードベースを再コンパイルする必要があります。廃止された API またはメソッドは、AEM のターゲットバージョンとの互換性を確保するためにアップデートする必要があります。

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

管理リソースリゾルバの使用の段階的廃止

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

クエリと Oak インデックス

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

クエリパフォーマンスを分析および調査するためのツールが複数用意されています。

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

クラシック UI オーサリングは AEM 6.3 でも使用できますが、今後のバージョンで廃止される予定です。詳しくは、こちらを参照してください。アプリケーションが現在クラシック UI オーサー環境で実行されている場合は、AEM 6.3 にアップグレードして、クラシック UI を引き続き使用することをお勧めします。タッチ UI への移行は、複数の開発サイクルをおこなう個別プロジェクトとして計画できます。AEM 6.3 でクラシック UI を使用するには、複数の OSGi 設定をコードベースにコミットする必要があります。この設定方法について詳しくは、こちらを参照してください。

AEM のカスタマイズ

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

一般的なオーバーレイ

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

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

アセット UI のカスタマイズ

注意:

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

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

アセット UI のカスタマイズを準備するには、以下の手順を実行します。

  1. アップグレードする必要があるインスタンス上で、http://server:port/crx/de/index.jsp に移動して CRXDE Lite を開きます。

  2. 次のノードに移動します。

    • /apps/dam/content
  3. content ノードの名前を content_backup に変更します。ウィンドウ左側のエクスプローラーパネルを右クリックし、「名前を変更」を選択することによって、変更できます。

  4. ノードの名前を変更したら、content という名前の新しいノードを /apps/dam の下に作成し、ノードタイプを sling:Folder に設定します。

  5. content_backup のすべての子ノードを、新しく作成された content ノードに移動します。そのためには、エクスプローラーパネルで個々の子ノードを右クリックし、「移動」を選択します。

  6. content_backup ノードを削除します。

  7. /apps/dam の下の(正しいノードタイプ sling:Folder を持つ)更新されたノードは、バージョン管理に保存してコードベースにデプロイするか、少なくともコンテンツパッケージとしてバックアップする必要があります。

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

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

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

1487758945977

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

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

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

InDesign スクリプトのカスタマイズに対する変更は、アップグレードの際に維持されません。AEM および InDesign 統合をカスタマイズするために、/etc/dam/indesign/scripts の下のファイルに加えられた変更を追跡する必要があります。InDesign スクリプトのカスタマイズについて詳しくは、こちらを参照してください。

ContextHub 設定の復元

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

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

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

編集可能テンプレート

注意:

この手順は、AEM 6.2 から編集可能テンプレートを使用して Sites をアップグレードする場合にのみ必要になります。

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

CUG 実装の変更

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

手順のテスト

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

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

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

テスト領域の実装

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

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

テスト計画の作成および結果

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

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー