文件AEM 6.4Deploying 指南

升級程式碼和自訂 upgrading-code-and-customizations

Last update: Thu May 04 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

建立對象：

  • Developer
CAUTION
AEM 6.4已結束延伸支援，本檔案不再更新。 如需詳細資訊，請參閱 技術支援期. 尋找支援的版本 此處.

規劃升級時，需要調查並處理實作的下列方面。

概觀 overview

  1. 圖樣偵測器 — 按升級計畫中所述運行模式檢測器，並詳細說明 本頁 若要取得模式偵測器報表，除了Target版本AEM中無法使用的API/套件組合外，還需要處理區域的詳細資訊。 「模式偵測」報表應可指出程式碼中有任何不相容之處，如果沒有相容，表示您的部署已相容6.4，您仍可以選擇進行新開發，以利用6.4功能，但您不僅需要它來維護相容性。 如果報告了不相容，則可以選擇a)以相容模式運行，並推遲新的6.4功能或相容性的開發；b)升級後決定進行開發，然後轉到步驟2。 請參閱 AEM 6.4的向後相容性 以取得更多詳細資訊。

  2. 開發6.4版程式碼庫 — 為Target版本的程式碼基底建立專用的分支或存放庫。 使用升級前相容性中的資訊來規劃要更新的代碼區域。

  3. 使用6.4 Uber jar編譯 — 更新代碼基POM以指向6.4 uber jar，並針對此編譯代碼。

  4. 更新AEM自訂 - AEM的任何自訂或擴充功能應更新/驗證，以在6.4中運作，並新增至6.4程式碼基底。 包含UI搜尋Forms、資產自訂、任何使用/mnt/覆蓋的項目

  5. 部署至6.4環境 — 在開發/QA環境中，應該有乾淨的AEM 6.4例項（製作+發佈）。 應部署更新的程式碼基底和具有代表性的內容範例（來自目前的生產環境）。

  6. QA驗證和錯誤修正 - QA應驗證6.4的製作和發佈執行個體上的應用程式。發現的任何錯誤都應修正並提交至6.4程式碼基底。 視需要重複開發週期，直到所有錯誤都修正完畢。

繼續升級之前，您應該有穩定的應用程式程式碼基底，且已針對AEM的目標版本進行徹底測試。 根據測試中的觀察，可以有方法最佳化自訂程式碼。 這可能包括重構程式碼以避免遍歷儲存庫、自訂索引以最佳化搜尋，或在JCR中使用無序節點等。

除了升級程式碼基底和自訂以搭配新的AEM版本運作的選項， 6.4也可協助您使用回溯相容性功能更有效率地管理自訂，如 本頁.

如上所述，並如下圖所示，執行 圖樣偵測器 第一步將幫助您評估升級的整體複雜性，以及您是否要以相容模式運行或更新自定義以使用所有新的AEM 6.4功能。 請參閱 AEM 6.4的向後相容性 頁面以取得更多詳細資訊。
screen_shot_2018-03-30at175257

升級程式碼庫 upgrade-code-base

在版本控制項中為6.4代碼建立專用分支 create-a-dedicated-branch-for-6-4-code-in-version-control

您的AEM實作所需的所有程式碼和設定，都應使用某種版本控制來管理。 應建立版本控制中的專用分支，以管理目標版本AEM中程式碼基底所需的任何變更。 在此分支中，會針對AEM的目標版本進行程式碼基底的反覆測試，並管理後續的錯誤修正。

更新AEM Uber Jar版本 update-the-aem-uber-jar-version

AEM Uber jar會在Maven專案的 pom.xml. 將Uber Jar納入為單一相依性，而非納入個別AEM API相依性，永遠是最佳作法。 升級程式碼基底時，應變更Uber Jar的版本，以指向AEM的目標版本。 如果您的專案是在AEM版本上開發，Uber Jar尚未存在時，所有個別AEM API相依性都應移除，並取代為目標AEM版本僅包含Uber Jar一次。 接著，應根據新版Uber Jar重新編譯程式碼基底。 任何已棄用的API或方法都應更新，以與AEM的目標版本相容。

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

淘汰管理資源解析器的使用 phase-out-use-of-administrative-resource-resolver

