実装段階 implementation-phase

ジャーニーの実装段階では、コードとコンテンツを AEM as a Cloud Service に移行する準備を整えるためのツールについて確認します。

これまでの説明内容 story-so-far

ジャーニーのこれまでの部分では、AEM as a Cloud Service の変更点を理解し、デプロイメントが準備段階でクラウドに移行する準備ができているかどうかを判断しました。

この記事では、コードとコンテンツをクラウドに移動する準備ができていることを、アドビが提供するツールを使用して確認する方法について引き続き説明します。

目的 objective

このドキュメントの目的は次のとおりです。

Cloud Manager の使用 using-cloud-manager

始める前に、Cloud Manager に習熟している必要があります。Cloud Manager は AEM as a Cloud Service にコードをデプロイするための唯一のメカニズムであるためです。

Cloud Manager を使用すると、クラウド内の AEM を組織で自己管理できるようになります。このサービスには継続的インテグレーションと継続的デリバリー（CI／CD）フレームワークが備わっているので、IT チームや実装パートナーはパフォーマンスやセキュリティを妥協することなくカスタマイズや更新を迅速に配信できます。

Cloud Manager の使い方については、以下のリソースを参照してください。

アドビが提供するツールを使用してコンテンツとコードクラウドを準備する use-tools-to-make-code-and-content-cloud-ready

Cloud Service への移行の正確な手順は、購入したシステムと準拠するソフトウェア開発ライフサイクル手法によって異なります。

次の図は、AEM as a Cloud Service で使用するコードとコンテンツを変換するフェーズについて、主な段階を示したものです。

以下の章では、これを実現するために必要なツールの詳細を説明します。

コンテンツの移行 content-migration

現在の AEM インスタンスから Cloud Service インスタンスにコンテンツを移行するには、アドビのコンテンツ転送ツールを使用します。

このツールを使用すると、ソース AEM インスタンスから AEM Cloud Service インスタンスに転送するコンテンツのサブセットを指定できます。

コンテンツ移行は、異なるチーム間での計画、追跡、共同作業を必要とする複数の手順で構成されるプロセスです。

ツールの仕組みと推奨される使用方法について詳しくは、コンテンツ転送ツールのドキュメントを参照してください。

コードリファクタリング code-refactor

開発用にセットアップ set-up-for-development

Cloud Services と互換性を持たせるために、既存の機能のリファクタリングを開始します。

まず、基本的なツールの詳細を説明したドキュメントを参照し、コードのリファクタリングを開始します。

また、以下も行ってください。

発想の転換 a-change-in-mindset

AEM as a Cloud Service でコードを開発して実行するには、考え方を変える必要があります。インスタンスはいつ停止するかわからないので、コードには特に回復力が必要である点に留意してください。Cloud Service で実行するコードは、常にクラスター内で実行されていることを認識している必要があります。つまり、常に複数のインスタンスが実行されています。

AEM Maven プロジェクトをクラウドに対応させるためには、ある程度の変更が必要です。AEM as a Cloud Service では、 コンテンツ と コード を AEM にデプロイするには別個のパッケージに分離する必要があります。

詳しくは、 推奨されるパッケージ構造 のドキュメントを参照してください。

クラウド移行ツール cloud-migration-tools

アドビは、コードをリファクタリングするタスクの高速化に役立つツールをいくつか用意しています。これらのツールと解決する問題を理解することで、移行の複雑さと時間を削減できます。

ローカル開発環境を設定したら、AEM as a Cloud Service SDK に精通するために、 ドキュメント を参照してください。

コードの凍結のスケジュール設定 schedule-a-code-freeze

移行ジャーニーの一環として、アクティブな AEM 上で進行中のコード開発と、コードリファクタリングタスクを管理するには、AEM as a Cloud Service と互換性のある Maven プロジェクトの再構築が完了するまで、コードの凍結期間をスケジュール設定しておくことをお勧めします。

プロジェクトの再構築が完了したら、この新しい構造に基づいて新しいコード開発を再開できます。これにより、コードのデプロイメントおよびテスト中に発生する Cloud Manager パイプラインのエラーを減らすことができます。

コードのデプロイメントとテストのベストプラクティス best-practices

Cloud Manager パイプラインは、ステージング環境に対するテストの実行をサポートしています。

コード品質テストに関する以下のドキュメントのベストプラクティスに従います。

運用開始の準備 preparing-for-go-live

ソースシステムを準備するには、システムレベルおよび AEM 管理者レベルのタスクが必要です。開始するには、 リビジョンのクリーンアップ タスクと データストアのごみ収集 タスクのステータスを確認し、コンテンツリポジトリが適切に維持されている状態にあることを確認します。AEM バージョン 6.3を実行している場合は（コンテンツ転送ツールはバージョン 6.3 以降と互換性があるので）、オフライン圧縮を実行し、その後にデータストアのガベージコレクションを実行することをお勧めします。

データ整合性チェック は、すべての AEM バージョンにわたって推奨され、コンテンツリポジトリの移行作業を適切な状態に保ちます。

AZCopy のインストールと設定を行うには、システム管理者レベルのアクセス権が必要です

また、未使用のアセット、ページ、AEM プロジェクト、ユーザーおよびグループを確認して、移行時の時間を節約することをお勧めします。詳しくは、 コンテンツリポジトリの正常性 の節を参照してください。

コンテンツリポジトリの正常性 repository-health

実稼動クローン へのアクセスが設定されたら、リポジトリの正常性の確認に進みます。前の節で説明したように、移行を開始する前に、ソース上のリポジトリをクリーンアップしてコンパクト化することが目的です。この手順により、移行が開始された後の問題のトラブルシューティングに費やす時間を大幅に節約できる可能性があります。

データの収集 gathering-data

データの収集は、移行作業および関連タスクの計画に役立ちます。抽出と取り込みの時間は、データポイントを移行セットの特定のサイズに関連付けることができるので、特に便利です。そのため、次のデータポイントを推定して、プランを作成できます。

これらのデータポイントは、「KPI の設定」やその他の移行関連タスクにも役立ちます。

移行プラン migration-plan

収集したデータポイント（上記を参照）に基づいて、マクロなプロジェクトプランに統合できる移行プランを作成できます。この手順により、すべての主要な関係者が移行アクティビティを視覚化し、計画できるようになります。

次の表に、一般的な移行プランを示します。

上記の表からわかるように、特定の命名形式に従って移行の反復を識別すると便利です。例：ソース AEM 環境の場合は PRDCLONE、AEM as a Cloud Service 環境の場合は AUTHOR/PUBLISH、AEM as a Cloud Service インスタンスの場合は CSSTAGE-AUTHOR などです。

移行プランに影響を与える重要な詳細：

必要な抽出の合計数

必要な取り込みの合計数

移行トラッカー migration-tracker

移行トラッカーを使用して、初期実行と追加実行の両方の時間をメモすることができます。これらのデータポイントは、最終的な追加の前に、現実的なコンテンツ凍結要件を策定するのに役立ちます。

トラッカーは、次の操作にも役立ちます。

次の表に、機能移行トラッカーを示します。

コンテンツ移行の戦略とタイムライン content-strategyand-timeline

次の節では、コンテンツ移行戦略とタイムラインの策定に使用できる重要な手順と関連タスクを示します。

フィットメント fitment

移行の証明 proof-of-migration

次の手順 what-is-next

AEM インストールをクラウドに移行する準備ができているかどうかを評価する方法を把握し、その準備に必要なツールの使用方法を確認したら、実稼動段階に進みます。