アップグレードの計画 planning-your-upgrade

AEM Project の概要 aem-project-overview

AEMは、多くの場合、数百万人のユーザーに役立つ可能性のある、影響の大きいデプロイメントで使用されます。 ほとんどの場合、インスタンスにデプロイされるカスタムアプリケーションがあり、その結果、複雑さが増します。 このようなデプロイメントをアップグレードする際の作業は、体系的に処理する必要があります。

このガイドは、アップグレードを計画する際に明確な目標、フェーズ、成果物を確立する際に役立ちます。 全体的なプロジェクトの実行とガイドラインに焦点を当てます。 実際のアップグレード手順の概要は示されますが、必要に応じて利用可能な技術リソースを指します。 ドキュメントで参照されている利用可能な技術リソースと組み合わせて使用する必要があります。

AEMアップグレードプロセスでは、計画、分析および実行フェーズを慎重に処理し、各フェーズで定義された主な成果物を使用する必要があります。

AEM バージョン 6.0 から 6.4 までのバージョンでは、直接アップグレードすることが可能です。5.6.x 以下のバージョンを実行しているお客様は、まずバージョン 6.0 以上にアップグレードする必要があります（6.0（SP3）を推奨）。また、6.3 以降、Segment Node Store では新しい OAK Segment Tar 形式が使用され、6.0、6.1 および 6.2 でも、この新しい形式へのリポジトリの移行は必須です。

アップグレードの範囲と要件 upgrade-scope-requirements

一般的なAEM Upgrade プロジェクトで影響を受ける領域のリストを次に示します。

サポートされているオペレーティングシステム、Java ランタイム、httpd、Dispatcher のバージョンを実行していることを確認することが重要です。 詳しくは、 AEM 6.4 技術要件ページ. これらのコンポーネントのアップグレードは、プロジェクト計画で考慮する必要があり、AEMをアップグレードする前に実行する必要があります。

プロジェクトフェーズ project-phases

AEMのアップグレードの計画と実行には、多くの作業が必要になります。 このプロセスに伴う様々な取り組みを明確にするため、計画と実行の演習を別々のフェーズに分けました。 以下の節では、各フェーズで成果物が生成され、多くの場合、プロジェクトの将来のフェーズで活用されます。

作成者トレーニングの計画 planning-for-author-training

新しいリリースでは、UI とユーザーワークフローに潜在的な変更が加えられる可能性があります。 さらに、新しいリリースでは、ビジネスが活用すると役立つ新機能が導入されます。 導入された機能の変更を確認し、ユーザーを効果的に活用するためのトレーニング計画を作成することをお勧めします。

AEM 6.4 の新機能は、 adobe.com のAEMセクション. 組織で一般的に使用される UI や製品機能に対する変更を必ずメモしておきます。 新機能を確認する際は、組織にとって価値のあるものをメモしておきます。 AEM 6.4 での変更点を確認したら、作成者向けのトレーニング計画を作成します。 これには、helpx 機能のビデオや、 Adobeデジタルラーニングサービス.

テスト計画の作成 creating-a-test-plan

各お客様のAEMの実装は一意で、ビジネス要件に合わせてカスタマイズされています。 その結果、テスト計画に含めることができるように、システムに対して行われたすべてのカスタマイズを特定することが重要です。 このテスト計画は、アップグレードされたインスタンスで実行する QA プロセスを強化します。

正確な実稼動環境を複製し、アップグレード後にテストを実行して、すべてのアプリケーションとカスタムコードが引き続き必要に応じて実行されることを確認する必要があります。 すべてのカスタマイズを取り消し、パフォーマンス、負荷、セキュリティのテストを実行する必要があります。 テスト計画を整理する際は、標準搭載の UI や日々の操作で利用されるワークフローに加えて、システムに対しておこなわれたすべてのカスタマイズを必ずカバーしてください。 これには、カスタム OSGi サービスおよびサーブレット、Adobe Marketing Cloudへの統合、AEMコネクタを介したサードパーティとの統合、カスタムサードパーティの統合、カスタムコンポーネントとテンプレート、AEMのカスタム UI オーバーレイ、カスタムワークフローが含まれます。 AEM 6 より前のバージョンから移行するお客様の場合は、カスタムクエリのインデックスを作成する必要がある場合があるので、カスタムクエリを分析する必要があります。 既にAEM 6.x バージョンを使用しているお客様の場合、アップグレード後もインデックスが引き続き効果的に動作することを確認するために、これらのクエリをテストする必要があります。