通過 SlingRepository.loginAdministrative() 和 ResourceResolverFactory.getAdministrativeResourceResolver() 在AEM 6.0之前的程式碼基底中相當普遍。由於這些方法提供的存取層級過寬，因此已因安全原因而遭到淘汰。 在未來的Sling版本中，這些方法將會移除. 強烈建議重構任何程式碼，以改用服務使用者。 有關服務用戶和 如何在此處逐步淘汰管理會話.

查詢和Oak索引 queries-and-oak-indexes

在升級程式碼基底時，必須徹底測試程式碼基底中查詢的使用。 對於從Jackrabbit 2(6.0以上的AEM版本)升級的客戶，這點尤其重要，因為Oak不會自動為內容編列索引，且可能需要建立自訂索引。 如果從AEM 6.x版升級，現成可用的Oak索引定義可能已變更，且可能會影響現有查詢。

有幾種工具可用於分析和檢查查詢效能：

傳統UI編寫 classic-ui-authoring

AEM 6.4仍提供傳統UI編寫功能，但已淘汰。 如需詳細資訊，請參閱 此處. 如果您的應用程式目前在傳統UI製作環境上執行，建議升級至AEM 6.4並繼續使用傳統UI。 接著，您就可以將移轉至觸控式UI的計畫為個別專案，以在數個開發週期中完成。 若要在AEM 6.4中使用傳統UI，需要將數個OSGi設定提交至程式碼基底。 有關如何配置的更多詳細資訊，請參見 此處.

NOTE
若要協助您擺脫傳統UI並善用最新的AEM技術，請考慮運用 AEM現代化工具 讓移轉更輕鬆。

與6.4儲存庫結構一致 align-repository-structure

為了讓升級更輕鬆，並確保配置在升級期間不會被覆蓋，6.4版中的儲存庫將重組，以將內容與配置分開。

因此，許多設定必須移至下方，才不再位於 /etc 就像過去一樣。 若要檢閱AEM 6.4更新版本中必須審核及修正的完整存放庫重組問題，請參閱 AEM 6.4中的存放庫重新調整架構.

AEM自訂 aem-customizations

需要識別來源版本中AEM製作環境的所有自訂項目。 識別後，建議將每個自訂內容儲存在版本控制中，或至少儲存為內容套件的一部分。 所有自訂項目都應在生產升級前，於執行AEM目標版本的QA或測試環境中部署和驗證。

一般覆蓋 overlays-in-general

通常會使用/apps底下的其他節點覆蓋/libs下的節點和/或檔案，以將AEM擴充至現成可用的功能。 這些覆蓋應在版本控制中受到追蹤，並針對AEM的目標版本進行測試。 如果檔案（無論是JS、JSP、HTL）已覆蓋，建議您對已增強的功能留下註解，以便在目標版AEM上更輕鬆地進行回歸測試。 如需一般覆蓋的詳細資訊，請參閱 此處. 如需特定AEM覆蓋的指示，請參閱下方。

升級自訂搜尋Forms upgrading-custom-search-forms

為了正常運作，自訂搜尋刻面在升級後需要進行一些手動調整。 如需詳細資訊，請參閱 升級自訂搜尋Forms.

資產UI自訂 assets-ui-customizations

NOTE
只有從AEM 6.2以前的版本升級時，才需要此程式。

具有自訂Assets部署的執行個體需要準備以進行升級。 這是為了確保所有自訂內容都與新的6.4節點結構相容所需。

您可以執行下列動作，準備對Assets UI的自訂：

  1. 在需要升級的執行個體上，開啟CRXDE Lite，前往 https://server:port/crx/de/index.jsp

  2. 前往下列節點：

    • /apps/dam/content

  3. 將內容節點重新命名為 content_backup. 要執行此操作，請按一下右鍵窗口左側的瀏覽器窗格，然後選擇 重新命名.

  4. 重新命名節點後，請在「 」下建立名為「 content 」的新節點 /apps/dam 已命名 內容 將節點類型設定為 sling:Folder.

  5. 移動 content_backup 新建立的內容節點。 您可以按一下右鍵瀏覽器窗格中的每個子節點並選擇 移動.

  6. 刪除 content_backup 節點。

  7. 下方的更新節點 /apps/dam 節點類型正確 sling:Folder 最好將儲存至版本控制項，並與程式碼基底一起部署，或至少備份為內容套件。

