升級代碼和自定義

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

概覽

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

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

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

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

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

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

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

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

如上圖所示,在第一步中執行Pattern Detector將協助您評估升級的整體複雜性,以及您是要以相容模式執行或更新自訂,以使用所有新的AEM 6.4功能。 如需詳細資訊,請參閱AEM 6.4的「向後相容性」頁面。
screen_shot_2018-03-30at175257

升級代碼庫

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

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

更新AEM Uber Jar版本

AEM Uber jar會將所有AEM API作為單一相依關係納入您的Maven專案的pom.xml。 將Uber Jar納入為單一相依性,而不是納入個別AEM API相依性,永遠是最佳做法。 升級程式碼庫時,Uber Jar的版本應變更為指向AEM的目標版本。 如果您的專案是在Uber Jar存在之前以AEM版本開發的,所有個別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索引定義可能已變更,並可能影響現有的查詢。

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

Classic UI編寫

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

注意

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

與6.4儲存庫結構對齊

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

因此,必須移動一些設定,使之不再像過去那樣位於/etc下方。 若要檢視完整的資料庫重組顧慮,而這些顧慮必須在更新至AEM 6.4時加以檢視和修正,請參閱「AEM 6.4中的資料庫重組」。

AEM自訂

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

一般的覆蓋

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

升級自定義搜索表單

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

資產UI自訂

注意

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

必須為具有自訂資產部署的例項準備升級。 這是為了確保所有自訂內容都與新的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,請在您升級AEM實例以執行AEM 6.4時升級資產。這是啟用資產前瞻分析功能的必要條件。 如需詳細資訊,請參閱新增內嵌代碼

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

1487758945977

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

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

InDesign Script自訂

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

恢復ContextHub配置

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

工作流定制

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

可編輯的範本

注意

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

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

CUG實施變更

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

測試過程

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

測試升級過程

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

實施測試區域

以下是任何AEM實作的重要部分,在環境升級並部署升級的程式碼庫後,測試計畫應涵蓋這些部分。

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

文檔測試計畫和結果

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

本頁內容