升級代碼和自定義

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

概覽

  1. 模式偵測器 — 如升級規劃中所述並在本頁中詳細說明,執行模式偵測器,以取得模式偵測器報表,其中包含除了AEM Target版本中無法使用的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

升級代碼庫

在版本控制項中為6.4代碼建立專用分支

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

更新AEM Uber Jar版本

AEM Uber jar會在Maven專案的pom.xml中,將所有AEM API視為單一相依性。 將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>

淘汰管理資源解析器的使用

透過SlingRepository.loginAdministrative()ResourceResolverFactory.getAdministrativeResourceResolver()使用管理工作階段在AEM 6.0之前的程式碼基底中相當普遍。由於這些方法的存取範圍太廣,因此安全性原因已遭取代。 在未來的Sling版本中,這些方法將遭到移除。強烈建議重構任何程式碼,以改用服務使用者。 有關服務用戶和如何逐步淘汰管理會話的更多資訊,請參見此處

查詢和Oak索引

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

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

傳統UI編寫

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

注意

若要協助您遠離傳統UI並運用最新的AEM技術,請考慮運用AEM現代化工具,讓您更輕鬆進行移轉。

與6.4儲存庫結構一致

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

因此,許多設定必須移至不再如過去般位於/etc下。 若要查看AEM 6.4更新版本中必須審查和滿足的完整存放庫重組問題,請參閱AEM 6.4🔗中的存放庫重組。

AEM自訂

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

一般覆蓋

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

升級自訂搜尋Forms

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

資產UI自訂

注意

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

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

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

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

  2. 前往下列節點:

    • /apps/dam/content
  3. 將內容節點更名為​content_backup。 要執行此操作,請按一下右鍵窗口左側的瀏覽器窗格,然後選擇​更名

  4. 重新命名節點後,在/apps/dam下建立名為​content​的新節點,並將其節點類型設定為​sling:Folder

  5. 將​content_backup​的所有子節點移至新建立的內容節點。 要執行此操作,請按一下右鍵瀏覽器窗格中的每個子節點,然後選擇​Move

  6. 刪除​content_backup​節點。

  7. /apps/dam下方更新的節點類型sling:Folder應理想地保存到版本控制中,並與代碼庫一起部署,或至少備份為內容包。

產生現有資產的資產ID

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

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

1487758945977

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

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

InDesign指令碼自定義

Adobe建議將自訂指令碼放在/apps/settings/dam/indesign/scripts位置。 有關InDesign指令碼自定義的詳細資訊,請參見此處

恢復ContextHub配置

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

工作流自定義

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

可編輯的範本

注意

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

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

CUG實作變更

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

測試過程

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

測試升級過程

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

實作測試區域

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

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

文檔測試計畫和結果

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

本頁內容