升級代碼和自定義

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

概覽

  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和階段環境上執行。 在較低的環境中，應擷取測試結果和效能度量，以便在升級「階段」和「生產」環境時提供比較。

本頁內容