為現有資產產生資產ID generating-asset-ids-for-existing-assets

若要為現有資產產生資產ID，請在升級AEM執行個體以執行AEM 6.4時升級資產。這是啟用 Assets Insights功能. 如需詳細資訊，請參閱 新增內嵌程式碼.

若要升級資產，請在JMX主控台中設定「關聯資產ID」套件。 視存放庫中的資產數量而定， migrateAllAssets 可能需要很長時間。 我們的內部測試估計，TarMK上的12.5萬個資產大約需要1小時。

1487758945977

如果您需要整個資產子集的資產ID，請使用 migrateAssetsAtPath API。

對於所有其他用途，請使用 migrateAllAssets() API。

InDesign指令碼自定義 indesign-script-customizations

Adobe建議將自訂指令碼放在 /apps/settings/dam/indesign/scripts 位置。 如需InDesign指令碼自訂的詳細資訊，請參閱 此處.

恢復ContextHub配置 recovering-contexthub-configurations

ContextHub設定會受升級影響。 有關如何恢復現有ContextHub配置的說明 此處.

工作流程自訂 workflow-customizations

通常會更新現成可用的修改工作流程，以新增或移除不需要的功能。 DAM更新資產工作流程是自訂的常見工作流程。 自訂實作所需的所有工作流程都應備份並儲存在版本控制項中，因為升級期間可能會加以覆寫。

可編輯的範本 editable-templates

NOTE
只有使用AEM 6.2的可編輯範本進行網站升級時，才需要執行此程式

在AEM 6.2和6.3之間更改的可編輯模板的結構。如果您從6.2或更早版本升級，並且使用可編輯模板構建網站內容，則需要使用 回應式節點清理工具. 此工具旨在執行 after 升級以清理內容。 它需要同時在製作和發佈層級上執行。

CUG實作變更 cug-implementation-changes

封閉使用者群組的實作已大幅變更，以解決舊版AEM的效能和可擴充性限制。 舊版CUG已於6.3中淘汰，而新實作僅支援觸控式UI。 如果您從6.2版或更新版本升級，則可找到要遷移到新CUG實作的說明 此處.

測試程式 testing-procedure

應為測試升級準備全面的測試計畫。 必須先在較低的環境中測試升級的代碼庫和應用程式。 發現的任何錯誤都應以迭代方式修正，直到程式碼基底穩定為止，只有在此時才應升級較高層級的環境。

測試升級程式 testing-the-upgrade-procedure

此處概述的升級程式應在開發和QA環境中進行測試，如您自訂的執行手冊所述(請參閱 規劃升級)。 應重複升級過程，直到所有步驟都記錄在升級運行手冊中，並且升級過程順利。

實作測試區域 implementation-test-areas-

以下是任何AEM實作的重要區域，在環境升級並部署升級的程式碼基底後，應由您的測試計畫涵蓋。

功能測試區
說明
發佈的網站
在發佈層級上測試AEM實作和相關的程式碼
透過dispatcher。 應包含頁面更新的條件，以及
快取失效。
編寫
在製作層級上測試AEM實作和相關聯的程式碼。 應包含頁面、元件編寫和對話方塊。
與Marketing Cloud解決方案的整合
驗證與Analytics、DTM和Target等產品的整合。
與協力廠商系統的整合
任何第三方整合都應在製作和發佈層級上進行驗證。
驗證、安全性和權限
任何驗證機制（如LDAP/SAML）都應經過驗證。
權限和群組應同時在「作者」和「發佈」上測試
分層。
查詢
應測試自訂索引和查詢以及查詢效能。
UI自訂
製作環境中AEM UI的任何擴充功能或自訂項目。
工作流程
自訂和/或現成可用的工作流程和功能。
效能測試
應同時在模擬實際情況的製作和發佈層級上執行負載測試。

文檔測試計畫和結果 document-test-plan-and-results

應建立涵蓋上述實作測試區域的測試計畫。 在許多情況下，依「作者」和「發佈」任務清單來區隔測試計畫是有意義的。 升級生產環境之前，應先在開發、QA和預備環境上執行此測試計畫。 測試結果和效能量度應在較低環境中擷取，以便在升級預備和生產環境時提供比較。

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56