在此過程的實施階段,您將探索各種工具,通過這些工具,您可以隨時將代碼和內容移至AEMas a Cloud Service。
在前一段旅程中, 熟悉as a Cloud Service的變AEM化,以及確定您的部署是否已準備好隨 就緒階段。
本文繼續就如何使用Adobe提供的工具來確保您的代碼和內容已準備好移至雲提供建議。
本文旨在:
在開始之前,您必須熟悉雲管理器,因為它是將代碼部署到AEMas a Cloud Service的唯一機制。
Cloud Manager 可讓組織在雲端中自行管理 AEM。其內容包含持續整合與持續傳送 (CI/CD) 架構,可讓 IT 團隊與實作合作夥伴加快提供自訂或更新的傳送速度,而不會影響效能或安全性。
您可以通過咨詢以下資源來熟悉使用雲管理器:
加入 Experience Manager as a Cloud Service,了解有關加入 Experience Manager as a Cloud Service 的自助資源。
整合 Git 與 Adobe Cloud Manager,了解如何使用 Single Git 存放庫來部署程式碼。
Adobe Experience as a Cloud Service 設定,了解如何「在 Admin Console 中管理產品與使用者存取」。
您向Cloud Service過渡的確切步驟取決於您購買的系統和遵循的軟體開發生命週期做法。
下圖顯示了該階段涉及的主要步驟,這些步驟涉及轉換代碼和內容以用於AEMas a Cloud Service:
我們將開始在以下章節中詳細介紹您需要使用的工具,以實現此目標。
要將內容從當前實AEM例遷移到Cloud Service實例,可以使用Adobe的內容傳輸工具。
使用此工具,即可指定想從您的 AEM 例項轉移至雲端服務例項的內容。
內容遷移是一個多步過程,需要不同團隊之間進行規劃、跟蹤和協作。
有關該工具的工作原理以及我們建議您使用它的完整詳細資訊,請參閱 內容傳輸工具文檔。
現在是時候開始重構與Cloud Services相容的現有功能了。
為此,您需要查看詳細說明啟動重構代碼所需的基本工具的文檔:
此外,您還可以:
觀看此視頻以瞭解如何在本地安裝Dispatcher SDK:
觀看此視頻以瞭解如何配置Dispatcher SDK:
在as a Cloud Service中開發和運AEM行代碼需要改變思維。 請注意,程式碼必須具復原性,特別是因為例項可能隨時停止。您必須了解,在雲端服務中執行程式碼時,一律會在叢集中執行。這表示執行中的例項永遠多於一個。
Maven項目需要某些AEM更改才能與雲相容。 AEMas a Cloud Service要求 內容 和 代碼 到不同的包中AEM:
/apps
和 /libs
被視為不可變AEM的區域,因為它們在啟AEM動後無法更改(即在運行時)。 這包括建立、更新或刪除操作。 在運行時更改不可變區域的任何嘗試都將失敗。
儲存庫中的其他所有內容(例如, /content
。 /conf
。 /var
。 /home
。 /etc
。 /oak:index
。 /system
。 /tmp
)是所有可變區域,這意味著可以在運行時更改這些區域。
通過咨詢 推薦的包結構 文檔。
Adobe提供了多種工具來幫助加速某些代碼重構任務。 瞭解這些工具及其解決的問題將減少遷移的複雜性和時間。
一旦您設定了本地開發環境,請咨詢AEMas a Cloud ServiceSDK 文檔。
要在您的活動代碼開發上管理您的持續代碼開發AEM,並將代碼重構任務作為過渡過程的一部分,我們建議您安排一個代碼凍結期,直到您完成對Maven項目的重組以與as a Cloud Service兼AEM容。
項目重組完成後,可以基於此新結構恢復新代碼開發。 這可減少代碼部署和測試期間Cloud Manager管道故障。
「內容傳輸」和「代碼重構」任務不必按順序完成。 這些任務可以各自獨立完成。不過,您需要正確的專案結構,以確保內容能在雲端服務環境中成功轉譯。
Cloud Manager管道支援針對階段環境運行的test的執行。
請遵循以下文檔中有關代碼質量測試的最佳做法:
為遷移準備源系統涉及系統級和管AEM理員級任務。 您可以通過檢查 修訂 和 資料儲存垃圾收集 任務狀態。 如果您運行的AEM是6.3版(因為內容傳輸工具從6.3版開始相容),建議執行離線壓縮,然後執行資料儲存垃圾收集。
資料一致性檢查 建議跨所有版AEM本進行遷移,以確保內容儲存庫處於啟動遷移活動的良好狀態。
安裝和配置需要系統管理員級別訪問權限 AZCopy
還建議您查看任何未使用的資產、頁AEM面、項目、用戶和組,以節省遷移時間。 查看 內容儲存庫運行狀況 的子菜單。
訪問 生產克隆 已建立,以檢查儲存庫的運行狀況。 如上節所述,目標是在開始遷移之前清理並壓縮源上的儲存庫。 此步驟可能會節省大量時間,否則,在遷移開始後,將花費大量時間進行故障排除。
措施項 | 關鍵要點 |
---|---|
用戶、組和權限 | 您需要瞭解用戶數量、組數量和成員資格的複雜性。 在遷移前查找清除源中任何未使用的用戶和組的機會。 |
未完成資產處理 | 嘗試在開始遷移之前完成源系統中資產的處理,以避免as a Cloud Service遷移後AEM的潛在問題。 |
內容運行狀況 | 建議在開始遷移之前查詢錯誤內容並將其清除。 例如,查找沒有原始格式副本或在工作流處理中停滯的資產或頁面。 另請參閱 資產運行狀況。 |
的 內容遷移策略和時間表 部分進一步詳細說明如何推斷收集的資料並建立遷移計畫。
收集資料可以幫助您規劃遷移活動和相關任務。 提取和攝取時間特別有用,因為資料點可以與遷移集的特定大小相關聯。 因此,可以推斷這些資料點,以便制定計畫:
另一個重要的資料點是完成 用戶映射,如果這與內容遷移相結合。 您可以考慮此資料點,以便進行更為現實的估計,因為它將添加到整個提取時間線中,並且可能不需要在頂部操作期間運行它。
這些資料點也可幫助您 建立KPI 和其他遷移相關任務。
根據您收集的資料點(請參閱上面),您可以建立可整合到宏項目計畫中的遷移計畫。 此步驟將使所有關鍵利益相關方能夠直觀顯示和規劃遷移活動。
下表說明了典型的遷移計畫:
遷移迭代 | 開始日期 | 估計結束日期 | 相依關係 | 估計持續時間(天) | 附加詳細資訊/措施項 |
---|---|---|---|---|---|
PRDCLONE-AUTHOR-INITIAL-USRMAP-CSSTAGE-AUTHOR | |||||
PRDCLONE-PUBLISH-TOPUP-CSSTAGE-AUTHOR |
如上表所示,遵循特定命名格式來標識遷移小版本非常有幫助,例如: PRDCLONE 對於源環AEM境, 作者/發佈 為了AEMas a Cloud Service, CSSTAGE作者 例AEM如as a Cloud Service。
影響遷移計畫的一些重要詳細資訊:
所需提取的總數
所需接收總數
您可以使用遷移跟蹤器記下初始運行和上行運行的時間。 這些資料點將幫助您在最終的備份之前制定真實的內容凍結要求。
該跟蹤器還將幫助您:
下表說明了功能性遷移跟蹤器:
源(環境/實例/URL) | 目標(環境/實例/URL) | 遷移集名稱、類型(初始或自上而下) | 遷移集大小(MB) | 用戶映射(是/否) | 提取持續時間(開始、結束、所用時間) | 攝取持續時間(開始、結束、所用時間) | 問題/解決方案/詳細資訊 |
---|---|---|---|---|---|---|---|
以下部分顯示了可用於制定內容遷移策略和時間表的重要步驟和相關任務。
一旦您完全瞭解了如何評估AEM您的安裝是否已準備好移至雲,我們將學習如何使用使安裝準備就緒所需的工具,現在就是時候繼續 上線階段。