必要なアーキテクチャとインフラストラクチャの変更の決定 determining-architectural-and-infrastructure-changes-needed

アップグレード時に、オペレーティングシステムや JVM など、技術スタック内の他のコンポーネントをアップグレードする必要が生じる場合があります。 また、リポジトリ構成の変更により、追加のハードウェアが必要になる場合があります。 これは通常、6.x より前のインスタンスから移行するお客様に対してのみ提供されますが、考慮する必要があります。 最後に、監視、保守、バックアップ、災害復旧のプロセスを含む、運用上の慣行に必要な変更が存在する場合があります。

AEM 6.4 の技術要件を確認し、現在のハードウェアおよびソフトウェアで十分であることを確認します。 運用プロセスに関して考えられる変更については、以下のドキュメントを参照してください。

監視およびメンテナンス：

操作ダッシュボード

Assets の監視のベストプラクティス

JMX コンソールを使用したサーバーリソースの監視

リビジョンクリーンアップ

バックアップ／復元および障害回復：

バックアップと復元

パフォーマンスとスケーラビリティ

TarMK コールドスタンバイによる AEM の実行方法

コンテンツの再構築に関する考慮事項 content-restructuring-considerations

AEM 6.4 では、よりシームレスにアップグレードをおこなう際に役立つ、リポジトリ構造の変更が導入されました。 この変更の一環として、コンテンツが /etc フォルダーから /libs、/apps、/content などのフォルダーに移動されます。Adobe の所有コンテンツとお客様の所有コンテンツが分けて管理されるようになるので、リリース中にコンテンツを上書きしてしまう危険が低減します。リポジトリの再構築は、6.4 へのアップグレード時にコードを変更する必要がないようにおこなわれました。ただし、詳細は AEM 6.4 におけるリポジトリの再構築 アップグレードの計画中に

アップグレードの複雑性の評価 assessing-upgrade-complexity

お客様がAEM環境に適用するカスタマイズの量と特性は様々なので、アップグレードで予想される全体的な作業レベルを決定するには、事前に少し時間を割くことが重要です。

アップグレードの複雑さを評価する方法は 2 つあります。予備段階では、新しく導入されたパターン検出を使用するだけで済みます。パターン検出は、AEM 6.1、6.2 および 6.3 インスタンスで実行できます。 パターン検出は、報告されたパターンを使用して、アップグレードの全体的な複雑さを評価する最も簡単な方法です。 パターン検出レポートには、カスタムコードベースで使用中の、使用できない API を識別するためのパターンが含まれています（これは、6.3 のアップグレード前の互換性チェックを使用しておこなわれました）。

最初の評価の後、より包括的な次のステップは、テストインスタンスのアップグレードを実行し、いくつかの基本的なスモークテストを実行することです。 Adobeには、もいくつか用意されています。 また、アップグレード先のバージョンだけでなくソースバージョンとターゲットバージョンの間のバージョンについても、廃止および削除された機能のリストを確認する必要があります。例えば、AEM 6.2 から 6.4 にアップグレードする場合、AEM 6.4 以外に AEM 6.3 の廃止および削除された機能を確認することが重要です。

6.4 で導入されたパターン検出は、ほとんどの場合、アップグレード中に予想される事項を、かなり正確に予測できるものにします。 ただし、互換性のない変更点が存在する、より複雑なカスタマイズやデプロイメントの場合は、インプレースアップグレードの実行の手順に従い開発インスタンスを AEM 6.4 にアップグレードできます。完了したら、この環境で高レベルのスモークテストを実行します。 この演習の目的は、テストケースのインベントリを完全に完了し、欠陥の正式なインベントリを作成するのではなく、6.4 互換性のためにコードをアップグレードするために必要な作業量を大まかに見積もることです。 を パターン検出 また、前の節で決定したアーキテクチャの変更については、プロジェクト管理チームに大まかな見積もりを提供し、アップグレードを計画できます。

アップグレードおよびロールバックランブックの構築 building-the-upgrade-and-rollback-runbook

