瞭解多租使用者和同時開發
簡介
當多個團隊將他們的計畫碼部署到相同的AEM環境時，他們應該遵循慣例以確保團隊可以儘可能獨立地工作，而不需要踩到其他團隊的腳步。 雖然這些技巧永遠無法完全消除，但可儘量減少跨團隊的相依性。 同時開發模型若要獲得成功，開發團隊之間的良好溝通至關重要。
此外，當多個開發團隊在相同的AEM環境中工作時，可能會出現某種程度的多租用。 關於嘗試在AEM環境中支援多個租使用者的實際考量已撰寫許多文章，尤其是關於管理治理、營運和開發時面臨的挑戰。 本文探討在多租使用者環境中實施AEM的一些技術挑戰，但其中許多建議將適用於擁有多個開發團隊的任何組織。
預先務必注意，雖然AEM可支援在單一環境中部署多個網站甚至多個品牌，但並未提供真正的多租使用者。 某些環境設定和系統資源將一律在環境中部署的所有網站之間共用。 本檔案旨在提供相關指引，以儘量降低這些共用資源的影響，並提供相關建議，簡化這些領域的溝通和合作。
優點與挑戰
實作多租使用者環境有許多挑戰。
這些類別包括：
- 額外技術複雜性
- 增加開發額外負荷
- 共用資源的跨組織相依性
- 增加營運複雜性
儘管面臨各種挑戰，執行多租使用者應用程式確實有好處，例如：
- 降低硬體成本
- 縮短未來網站的上市時間
- 降低未來租使用者的實作成本
- 全企業的標準架構和開發實務
- 通用程式碼基底
如果企業需要真正的多重租賃，對其他租戶的知識為零，並且沒有共用的程式碼、內容或通用作者，則單獨的作者例項是唯一可行的選項。 應將開發工作的整體增加與基礎結構和授權成本的節省進行比較，以判斷此方法是否最適合。
開發技術
管理相依性
管理Maven專案相依性時，所有團隊務必要在伺服器上使用相同版本的指定OSGi套件。 為了說明當Maven專案受到錯誤管理時可能出現什麼問題，我們舉了一個例子：
專案A依賴於foo程式庫1.0版；foo 1.0版內嵌於其伺服器部署中。 專案B依賴於foo程式庫1.1版；foo 1.1版內嵌於其部署中。
此外，我們假設此程式庫中的API在1.0版和1.1版之間有所變更。此時，這兩個專案中的一個將無法繼續正常運作。
為解決此問題，我們建議將所有Maven專案設為一個父項Reactor專案的子項。 此Reactor專案有兩個用途：如果需要，可一起建置和部署所有專案，並包含所有子專案的相依性宣告。 父專案會定義相依性及其版本，而子專案只會宣告所需的相依性，從父專案繼承版本。
在此案例中，如果專案B的團隊需要foo 1.1版中的功能，在開發環境中，很快就會發現此變更將中斷專案A。此時，團隊可討論此變更，並使專案A與新版本相容，或尋找專案B的替代解決方案。
請注意，這並未免除這些團隊共用此相依性的需求，只是快速及早強調問題，讓團隊可以討論任何風險並同意解決方案。
防止程式碼重複
處理多個專案時，請務必確保程式碼不會重複。 程式碼複製會增加發生瑕疵的可能性、系統變更的成本，以及程式碼庫中的整體硬度。 為避免重複，請將通用邏輯重構為可重複使用的程式庫，以便用於多個專案。
為了支援此需求，我們建議開發和維護所有團隊都可以依賴並參與的核心專案。 進行此操作時，請務必確保此核心專案不取決於任何個別團隊的專案；這允許獨立部署，同時仍可促進程式碼重複使用。
核心模組中常見的一些程式碼範例包括：
- 系統範圍設定，例如：
- OSGi設定
- Servlet篩選器
- ResourceResolver對應
- Sling轉換器管道
- 錯誤處理常式(或使用ACS AEM Commons Error Page Handler1)
- 授權servlet以進行許可權敏感型快取
- 公用程式類別
- 核心商業邏輯
- 協力廠商整合邏輯
- 編寫UI覆蓋圖
- 製作所需的其他自訂，例如自訂Widget
- 工作流程啟動器
- 跨網站使用的常見設計元素
模組化專案架構
這並不能免除讓多個團隊相依並可能更新同一組程式碼的需求。 透過建立核心專案，我們減少了團隊之間共用的程式碼庫大小，減少了但沒有消除共用資源的需求。
為確保對此核心套件所做的變更不會中斷系統的功能，我們建議由資深開發人員或開發人員團隊負責監督。 一個選項是讓單一團隊管理此封裝的所有變更；另一個選項是讓團隊提交由這些資源審查和合併的提取請求。 重要的是，治理模型要由團隊設計和同意，並且開發人員要遵循它。
管理部署範圍
當不同的團隊將他們的程式碼部署到相同的存放庫時，請務必不要覆寫彼此的變更。 AEM有可在部署內容套件（即篩選器）時控制此功能的機制。 xml檔案。 篩選器之間沒有重疊，這一點很重要。 xml檔案，否則一個團隊的部署可能會清除另一個團隊之前的部署。 若要說明這一點，請參閱下列精心製作與有問題的篩選檔案範例：
/apps/my-company與/apps/my-company/my-site
/etc/clientlibs/my-company與/etc/clientlibs/my-company/my-site
/etc/designs/my-company與/etc/designs/my-company/my-site
如果每個團隊明確將其篩選檔案配置到他們正在處理的網站，則每個團隊都可以獨立部署其元件、使用者端程式庫和網站設計，而不會擦除彼此的變更。
由於這是全域系統路徑，而不是特定於某個網站，因此應將以下servlet包含在核心專案中，因為此處所做的更改可能會影響任何團隊：
/apps/sling/servlet/errorhandler
覆蓋
覆蓋圖常用來擴充或取代現成的AEM功能，但使用覆蓋圖會影響整個AEM應用程式（亦即，所有租使用者都可使用任何覆蓋圖功能變更）。 如果租戶對覆蓋圖有不同的要求，這會更複雜。 理想情況下，業務群組應共同合作，就AEM管理主控台的功能和外觀達成一致意見。
如果不同業務單位之間無法達成一致意見，可能的解決方案是直接不使用覆蓋。 請改為建立功能的自訂副本，並透過每個租使用者的不同路徑將其公開。 這可讓每個租使用者獲得完全不同的使用者體驗，但此方法也會增加實作和後續升級工作的成本。
工作流程啟動器
在存放庫中做出指定的變更時，AEM會使用工作流程啟動器自動觸發工作流程執行。 AEM提供數個現成的啟動器，例如用來對新的和更新的資產執行轉譯產生和中繼資料擷取程式。 雖然這些啟動器可以維持原狀，但在多租使用者環境中，如果租使用者具有不同的啟動器及/或工作流程模型需求，則可能需要為每個租使用者建立和維護個別啟動器。 這些啟動器需要設定為在其租使用者的更新上執行，同時保留其他租使用者的內容不變。 將啟動器套用至租使用者專屬的指定存放庫路徑即可輕鬆完成此操作。
虛名 URL
AEM提供虛名URL功能，可依每個頁面設定。 在多租使用者情況下，此方法的問題是AEM無法確保以此方式設定的虛名URL之間的唯一性。 如果兩個不同的使用者為不同的頁面設定相同的虛名路徑，可能會遇到未預期的行為。 因此，我們建議在Apache Dispatcher執行個體中使用mod_rewrite規則，這會允許設定中心點與僅限出站的資源解析器規則一致。
元件群組
為多個編寫群組開發元件和範本時，請務必有效使用componentGroup和allowedPaths屬性。 透過有效地搭配網站設計利用這些功能，我們可以確保品牌A的作者只會看見為其網站建立的元件和範本，而品牌B的作者只會看見其元件和範本。
測試
雖然良好的架構和開放的通訊通道有助於防止網站上的非預期區域出現缺陷，但這些方法並非萬無一失。 因此，在將任何內容發佈到生產環境之前，請務必充分測試平台上正在部署的內容。 這要求團隊之間在發佈週期中進行協調，並強調需要包含儘可能多功能的自動化測試套件。 此外，由於一個系統由多個團隊共用，因此效能、安全性和負載測試變得前所未有的重要。
操作考量
共用資源
AEM在單一JVM中執行；除了已在一般執行AEM中消耗的資源外，任何部署的AEM應用程式本身都會彼此共用資源。 在JVM空間本身內，沒有執行緒的邏輯分隔，而且AEM可用的有限資源（例如記憶體、CPU和磁碟I/O）也會共用。 任何佔用資源的租使用者都會不可避免地影響其他系統租使用者。
效能
如果不遵循AEM最佳實務，就有可能開發消耗超出正常範圍資源的應用程式。 例如，觸發許多繁重的工作流程操作（例如DAM更新資產）、對許多節點使用MSM推播修改操作，或使用昂貴的JCR查詢來即時呈現內容。 這些勢必會影響其他租使用者應用程式的效能。
記錄
AEM提供現成的介面，用於健全的記錄器設定，可在共用開發情境下用於我們的優勢。 透過為每個品牌指定個別的記錄器，以套裝名稱，我們可以達到某種程度的記錄分隔。 雖然系統範圍作業（例如復寫和驗證）仍會記錄到中央位置，但非共用的自訂程式碼可以單獨記錄，讓每個品牌的技術團隊更容易監控和偵錯。
備份和還原
由於JCR存放庫的性質，傳統備份會在整個存放庫中使用，而不是在個別內容路徑中使用。 因此，無法根據租使用者來輕鬆區分備份。 相反地，從備份還原將會復原系統上所有租使用者的內容和存放庫節點。 雖然您可以使用VLT等工具執行目標內容備份，或是挑選要在個別環境中建置套件來還原的內容，但是
方法不容易包含組態設定或應用程式邏輯，而且管理起來可能很麻煩。
安全性考量
ACL
當然，您可以使用存取控制清單(ACL)來控制誰有權根據內容路徑檢視、建立和刪除內容，這需要建立和管理使用者群組。 維護ACL和群組的難度取決於強調確保每個租使用者對其他人的瞭解為零，以及部署的應用程式是否依賴共用資源。 為了確保有效的ACL、使用者和群組管理，我們建議建立一個具有必要監督的集中式群組，以確保這些存取控制項和主體以提升效率和安全性的方式重疊（或不重疊）。
