移行する準備を整えるためのツールについて確認します。変更点を理解し、デプロイメントが準備段階でクラウドに移行する準備ができているかどうかを判断しました。この記事では、コードとコンテンツをクラウドに移動する準備ができていることを、アドビが提供するツールを使用して確認する方法について引き続き説明します。objectiveこのドキュメントの目的は次のとおりです。コンテンツ転送ツールについて詳しく説明します。コードを最新化するために使用する必要がある、コードリファクタリングツールについて説明します。習熟している必要があります。コードをデプロイするための唯一のメカニズムであるためです。組織で自己管理できるようになります。チームや実装パートナーはパフォーマンスやセキュリティを妥協することなくカスタマイズや更新を迅速に配信できます。使い方については、以下のリソースを参照してください。移行の正確な手順は、購入したシステムと準拠するソフトウェア開発ライフサイクル手法によって異なります。使用するコードとコンテンツを変換するフェーズについて、主な段階を示したものです。以下の章では、これを実現するために必要なツールの詳細を説明します。インスタンスにコンテンツを移行するには、アドビのコンテンツ転送ツールを使用します。インスタンスに転送するコンテンツのサブセットを指定できます。必要とする複数の手順で構成されるプロセスです。ツールの仕組みと推奨される使用方法について詳しくは、コンテンツ転送ツールのドキュメントを参照してください。互換性を持たせるために、既存の機能のリファクタリングを開始します。基本的なツールの詳細を説明したドキュメントを参照し、コードのリファクタリングを開始します。互換性を保つためにリファクタリングが必要な領域のリストを用意しておくことをお勧めします。する方法を確認してください。ダウンロードして、ローカル開発環境を設定する方法を確認してください。ついて詳しく確認してください。以下も行ってください。ローカルにインストールする方法を理解できます。設定方法を理解できます。コードを開発して実行するには、考え方を変える必要があります。インスタンスはいつ停止するかわからないので、コードには特に回復力が必要である点に留意してください。実行するコードは、常にクラスター内で実行されていることを認識している必要があります。常に複数のインスタンスが実行されています。プロジェクトをクラウドに対応させるためには、ある程度の変更が必要です。デプロイするには別個のパッケージに分離する必要があります。不変領域と見なされます。実行時に不変領域を変更しようとすると失敗します。リポジトリ内のその他すべて(例:/content、/conf、/var、/home、/etc、/oak:index、/system、/tmp)はすべて可変領域です。実行時に変更できます。ドキュメントを参照してください。cloud-migration-toolsアドビは、コードをリファクタリングするタスクの高速化に役立つツールをいくつか用意しています。これらのツールと解決する問題を理解することで、移行の複雑さと時間を削減できます。対応する形式に変換するツール。機能に変換するためのユーティリティスイート。プロジェクトの再構築が完了するまで、コードの凍結期間をスケジュール設定しておくことをお勧めします。プロジェクトの再構築が完了したら、この新しい構造に基づいて新しいコード開発を再開できます。パイプラインのエラーを減らすことができます。NOTEコンテンツ転送タスクとコードリファクタリングタスクは、順番に実行しなくてもかまいません。これらのタスクは互いに独立に実行することができます。環境でコンテンツが正常にレンダリングされるようにするには、正しいプロジェクト構造が必要です。パイプラインは、ステージング環境に対するテストの実行をサポートしています。コード品質テストに関する以下のドキュメントのベストプラクティスに従います。推奨カバレッジの概念を説明するドキュメント。実行されるカスタムコード品質ルールを説明するドキュメント。管理者レベルのタスクが必要です。タスクのステータスを確認し、コンテンツリポジトリが適切に維持されている状態にあることを確認します。以降と互換性があるので)、オフライン圧縮を実行し、その後にデータストアのガベージコレクションを実行することをお勧めします。バージョンにわたって推奨され、コンテンツリポジトリの移行作業を適切な状態に保ちます。プロジェクト、ユーザーおよびグループを確認して、移行時の時間を節約することをお勧めします。節を参照してください。アクセスが設定されたら、リポジトリの正常性の確認に進みます。前の節で説明したように、移行を開始する前に、ソース上のリポジトリをクリーンアップしてコンパクト化することが目的です。この手順により、移行が開始された後の問題のトラブルシューティングに費やす時間を大幅に節約できる可能性があります。重要な留意点ユーザー、グループ、権限メンバーシップに関するユーザー、グループ、複雑さの量を理解する必要があります。移行前に、クリーンアップできる未使用のユーザーやグループがソース内にないか探します。移行時に発生する可能性のある問題を回避します。移行を開始する前に、正しくないコンテンツを検索して除去することをお勧めします。オリジナルのレンディションがない、またはワークフロー処理でスタックしている、アセットやページを探します。節では、収集したデータを推定して移行プランを作成する方法について詳しく説明します。データの収集は、移行作業および関連タスクの計画に役立ちます。抽出と取り込みの時間は、データポイントを移行セットの特定のサイズに関連付けることができるので、特に便利です。そのため、次のデータポイントを推定して、プランを作成できます。設定」やその他の移行関連タスクにも役立ちます。migration-plan収集したデータポイント(上記を参照)に基づいて、マクロなプロジェクトプランに統合できる移行プランを作成できます。この手順により、すべての主要な関係者が移行アクティビティを視覚化し、計画できるようになります。次の表に、一般的な移行プランを示します。(日数)追加の詳細/作業項目PRDCLONE-AUTHOR-INITIAL-USRMAP-CSSTAGE-AUTHORPRDCLONE-PUBLISH-TOPUP-CSSTAGE-AUTHOR上記の表からわかるように、特定の命名形式に従って移行の反復を識別すると便利です。つの並列抽出と見なされます。特定の期間でのリポジトリの増加に基づく追加抽出の数。環境に取り込めるので、この項目をプランに取り込むことが重要です。パブリッシュにコンテンツを移行することが推奨されます。migration-tracker移行トラッカーを使用して、初期実行と追加実行の両方の時間をメモすることができます。これらのデータポイントは、最終的な追加の前に、現実的なコンテンツ凍結要件を策定するのに役立ちます。トラッカーは、次の操作にも役立ちます。プランまたは実稼動タイムラインの調整が必要なプランナーからの逸脱を識別するすべての必要な通信で使用できる現実的なステータスを提供する初期または将来の追加移行のプラン次の表に、機能移行トラッカーを示します。content-strategyand-timeline次の節では、コンテンツ移行戦略とタイムラインの策定に使用できる重要な手順と関連タスクを示します。fitmentリビジョンのクリーンアップ、データストアのガベージコレクション、データの整合性チェックを実行します。