AdobeではAEMインスタンスのアップグレードプロセスを説明していますが、各顧客のネットワークレイアウト、デプロイメントアーキテクチャおよびカスタマイズには、このアプローチの微調整とカスタマイズが必要です。 このため、提供されたすべてのドキュメントを確認し、それを使用して、お使いの環境で従う特定のアップグレードおよびロールバック手順の概要を示すプロジェクト固有のランブックに通知することをお勧めします。 CRX2 からアップグレードする場合は、CRX2 から Oak に移行する際にコンテンツ移行に要する時間を必ず評価してください。 大規模なリポジトリの場合は、相当量が存在する可能性があります。

アップグレードおよびロールバック手順については、 アップグレード手順 アップグレードを適用する手順については、 インプレースアップグレード. これらの手順を確認し、システムアーキテクチャ、カスタマイズ、およびダウンタイムの許容値に従って考慮し、アップグレード中に実行する適切な切り替えおよびロールバック手順を決定する必要があります。 カスタマイズした Runbook の作成時に、アーキテクチャやサーバーサイズの変更を含める必要があります。 これは最初の下書きとして扱う必要があることに注意してください。 チームが QA および開発サイクルを完了し、ステージング環境にアップグレードをデプロイすると、追加の手順が必要になる場合があります。 このドキュメントには、オペレーションスタッフに渡された場合に、内の情報から完全にアップグレードを完了できるような十分な情報を含めることが理想的です。

プロジェクト計画の作成 developing-a-project-plan

前の演習の出力を使用して、テストまたは開発の取り組み、トレーニング、実際のアップグレードの実行に必要なタイムラインをカバーするプロジェクト計画を作成できます。

包括的なプロジェクト計画には、以下が含まれています。

開発および QA の実行 performing-development-and-qa

手続きをしました コードのアップグレードとカスタマイズ AEM 6.4 との互換性を保つには、この反復プロセスが実行されるので、必要に応じてランブックに変更を加える必要があります。 ほとんどの場合において、開発作業を行うことなくアップグレード後すぐにカスタマイズの後方互換性が確保できるようにする方法について詳しくは、AEM 6.4 における後方互換性も参照してください。

通常、開発とテストのプロセスは反復的なプロセスです。 カスタマイズが原因で、アップグレード中に加えられた変更により、製品のセクション全体が使用できなくなる場合があります。 開発者が問題の根本原因に対処し、テストチームがこれらの機能をテストできるようになると、問題がさらに発生する可能性があります。 アップグレードプロセスの調整が必要な問題が見つかったので、必ずカスタムアップグレード Runbook に追加してください。 テストと修正を数回繰り返した後、コードベースは完全に検証され、ステージング環境にデプロイする準備が整う必要があります。

最終テスト final-testing

コードベースが組織の QA チームによって認定された後、最終的なテストラウンドをお勧めします。 この一連のテストでは、ステージング環境での Runbook の検証に続いて、ユーザーの受け入れ、パフォーマンス、セキュリティのテストが行われます。

実稼動環境に対してランブックの手順を検証できるのは、この手順だけなので、この手順は重要です。 環境がアップグレードされたら、エンドユーザーがログインして、日々のアクティビティでシステムを使用する際におこなうアクティビティを実行できるようにすることが重要です。 ユーザーが、以前は検討されていなかったシステムの一部を活用することは珍しくありません。 運用開始前にこれらの領域で問題を見つけて修正すると、コストのかかる生産停止を防ぐのに役立ちます。 新しいバージョンのAEMには、基盤となるプラットフォームに対する大幅な変更が含まれているので、初めて起動する場合と同様に、システムでパフォーマンス、負荷、セキュリティのテストを実行することも重要です。

アップグレードの実行 performing-the-upgrade

すべての関係者から最終的な承認が得られたら、定義された Runbook 手順に対して実行する時間です。 でアップグレードおよびロールバックの手順を実行しました。 アップグレード手順 と、 インプレースアップグレード を参照点として使用します。

環境の検証のためのアップグレード手順をいくつか示しました。 これには、アップグレードログのスキャンや、すべての OSGi バンドルが正しく開始されたことの確認などの基本的なチェックが含まれますが、ビジネスプロセスに基づいて独自のテストケースで検証することもお勧めします。 また、AEM Online Revision Cleanup のスケジュールや関連するルーチンを確認して、会社の静かな時間帯に実行されるようにすることをお勧めします。 これらのルーチンは、AEMの長期的なパフォーマンスに不可欠です。