規劃升級

AEM專案概觀

AEM通常用於高影響力的部署，可能為數百萬使用者提供服務。 在大多數情況下，有自訂應用程式會部署在例項上，這會增加複雜性。 升級此類部署的任何努力都必須有條不紊地處理。

本指南可協助您在規劃升級時建立清楚的目標、階段和交付項目。 它著重於整體項目執行和准則。 雖然它提供實際升級步驟的概觀，但是會參考適當的可用技術資源。 它應與檔案所述的可用技術資源一起使用。

AEM升級程式需要謹慎處理規劃、分析和執行階段，並針對每個階段定義關鍵交付項目。

請注意，您可以直接從AEM 6.0版和最高6.4版升級。5.6.x及以下版本的客戶需要先升級至6.0或更新版本，建議使用6.0(SP3)。 此外，新的OAK區段Tar格式現在自6.3起用於區段節點商店，而資料庫移轉至此新格式是強制的，即使6.0、6.1和6.2亦然。

升級範圍和要求

以下是AEM升級專案中受影響的區域清單：

請務必確保您正在運行受支援的作業系統、Java運行時、httpd和Dispatcher版本。 如需詳細資訊，請參閱AEM 6.4技術需求頁面。 升級這些元件需要納入您的專案計畫，而且應在升級AEM之前進行。

項目階段

規劃和執行AEM升級需要做許多工作。 為了釐清這個過程中的不同努力，我們將規劃和執行練習分為不同的階段。 在以下各節中，每個階段都會產生一個交付內容，而項目的未來階段通常會利用它。

Planning for Author Training

在任何新版本中，UI和使用者工作流程都可能會有所變更。 此外，新版本還引入一些新功能，這些新功能可能有助於企業運用。 我們建議您檢閱已引入的功能變更，並組織計畫來培訓您的使用者有效運用這些變更。

