升級代碼和自定義

在規劃升級時,需要調查並解決實施的下列領域。

概覽

  1. 模式偵測器 -如升級規劃中所述及本頁中所述執行模式偵測器,以取得模式偵測器報表,其中除了Target版本的不可用API/組合外,還包含需要解決之區域的詳細資訊AEM。「模式偵測」報表應指出程式碼中有任何不相容之處,如果沒有相容,則您的部署已相容於6.4,您仍可選擇使用6.4功能進行新開發,但您不需要它來維持相容性。 如果報告了不相容性,則可以選擇a)以相容性模式運行,並推遲開發新6.4功能或相容性; b)在升級後決定進行開發,然後轉到步驟2。 請參閱6.4中的AEM向後相容性,以取得詳細資訊。

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

  3. 使用6.4 Uberjar編譯 -更新代碼庫POM,指向6.4 Uberjar並編譯代碼。

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

  5. 部署至6.4環境 -在Dev/QA環境中,AEM應啟用6.4(作者+發佈)的簡潔實例。應部署更新的程式碼庫和代表性的內容範例(來自目前的生產環境)。

  6. QA驗證和錯誤修正 - QA應在6.4的「作者」和「發佈」例項上驗證應用程式。發現的任何錯誤都應修正並提交至6.4程式碼庫。視需要重複「開發週期」,直到修正所有錯誤。

在繼續升級之前,您應擁有穩定的應用程式碼庫,並已針對目標版本的完整測試AEM。 根據測試中的觀察,可以有方法最佳化自訂程式碼。 這可能包括重構代碼以避免遍歷儲存庫、自定義索引以優化搜索,或在JCR中使用無序節點等。

除了升級程式碼庫和自訂以搭配新版本使用的選項外AEM, 6.4還可協助您使用本頁所述的「向後相容性」功能,更有效率地管理自訂。

如上圖所示,在第一步中運行模式檢測器將幫助您評估升級的整體複雜性,以及您是否要以相容模式運行或更新自定義以使用所有新AEM6.4功能。 如需詳細資訊,請參閱6.4<a1/AEM>中的[向後相容性頁面。
](/docs/experience-manager-64/deploying/upgrading/backward-compatibility.html?lang=zh-Hant) screen_shot_2018-03-30at175257

升級代碼庫

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

您實作所需的所有程式碼AEM和組態都應使用某種版本控制來管理。 應建立版本控制中的專用分支,以管理目標版本中代碼庫所需的任何更改AEM。 此分支將管理針對目標版本及後續錯誤修AEM正的程式碼庫反覆測試。

更新AEMUber Jar版本

Uber AEM jar將所有AEMAPI作為單一依賴項包含在Maven項目的pom.xml中。 將Uber Jar納入為單一相依性,而不是納入個別API相依性,永遠是最佳AEM做法。 升級代碼庫時,應將Uber Jar的版本更改為指向的目標版本AEM。 如果您的專案是在Uber Jar存在之AEM前開發的版本,則所有個AEM別API相依性都應移除,並由目標版本的Uber Jar中的單一包含項取代AEM。 然後,應根據新版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()使用管理會話在6.0之前的代碼庫中非常普遍AEM。由於這些方法的存取範圍太廣,因此已因安全原因而遭到淘汰。 在Sling的未來版本中,這些方法將會移除。強烈建議您重新調整任何程式碼,以改用「服務使用者」。 有關服務用戶和如何淘汰管理會話的詳細資訊,請參閱此處

查詢和Oak索引

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

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

Classic UI編寫

傳統的UI編寫功能仍可在AEM6.4中使用,但已過時。 如需詳細資訊,請至這裡。 如果您的應用程式目前在Classic UI作者環境上執行,建議升級至AEM6.4並繼續使用Classic UI。 然後可規劃為個別專案,以在數個開發週期中完成移轉至Touch UI。 為了在6.4版中使用Classic UI,AEM需要將幾個OSGi配置提交到代碼庫。 有關如何配置此選項的詳細資訊,請參閱此處

注意

若要協助您擺脫傳統UI並運用最新技術AEM,請考慮運用AEM Meduration Tools,讓您的移轉更輕鬆。

與6.4儲存庫結構對齊

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

因此,必須移動一些設定,使之不再像過去那樣位於/etc下方。 要複查在更新到6.4時必須審查並滿足的全套資料庫重組問題,請參見6.4<a1/AEM>中的AEM資料庫重組。

AEM自定義

需要確定源AEM版本中編寫環境的AEM所有自定義。 在識別後,建議您將每個自訂項目儲存在版本控制中,或至少儲存在內容套件的備份中。 所有自訂應在生產升級之前,在執行目標版本的QA或測試環境AEM中部署和驗證。

一般的覆蓋

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

升級自訂搜尋Forms

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

資產UI自訂

注意

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

必須為具有自訂資產部署的例項準備升級。 這是為了確保所有自訂內容都與新的6.4節點結構相容所需。

您可以執行下列動作,準備資產UI的自訂設定:

  1. 在需要升級的實例上,通過轉到https://server:port/crx/de/index.jsp開啟CRXDE Lite

  2. 轉到以下節點:

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

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

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

  6. 刪除​content_backup​節點。

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

為現有資產產生資產ID

若要為現有資產產生資產ID,請在您將例項升級至執行AEM6.AEM4時升級資產。這是啟用資產前瞻分析功能的必要條件。 如需詳細資訊,請參閱新增內嵌代碼

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

1487758945977

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

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

InDesign指令碼自定義

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

恢復ContextHub配置

ContextHub組態是由升級所決定。 有關如何恢復現有ContextHub配置的說明,請參閱此處

工作流定制

您通常會在開箱即用的工作流程中進行更新,以新增或移除不需要的功能。 自訂的常見工作流程是「DAM更新資產」工作流程。 自訂實作所需的所有工作流程都應備份並儲存在版本控制中,因為升級期間可能會覆寫這些工作流程。

可編輯的範本

注意

只有使用6.2版可編輯範本的網站升級才需AEM要此程式

可編輯範本的結構在6.2AEM和6.3之間變更。如果您是從6.2或更舊版本升級,而且如果您的網站內容是使用可編輯的範本建立,則需要使用回應式節點清理工具。 此工具的用途是在​升級後執行,以清除內容。 它必須同時在「作者」和「發佈」層上執行。

CUG實施變更

封閉使用者群組的實施已大幅改變,以解決舊版的效能與延展性限AEM制。 舊版CUG已在6.3中停用,而新實作僅在Touch UI中受支援。 如果從6.2或更新版本升級,則可以在此處找到遷移到新CUG實施的說明。

測試過程

應為測試升級準備完整的測試計畫。 測試升級後的程式碼庫和應用程式時,必須先在較低的環境中完成。 發現的任何錯誤都應以反覆方式加以修正,直到代碼庫穩定為止,只有當代碼庫穩定時,才應升級更高級別的環境。

測試升級過程

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

實施測試區域

以下是在升級環AEM境並部署升級的代碼庫後,測試計畫應涵蓋的任何實施的關鍵部分。

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

文檔測試計畫和結果

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

本頁內容

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now