実稼動サイトの移行 production-migration
このワークフローを使用して、合意されたページのリストを、web サイトを配信するAdobe Experience Manager サービスであるEdge Delivery Servicesに移動します。 各テンプレートのサンプルページから始め、そのコンテンツとデザインマップを新しいサイトに配置する方法を決め、作成者が使用するエディターでサンプルが作業した後にのみ、さらにページを読み込みます。 ブロック、デフォルトコンテンツ、プレビューなどの用語が初めての場合は、 サイトの構築および更新方法および コンテンツ構造の形成を参照してください。
少数のデモンストレーションページまたは最初の評価を行う場合は、小さい デモと体験版のワークフローを使用します。 リリース前に実稼動サイトで必要なチェックは不要です。
範囲と宛先の同意 scope
移行のリーダーとアーキテクトは、スコープと宛先を一致させます。 ソースを読み取り、ターゲットリポジトリを変更し、コンテンツとアセットを宛先に書き込むには、権限が必要です。 誰が結果を承認し、誰がリリースを承認するかを同意します。 一部のページでログインが必要な場合は、専用の読み取り専用アカウントで保護されたサイト認証を設定します。 ソースが自動訪問者をブロックする場合は、カタログ化する前に管理者にアクセス権を割り当てます。 ボット保護を含むSource サイト を参照してください。
レコード：
ページの読み込みでは、各ページのコンテンツとデザインをコピーします。 統合機能とCMS機能は、検索、フォーム処理、パーソナライゼーションルール、コンテンツ継承など、ソースのサーバーで実行されるため、インポートでは各ページの出力のみがコピーされます。 ビヘイビアーにリストし、新しいサイトでの動作を決定します。 制限を参照してください。
コンソールワークスペースは、一度に1つのサイトで動作します。 複数のサイトを持つプログラムで、注文に同意し、各サイトの作業をプッシュしてアップロードしてから、サイトを切り替えで次のサイトを開きます。
Experience Managerで実行するサイトのリニューアル relaunch-aem-site
チームが再起動を決定したら、ワークフローは他のソースと同じです。 これらのポイントは、Experience Manager ソースに固有です。
- 他のサイト： エージェントはソース サイトのページを読み取り、ソースを変更しません。 新しいサイトのGit リポジトリと、選択したコンテンツの宛先にのみ書き込むため、組織の他のExperience Manager サイトは現在の状態で動作し続け、ドメインを リリース で切り替えるまでソースサイトも同様に動作します。 Experience Manager オーサリングでは、アップロードによってサイトのAssets フォルダーの
/content/{site-name}の下にページが書き込まれ、そのパスにあるページが既に置き換えられるので、オーサーインスタンスの管理者に同意します。 「 コンテンツをアップロード 」を参照してください。 - エージェントによるソースの読み取り方法： エージェントは、ソースのコンポーネント、テンプレート、リポジトリではなく、各ページをブラウザーがレンダリングする際に読み取ります。 したがって、コンポーネント、エクスペリエンスフラグメント、コンテンツの継承は引き継がれません。各ページに出力が表示されます。 新しいサイトで維持する共有コンテンツを決めます。 残りのプロジェクト作業を参照してください。
- コンテンツの保存場所： コンテンツの保存先は、任意のソースと同様に選択できます。 コンテンツの保存場所と作成者による編集方法を参照してください。 Experience Manager オーサリングにはExperience Manager as a Cloud Service オーサーインスタンスが必要なので、他の場所で実行されるオーサーインスタンスを宛先にすることはできません。
- リポジトリ： コードがCloud Managerを介して接続されたリポジトリ内にある場合、コンソールも一緒に動作します。 別のGit ホストを使用を参照してください。
- チームの決定：言語、マーケット間の継承、承認ワークフローは、チームの決定です。 「読み込み」を選択すると、これらの構造ではなく、ソースパスにあるページが表示されます。 カタログ化する前に、他のスコープ決定と記録します。
Prepare and Catalog prepare
- コンテンツがExperience Manager オーサリングに移行する場合は、共有コンソールの設定またはExperience Manager オーサリングの設定に従います。 既存のプロジェクトの設定を再作成するのではなく、再利用します。
- 承認済みサイトのカタログ化をエージェントに依頼します：
Scope site https://www.example.com。 サイトカタログ は、ページを検出し、それらをテンプレート（レイアウトを共有するページ）とブロックのバリエーションにグループ化します。 - 計画ビューでカタログを確認します。 テンプレートとブロックのグループ化を修正し、失敗したURLを調査します。
- 検出されたURLと合意したページリストを比較します。 見つからないページを追加し、失敗したURL、スキップしたURL、重複したURL、除外されたURLを明示的に決定します。
- テンプレートと重要なバリエーションごとにサンプルページを選択します。 長いコンテンツや通常とは異なる画像、ロケール、ページなどについて、膨大なインタラクションでカバーします。
カタログ化はソースを読み込み、何もインポートしません。 ステータスが complete の実行は、失敗したページが残っている可能性があります。結果とステータス を参照してください。 先に進む前に、スコープ内のすべてのURLにテンプレートまたは承認済みの除外を指定します。
エージェントの大規模な移行方法 migration-at-scale
AI モデルを通じて各ページを送信するわけではありません。 各ページを個別に解釈しても、数千ページには拡張できません。また、同じページを毎回少しずつ異なる方法で処理することもできます。 代わりに、AI モデルはテンプレートごとに1つのサンプルページでマッピングを処理し、エージェントはそのマッピングをテンプレートの他のページで実行されるコードに変換します。
- ページをテンプレートにグループ化します。 サイトカタログ は、ソースサイトのページを、レイアウトを共有するページであるテンプレートにグループ化します。 カタログなしでページを移行する場合、名前を付けた各ページごとに独自のテンプレートが開始されます。
- サンプルページを移行します。 テンプレートごとに、エージェントはまず、テンプレートの典型的なレイアウトと、理想的にはほとんどのブロックとバリエーションを示す実際のページを1つ移行します。 サイトカタログでは、各テンプレートに対して1つが提案されます。 テンプレートの別のページにブロックが多く表示される場合は、代わりにそのページを選択します。読み込まれたページが必要な場合にのみ、サンプルページに欠けているブロックが後で追加されます。 AI モデルは、サンプルページのコンテンツをデフォルトのコンテンツとブロックにマッピングし、必要なブロックを作成したり、既存のブロックを再利用したりします。
- インポートスクリプトを生成します。 担当者は、テンプレートのインポートスクリプトを作成します。一部のパーサーは、ソースHTMLから各ブロックのコンテンツを抽出し、別のトランスフォーマーはページ全体をクリーンアップします。 スクリプトは、プロジェクトの
tools/importer/フォルダーにあるJavaScript ファイルで、Gitでバージョン管理され、残りのコードと共に作成されます。 - ページではなくパターンを調整します。 修正を求めると、エージェントは、1 ページの出力を編集する代わりに、結果を生成したブロックまたはインポートスクリプトを変更します。 その後、修正はテンプレートのすべてのページに適用され、後のテンプレートでは既に存在するブロックが再利用されます。
- 残りのページを一括で読み込みます。 一括読み込みでは、AI モデルが各ページを解釈することなく、テンプレートの他のページで読み込みスクリプトが実行されます。 次に、読み込んだページとソースページを比較し、異なるページの読み込みスクリプトを修正して、それらのページを再び読み込みます。
すべてのテンプレートを読み込む前に、各テンプレートの数ページを検証します。 バッチでのインポート を参照してください。
コンテンツ構造の変更（コンテンツがブロックになる、ページがセクションに分割される場合など）も同様です。読み込みスクリプトを変更します。 これはコードであり、レビューされ、残りの部分と同様に結合され、次の読み込みではテンプレートのすべてのページに適用されます。 1つの読み込まれたページへの編集はローカルのままになり、テンプレートを再び読み込むと上書きされます。
ページを別のテンプレートに移動したり、あるブロックを別のブロックのバリエーションにしたりするなど、テンプレートやブロック自体を変更するには、 プランニングビューを使用するか、チャットで質問します。 エージェントは、次にブロックを生成したりページを読み込んだりするときにこれらの変更を実行しますが、既に読み込んだページは変更されません。 デザインを統合するには、 サイトのスタイル変更を参照してください。 ブロックコードを統合するには、結果を変更せずにリファクタリング を参照してください。
body要素にクラスを追加するtemplate ページメタデータではなく、プロジェクトのコードがこれらのページに異なるスタイルを適用できるようにします。 2つを調整するには、テンプレートのすべてのページがインポート時にメタデータを取得するように、インポートスクリプトでメタデータを設定するようにエージェントに依頼します。例えば、「記事テンプレートの場合、インポートスクリプトでページメタデータ templateをarticleに設定し、記事ページのメイン列を狭くします。」サンプルページの検証 representatives
移行リード、デザイナー、作成者は、最初のテンプレートを一緒に設定します。 最初に、いくつかのページから始めます。 次に例を示します。
次の製品ページのみを移行します：
https://www.example.com/products/tents、https://www.example.com/products/backpacks、およびhttps://www.example.com/products/boots。 コンテンツを/productsの下のドキュメントベースのコンテンツとして保存します。 承認済みのテキスト、リンク、メタデータ、画像の意味を維持。 プロジェクトのブロックやコンテンツ規則を再利用しましょう。 インポートで再現されないコンテンツやインタラクションが見つからない場合は、レポートします。 アップロード、プッシュ、または公開しないでください。
サンプル URLとパスを独自のパスに置き換えます。Experience Manager オーサリングの場合は、コンテンツがJCRに保存されているとします。
-
コンテンツ構造（エージェントが選択したセクション、デフォルトコンテンツ、ブロック、バリエーション、セクションスタイル）を確認します。 作成者は、この構造のすべての移行ページを編集するので、サンプルページで設定します。 コンテンツ構造のシェイプ を参照してください。
-
インポートしたテキスト、リンク、画像、メタデータ、セクションの順序をソースと比較します。 パターンが間違っている場合は、ページではなくインポートスクリプトを修正します。 エージェントの大規模な移行方法を参照してください。
-
ソースのスタイル設定を適用するか、 デザイン変更ワークフローに従います。 個々のブロックを調整する前に、グローバルスタイルを確認します。
-
ページの読み込みとは別に、共有ヘッダー、ナビゲーション、フッターを入力します。 エージェントは、フッター画像を含め、すべてのページが1つのヘッダーと1つのフッターを共有するように、サイト全体に1回移行します。
-
サンプルページをコンテンツの宛先にアップロードしてから、編集、保存、再オープン、プレビューを行います。
-
より多くのページを読み込む前に、ソースから出力への合意されたマッピング、ブロックモデル、設計決定、既知の例外を記録します。
ページの作成者が編集できなくても、右表示のページは失敗します。 Experience Manager オーサリングの場合は、読み込む前に、ブロックモデル、生成されたコンポーネントの設定、変換エラー、画像の保存場所も確認します。
コンテンツ構造の形成 content-structure
作成者は、エージェントが読み込み時に選択した構造内のすべての移行済みページを編集し、一括読み込みは、テンプレートのすべてのページでその構造を繰り返します。 Edge Delivery Services ページは、デフォルトのコンテンツとブロックを含むセクションで構成されています。 マークアップ、セクション、ブロックおよび自動ブロック を参照してください。 エージェントはDavidのモデル に従い、デザインが可能な限り構造をシンプルに保ちます。なぜなら、すべてのブロックとバリエーションは、作成者が学習するためにさらに1つあるからです。
cards-compactなどのバリエーションを作成します。 異なるフィールドやジョブを持つコンテンツは、独自のブロックを取得します。 オプションコンテンツと異なる数のアイテムではバリエーションは作成されません。dark、light-grey、centeredなど、外観の後にスタイル名を付けます。 セクション内のテキストとボタンはスタイルからカラーを取得するので、カラーだけではブロックやバリエーションを作成することはできません。構造を操作するには：
- 移行する前に、Planning ビューでカタログを確認し、ブロック名とグループ化を修正してください。 カタログの調整を参照してください。
- プロジェクトのブロック、バリアント、セクション スタイルを
AGENTS.mdに記録して、エージェントが後のページと後のセッションで再利用できるようにします。 ドキュメントのコンテンツ規則を参照してください。 - プレビューパネルの ドキュメント表示 の各サンプルページを確認します。このページには、セクション、ブロック、デフォルトコンテンツが表示されます。 コンテンツビューを参照してください。
- 一括読み込みが各ページで修正を繰り返すように、読み込みスクリプトの間違ったパターンを修正します。 エージェントの大規模な移行方法を参照してください。
- サンプルページの編集を依頼します。 使用するブロック、バリエーション、スタイルがわからなければ、選択肢が多すぎます。
著者が選ぶ選択肢は少ない。 デザインシステムは、制作者が必要としない決定を下す必要があります。ブロックに必要な数のバリエーションやオプションを超える数のバリエーションがある場合は、その一部がデザインに属しているかどうかを確認します。
コミットする前に見積もる estimate
カタログと最初のサンプルページでは、ページ数ではなく、サイトが必要とする作業に基づいて見積もりを表示します。
- サイトのカタログ： カタログには、テンプレート、ブロックバリアント、ロケール、失敗したURLが一覧表示されます。 準備とカタログ を参照してください。
- メインテンプレートのサンプルページを検証します。 新しいブロックやスクリプトのインポートのための修正、スタイル設定、コンテンツ構造の変更など、それぞれが必要とするものを記録します。
- 残りのテンプレートのサイズを、サンプルページが必要なサイズから変更します。 後のテンプレートでは、既に存在するブロックが再利用されるため、それぞれが追加するブロックを数えます。 独自のレイアウトを持つページは、独自のテンプレートとしてカウントされます。
- インポートでカバーできない項目を追加します。 スコープ の ビヘイビアー で記録したビヘイビアーと、チームが決定して構築した プロジェクト作業です。
URL 🔗あたりの最初のバッチの レコードに対する見積もりを確認します。
チームとして働く collaboration
複数のユーザーがエージェントと同じプロジェクトに取り組むことができ、それぞれが自分の コンソールワークスペース で作業できます。 Gitやコンテンツを通じてコードを共有します。 コンソールには、誰が何に取り組んでいるかが表示されず、2人の変更内容が同じページに統合されないので、誰が何に取り組んでいるかに同意し、互いに話し合い続けます。
スコープは、担当者がいない場合よりも重要です。 1回のリクエストで多数のファイルを変更できるので、2人が同じブロックまたはスタイルを同時に変更する場合、複数のファイル間の競合を手動で解決する必要があります。
移行の主導 phases
移行は段階的に進められます。 担当者は、各チームの反復作業の大部分を行い、チームは意思決定をおこない、その結果を承認します。 最初のフェーズは、移行リードなど1人で実行します。ブロックとインポートスクリプトが解決したら、他の人が参加します。 チームとして作業を参照してください。
ビジュアルコントリビューターは、サンプルページのフェーズ以降でスタイルを設定できます。 視覚的な変更を加えるを参照してください。
1人から始めて、次に作業を分割します divide-work
最初のステップは、他のすべてが構築する基礎となります。グローバルスタイル、最初のブロック、最初のテンプレートのインポートスクリプトです。 1人で設定します。 作業を分割する前に、ブロックが実際のコンテンツに適合し、作成者が使いやすいことを確認してください。 コンテンツ構造のシェイプ を参照してください。
チームがブロックについて合意したら、メンバーが異なるファイルを変更できるように作業を分割します。
- ブロック別：あるユーザーがカードブロックを調整し、別のユーザーがカルーセルを作成します。
- テンプレート別：各ユーザーは、異なるテンプレートのインポートスクリプトを調整します。 エージェントの大規模な移行方法を参照してください。
- 専門分野： デザイナーは、開発者が統合を構築している間に、既存のブロックのスタイルを調整します。
同じブロック、グローバルスタイル、または同じ読み込みスクリプトを2人に同時に与えないでください。ただし、調整方法に同意する必要があります。
小さな手順でコードを共有 share-code
mainまたは開発ブランチなどの共有ブランチに同意します。 コードビューの スイッチ分岐 を使用して、各ユーザーがワークスペースをワークスペースに切り替えます。- エージェントへの各リクエストは、1つのブロック、テンプレート、タスクに集中させることができます。 新しいPRを作成して、動作するとすぐに結果をプッシュします。コンソールは、変更を新しいブランチにプッシュし、プルリクエストを共有ブランチに開き、ワークスペースを新しいブランチに残します。
- プルリクエストは頻繁にレビューして統合します。 小さな変更は競合が少なく、レビューが迅速に行われます。また、プルリクエストが数日間開いたままの場合、競合が収集されます。
- 新しいタスクを開始する前に、Switch ブランチで共有ブランチに切り替え、Sync > Pull > Codeで引き出して、全員の結合された作業に基づいて構築します。
プルが利用できない場合や競合が報告された場合は、他のユーザーがブランチを変更した場合を参照してください。
また、小さなプッシュ通知を頻繁に送信することで、担当者が何を変更し、なぜ変更したのかを把握できます。 リクエストごとに1つのコミットを取得するには、各リクエストのレコードを残すを参照してください。
コンテンツの変更を調整 share-content
コンテンツには結合がありません。 ワークスペースにはページのコピーが保持され、アップロードすると、コンテンツの宛先のページがコピーに置き換えられます。 2人が同じページを変更すると、最後のアップロードが成功し、他のユーザーの変更が失われます。 各ページ、または一連のページを、一度に1人に与えます。
他のユーザーがワークスペースにアップロードしたページを取得するには：
- コンテンツビューでクラウドアイコンを表示するページを開きます。 コンソールがワークスペースにダウンロードします。
- ドキュメントベースのプロジェクトで、Sync > Pull > Contentを選択して、Experience Workspaceからすべてのページをダウンロードします。 アップロードしていない編集内容を含め、ローカルコピーが置き換えられるので、最初に保存する編集内容をアップロードします。
一括読み込み batches
サンプルページを検証したら、 カタログの一括読み込みワークフローと一括読み込みプロンプト を使用します。
- テンプレートのインポートスクリプトを使用して小さなバッチをインポートします。
- 通常のページとエッジケースを確認してください。 読み込みスクリプトが正しくない場合は、修正し、影響を受けるページを再度読み込んでから続行してください。
- 宛先、インポート状態、エラー、サインオフ、承認済みの除外など、各ソース URLのレコードを保持します。
- テンプレートごとにテンプレートを続行。 検出、分析、読み込み、失敗、スキップ、サインオフの各ページを個別にカウントします。
- 共有スタイルの変更、スクリプトの読み込み、ブロックモデルまたはブロックコードを使用する場合は、以前のサンプルページを再確認します。
作成者がコンテンツの宛先で移行されたページの編集を開始すると、そのページは信頼できる唯一の情報源になります。 これらのページの読み込みまたはアップロードを再度行うと、作成者の作業が上書きされ、修正された読み込みスクリプトが結合されないので、まず作成者に同意します。
サイトの完成 complete-site
自動インポートは、配信の一部です。 合意された要件を実施し、検証します。
- ヘッダー、フッター、ナビゲーション、内部リンク、エラーページ。
- 画像、ダウンロード、フォント、アセットの権限、保持されているDynamic Mediaの参照などです。
- タイトル、説明、規範的なURL、構造化データ、リダイレクト、サイトマップ、必要に応じてロケール関係を管理できます。
- Forms、検索、コマース、アカウント機能、分析、同意、その他の統合。
- オーサーのガイダンス、運用上の所有権、アクセス、デプロイメント設定。
エージェントは、検索またはコマース APIを呼び出すブロック、フォーム、分析と同意を読み込むコードなど、これらのコード側を実装します。 検索サービス、CDN、分析アカウントなど、リポジトリやコンテンツ以外のシステムを設定することはできず、要件を決定することもできません。 API ドキュメントと合意された動作を指定し、結果をサインオフする各外部システムの所有者に名前を付けます。 Connect Services and Applications （フォームの場合： フォーム送信）および商品ページの場合：Commerce Pages）を参照してください。
画像とドキュメント assets
画像が新しいサイトに到達する方法は、コンテンツの宛先によって異なります。
- Experience Workspace: コンソールで作業している間も、読み込まれたページはソースサイトの画像を参照できます。 ページをアップロードすると、コンソールは、ソースからダウンロードした画像を含む画像を、先頭のドットが付いたページにちなんで名前の付いたフォルダーにアップロードします。 アップロードされたコピーがページにポイントされます。 画像が見つからない場合、サポートされていない形式の場合、またはあいまいな場合、コンソールは画像を報告し、ページをアップロードしません。 アップロード後、すべての画像が到着したかどうかをチェックします。 「 コンテンツをアップロード 」を参照してください。
- Experience Manager オーサリング： コンテンツパッケージをアップロードする際に 画像をアップロード を選択し、
/content/dam/の下のフォルダーを選択します。 デフォルトは、/content/dam/siteです。 「 コンテンツをアップロード 」を参照してください。 - Adobe Dynamic Media: ソースがDynamic Mediaから提供する画像（Scene7やOpenAPI URL付きDynamic Mediaなど）は、そのまま残ります。 読み込まれたページがそれらを参照し、プロジェクトのコードがそれらをレンダリングします。
Edge Delivery Servicesでは、各画面に合わせたサイズと形式で画像を提供します。 ファイルの種類とサイズ 🔗の制限に照らし合わせて、大きなファイル、ビデオ、SVGの画像を確認します。
サンプルページのPDFなどのドキュメントへのリンクを確認してください。 各リンクは、引退するソースサイトではなく、新しいサイトのコピーを指している必要があります。
URL、リダイレクト、検索メタデータ urls-seo
エージェントは、各ページのパスをソース URLから取得します。 パスを小文字にし、.htmlを削除し、末尾の/をindexに変換し、スペースやアンダースコアなどの他の文字をハイフンに置き換えます。 /About_Us.htmlは/about-usになります。 このように変更されたURLや、目的に応じて変更したURLは、すべてリダイレクトが必要です。
担当者は、リダイレクト、サイトマップ、言語の代替案を単独で作成することはありません。 タスクとして依頼し、結果を確認します。
- リダイレクト： Sourceと Destination 列を持つ
redirectsスプレッドシート （URLごとに1行、ワイルドカードなし）。 パスが変更されたソース URLを、シートの行として一覧表示するようにエージェントに依頼します。 リダイレクト を参照してください。 - ページメタデータ：読み込みでは、各ページのタイトル、説明、ソーシャルイメージがメタデータブロックに保持されます。 多数のページのメタデータを一度に設定するには、
metadataスプレッドシートを使用します。 バルクメタデータ を参照してください。 - サイトマップと言語： リポジトリ内の
helix-sitemap.yamlファイル。各ページの代替言語（hreflang）を含めることができます。 サイトマップ を参照してください。 - 検索エンジン： プレビューサイトとライブサイト
*.aem.pageおよび*.aem.liveは検索エンジンから非表示になっています。実稼動ドメインはそうではありません。 カットオーバーの前にrobots.txtを確認してください。 robots.txtを参照してください。 - クエリインデックス：記事リストやサイト検索などのページのリストは、公開されたページのみを含むクエリインデックスから読み取られます。 インデックス作成を参照してください。
確認してログオフ acceptance
リリース前に動作する必要のあるものをサイト所有者に同意し、プレビューサイトとライブサイトでテストします。 サイトオーナーは、テスターと作成者と共に結果を承認します。
各シグナルは、スクリプトが実行したインポーターステータス、コンテンツが変換された生成パッケージ、ページがソースのように見える視覚的な類似性スコア、ラボテストで1 ページが読み込まれるLighthouse スコアなど、1つのことをチェックします。 実稼動準備には、テーブル内のあらゆる領域が必要です。
リリース、回復、および引き継ぎ handoff
リリースオーナーは、コードの結合、コンテンツの公開、ドメインのカットオーバーを調整し、サイトの継続的な所有者が引き継いだことを確認します。
- ログオフしたコードをプッシュして、リポジトリのポリシーに従ってレビューしてもらいます。
mainに統合すると、ライブサイトのコードがすぐに更新されるため、コンテンツリリースと統合を計画します。 変更内容の公開方法を参照してください。 - 承認済みのコンテンツと画像のみを確認済みの宛先にアップロードします。 各ページと画像のエラーを確認します。
- プレビューサイト
*.aem.pageで意図したコードリビジョンを使用して、保存されたコンテンツを確認します。 - サイトのリリース承認を取得し、設定された公開およびドメインのカットオーバープロセスに従います。 公開すると、ページは
*.aem.liveで利用できるようになります。カットオーバーは、Adobeが管理するCDNまたは独自のCDNを通じて、自分のドメインで提供されます。 カットオーバーの前に、公開チェックリスト を確認します。 - リリース後のライブ URL、リダイレクト、主要なジャーニー、モニタリングを確認します。 運用上のテレメトリ は、実際の訪問者がサイトのパフォーマンスをどのように体験しているかを示します。
- プロジェクトの引き継ぎ、URLごとのレコード、作成者の例、サインオフ結果、例外、回復用の連絡先を指定します。
何か問題が発生した場合は、正確なURLまたはパス、操作、エラーログを保持します。 原因を修正した後、影響を受けた最小の範囲を再試行してください。 1つのページが失敗したため、正常なバッチを再起動しないでください。
コードのプッシュ、ドキュメントのアップロード、Experience Managerへのコンテンツパッケージの読み込み、公開は、別々のシステムでの個別の操作です。 部分的なエラーでは、一部の変更のみを適用できます。1回のロールバックですべての変更を元に戻すことはできません。 Gitを通じてコードを復元し、コンテンツの宛先または合意したプロセスのバージョン履歴を通じてコンテンツと画像を復元します。