AEM 6.4的新功能可在adobe.com](/docs/experience-manager-64/release-notes/release-notes.html?lang=zh-Hant)的[ AEM區段中找到。 請務必注意您組織中常用的UI或產品功能變更。 當您檢視這些新功能時，也請注意對您的組織有價值的功能。 檢視AEM 6.4中的變更後，請為您的作者制定培訓計畫。 這可能需要運用免費提供的資源，例如說明功能視訊或透過Adobe數位學習服務提供的正式訓練。

建立測試計畫

每個客戶的AEM實作都是獨一無二的，而且已自訂以符合其商業需求。 因此，務必確定對系統進行的所有自定義，以便將其納入測試計畫。 此測試計畫將為我們在升級實例上執行的QA過程提供動力。

必須複製實際的生產環境，並在升級後對其執行測試，以確保所有應用程式和自訂程式碼仍視需要執行。 您需要重新執行所有自訂作業，並執行效能、負載和安全性測試。 在組織測試計畫時，請務必涵蓋已對系統進行的所有自訂設定，以及日常操作中運用的現成UI和工作流程。 這些功能可包括自訂OSGI服務和servlet、與Adobe Marketing Cloud的整合、透過AEM連接器與協力廠商的整合、自訂協力廠商整合、自訂元件和範本、AEM中的自訂UI覆蓋，以及自訂工作流程。 對於從AEM 6之前版本移轉的客戶，應分析任何自訂查詢，因為這些查詢可能需要建立索引。 對於已使用AEM 6.x版本的客戶，仍應測試這些查詢，以確保其索引在升級後仍能繼續有效運作。

確定需要的體系結構和基礎架構更改

在升級時，您可能還需要升級技術堆棧中的其他元件，如作業系統或JVM。 此外，由於儲存庫結構的更改，可能需要額外的硬體。 這通常只適用於從6.x以前版本的例項移轉的客戶，但必須考慮。 最後，您的操作做法可能需要進行更改，包括監控、維護和備份和災難恢復過程。

檢閱AEM 6.4的技術需求，確保您目前的硬體和軟體已足夠。 如需作業程式的潛在變更，請參閱下列檔案：

監控和維護：

操作儀表板

Assets 監控最佳實務

使用JMX控制台監控伺服器資源

修訂清除

備份／恢復和災難恢復：

備份和還原

效能與可擴充性

如何使用TarMK Cold Standby運行AEM

內容重組注意事項

AEM 6.4已對儲存庫結構進行變更，有助於更順暢地升級。 這些變更包括根據Adobe或客戶是否擁有內容，將內容從/etc檔案夾移出至資料夾，包括/libs、/apps和/content，以限制在發行期間覆寫內容的機率。 資料庫重組的方式是，在6.4升級時不需要變更程式碼，不過建議在規劃升級時，檢閱AEM 6.4中「資料庫重組」的詳細資訊。

評估升級複雜性

由於我們客戶在AEM環境中所套用的自訂數量和性質多種多樣，因此請務必先花點時間，以決定您在升級時應該付出的整體努力。

您可以採用兩種方法來評估升級的複雜性，初步階段只需使用新推出的Pattern Detector（可在AEM 6.1、6.2和6.3執行個體上執行）。 模式偵測器是使用報告的模式來評估升級整體複雜度最簡單的方式。 模式偵測器報表包含用於識別自訂程式碼基底正在使用之不可用API的模式（這是使用6.3中的升級前相容性檢查來完成）。

在初次評估後，更全面的下一步可能是對測試實例執行升級並執行一些基本煙霧測試。 Adobe也提供一些。 此外，已過時和已移除功能的清單不僅應該針對您要升級至的版本進行審查，而且應該針對源版本和目標版本之間的任何版本進行審查。 例如，如果從AEM 6.2升級至6.4，除了AEM 6.4的功能外，請務必檢閱AEM 6.3已過時和已移除的功能。

6.4版中引入的圖樣偵測器，應該能讓您對大多數情況的升級期間預期內容有相當精確的估計。 不過，若是更複雜的自訂和部署，若您有不相容的變更，您可依照執行就地升級中的指示，將開發執行個體升級至AEM 6.4。 完成後，在此環境上執行一些高級煙霧測試。 本練習的目的不是詳盡地完成測試案例清單並產生正式的缺陷清單，而是讓我們大致估計升級程式碼以達到6.4相容性所需的工作量。 當結合模式檢測和在前一節中確定的體系結構變化時，可以向項目管理團隊提供粗略的估計，以規劃升級。

構建升級和回滾操作手冊

雖然Adobe已記錄升級AEM例項的程式，但每位客戶的網路版面配置、部署架構和自訂都需要微調和調整此方法。 因此，我們鼓勵您檢閱我們提供的所有檔案，並使用它通知專案特定的操作手冊，其中概述您將在環境中遵循的特定升級和回滾程式。 如果從CRX2升級，請務必評估從CRX2移至Oak時，內容移轉所需的時間。 對於大型儲存庫，它可能相當龐大。

我們在升級過程中提供了升級和回滾過程，並在執行就地升級中提供了應用升級的逐步說明。 這些說明應經過審查並考慮到您的系統體系結構、自定義和停機時間容限，以確定在升級期間將執行的適當切換和回滾過程。 在起草自訂的操作手冊時，應包含對架構或伺服器大小的任何變更。 必須指出，這應當作為第一稿處理。 當您的團隊完成其QA和開發週期並將升級部署至測試環境時，可能需要執行一些額外步驟。 理想情況下，本檔案應包含足夠的資訊，如果交給營運人員，他們就能完全從內含的資訊完成升級。

制定項目計畫

我們可使用先前練習的輸出來建立涵蓋測試或開發工作、訓練和實際升級執行所需時間的專案計畫。

綜合項目計畫應包括：

• 最後確定開發和測試計畫

• 升級開發和QA環境

• 更新AEM 6.4的自訂程式碼庫

• QA測試和修正週期

• 升級測試環境

• 整合、效能與負載測試

• 環境認證

• 上線

執行開發和QA

我們已提供與AEM 6.4相容的升級程式碼和自訂程式。當執行此反覆程式時，應視需要變更操作手冊。 另請參閱AEM 6.4](/docs/experience-manager-64/sites-deploying/backward-compatibility.html?lang=zh-Hant)中的[向後相容性，以瞭解在大多數情況下，如何讓自訂維持向後相容，而不需在升級後立即進行開發。

開發和測試過程通常是一個迭代過程。 由於自訂，升級期間所做的變更可能會使整個產品區段無法使用。 一旦開發人員解決問題的根本原因，且測試團隊可以存取這些功能，就有可能發現其他問題。 當發現需要調整升級程式的問題時，請務必將它們新增至您的自訂升級操作手冊。 經過幾次反複測試和修正後，程式碼庫應經過完整驗證，並可部署至測試環境。

最終測試

我們建議在您的組織的QA團隊認證程式碼基底後進行最後一輪測試。 本輪測試將包括在測試環境中驗證您的操作手冊，接著進行使用者接受度、效能和安全性測試。

此步驟至關重要，因為這是您唯一能夠針對類似生產環境驗證操作手冊中的步驟的時間。 在環境升級後，請務必讓使用者有時間登入，並在日常活動中使用系統時，執行其所執行的活動。 使用者運用先前未考慮的系統部分並不少見。 在上線前找出並修正這些區域的問題，可協助防止昂貴的生產中斷。 由於新版AEM包含對基礎平台的重大變更，因此在系統上執行效能、負載和安全性測試也很重要，就像我們第一次啟動它一樣。

執行升級

一旦收到所有利益相關者的最終簽名，就應該對已定義的操作手冊程式執行。 我們在升級過程中提供了升級和回滾的步驟，並在執行就地升級作為參考點中提供了安裝步驟。

我們在環境驗證的升級說明中提供了一些步驟。 這些檢查包括掃描升級日誌和驗證所有OSGi捆綁包是否已正確啟動等基本檢查，但我們建議您也根據業務流程使用自己的測試案例進行驗證。 我們也建議檢查AEM的「線上修訂清除」和相關常式的排程，以確保這些常式會發生在您公司的安靜時間。 這些常式對AEM的長期效能至關重要。