瞭解多租使用者和同時開發 understanding-multitenancy-and-concurrent-development

簡介 introduction

當多個團隊將他們的計畫碼部署到相同的AEM環境時，他們應該遵循慣例以確保團隊可以儘可能獨立地工作，而不是踩到其他團隊的腳步。 雖然這些技巧永遠無法完全消除，但可儘量減少跨團隊的相依性。 為了讓並行開發模型成功，開發團隊之間的良好溝通至關重要。

此外，當多個開發團隊在相同的AEM環境中工作時，可能會出現某種程度的多租用。 關於嘗試在AEM環境中支援多個租使用者的實際考量，尤其是管理治理、營運和開發時面臨的挑戰，已經有了大量論述。 本文探討在多租使用者環境中實施AEM的一些技術挑戰，但這些建議中許多將套用至擁有多個開發團隊的任何組織。

預先務必注意，雖然AEM可支援在單一環境中部署多個網站甚至多個品牌，但並未提供真正的多租使用者。 某些環境設定和系統資源將一律在環境中部署的所有網站之間共用。 本文提供相關指引，以儘量降低這些共用資源的影響，並提供簡化這些領域溝通與共同作業的建議。

優點與挑戰 benefits-and-challenges

實作多租使用者環境有許多挑戰。

這些類別包括：

儘管面臨各種挑戰，執行多租使用者應用程式確實有好處，例如：

如果企業需要真正的多租使用者，對其他租戶一無所知，且沒有共用的程式碼、內容或共同作者，則唯一可行的選項是單獨的author例項。 應將整體開發工作的增加與基礎結構和授權成本的節省進行比較，以判斷此方法是否最適合。

開發技術 development-techniques

管理相依性 managing-dependencies

管理Maven專案相依性時，所有團隊在伺服器上使用相同版本的指定OSGi套件組合非常重要。 為了說明當Maven專案受到錯誤管理時可能出現什麼問題，我們舉了一個例子：

專案A依賴於foo程式庫1.0版；foo 1.0版內嵌於其伺服器部署中。 專案B依賴於foo程式庫1.1版；foo 1.1版內嵌於其部署中。

此外，我們假設此程式庫中的API在1.0版和1.1版之間有所變更。此時，這兩個專案中的一個將無法繼續正常運作。

若要解決此問題，我們建議將所有Maven專案設為一個父級反應棧專案的子項。 此Reactor專案有兩個用途：如果需要，可一起建置和部署所有專案，並包含所有子專案的相依性宣告。 父專案會定義相依性及其版本，而子專案只會宣告所需的相依性，從父專案繼承版本。

在此案例中，如果專案B的團隊需要foo 1.1版中的功能，在開發環境中，此變更將很快中斷專案A。此時，團隊可討論此變更，並使專案A與新版本相容，或尋找專案B的替代解決方案。

請注意，這不會免除這些團隊共用此相依性的需求，只會快速及早地強調問題，讓團隊可以討論任何風險並同意解決方案。

防止程式碼重複 preventing-code-duplication-nbsp-br

處理多個專案時，請務必確保程式碼不會重複。 程式碼重複會增加發生瑕疵的可能性、系統變更的成本，以及程式碼庫中的整體硬度。 若要避免重複，請將通用邏輯重構為可重複使用的程式庫，以便用於多個專案。

為了滿足此需求，我們建議開發和維護所有團隊都可以依賴並參與的核心專案。 進行此操作時，請務必確保此核心專案不取決於任何個別團隊的專案；這允許獨立部署，同時仍可促進程式碼重複使用。

核心模組中常見的一些程式碼範例包括：

模組化專案架構

這並不排除多個團隊依賴並可能更新同一組計畫碼的需求。 透過建立核心專案，我們減少了團隊之間共用的程式碼庫大小，減少了但不消除共用資源的需求。

為確保對此核心套件進行的變更不會中斷系統的功能，我們建議由資深開發人員或開發人員團隊維持監督。 一個選項是讓單一團隊管理此封裝的所有變更；另一個選項是讓團隊提交由這些資源審查和合併的提取請求。 重要的是，治理模型要由團隊設計和同意，並且開發人員要遵循它。

管理部署範圍 managing-deployment-scope

不同團隊將計畫碼部署到相同的存放庫時，請務必不要覆寫彼此的變更。 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

覆蓋 overlays

覆蓋常用來擴充或取代現成的AEM功能，但使用覆蓋會影響整個AEM應用程式（亦即，所有租使用者都可使用任何覆蓋功能變更）。 如果租戶對覆蓋有不同的要求，這會更複雜。 理想情況下，業務群組應該共同合作，以便就AEM管理主控台的功能和外觀達成一致。

如果不同業務單位之間無法達成共識，可能的解決方案是不要使用覆蓋。 請改為建立功能的自訂副本，並透過每個租使用者的不同路徑將其公開。 這可讓每個租使用者獲得完全不同的使用者體驗，但此方法也會增加實作和後續升級工作的成本。

工作流程啟動器 workflow-launchers

在存放庫中完成指定的變更時，AEM會使用工作流程啟動器自動觸發工作流程執行。 AEM提供數個現成的啟動器，例如用來對新的和更新的資產執行轉譯產生和中繼資料擷取程式。 雖然這些啟動器可以保持原樣，但在多租使用者環境中，如果租使用者具有不同的啟動器及/或工作流程模型需求，則可能需要為每個租使用者建立和維護個別啟動器。 這些啟動器必須設定為在使用者更新上執行，同時保留其他使用者的內容不變。 將啟動器套用至租使用者專用的指定存放庫路徑即可輕鬆完成此操作。

虛名 URL vanity-urls

AEM提供虛名URL功能，可依每個頁面設定。 在多租使用者情況下，此方法的問題是AEM無法確保以這種方式設定的虛名URL之間的唯一性。 如果兩個不同的使用者為不同的頁面設定相同的虛名路徑，可能會遇到未預期的行為。 因此，我們建議在Apache Dispatcher執行個體中使用mod_rewrite規則，這會允許中央設定點與僅限出站的資源解析器規則一致。

元件群組 component-groups

為多個編寫群組開發元件和範本時，請務必有效使用componentGroup和allowedPaths屬性。 透過有效地搭配網站設計利用這些功能，我們可以確保品牌A的作者只會看到為其網站建立的元件和範本，而品牌B的作者只會看到其元件和範本。

測試 testing

雖然良好的架構和開放的通訊通道有助於防止網站上的非預期區域引進缺陷，但這些方法並非萬無一失。 因此，在將任何內容發佈到生產環境之前，請務必充分測試平台上正在部署的內容。 這要求團隊在發佈週期中進行協調，並且更加需要一套自動化測試，儘可能涵蓋更多功能。 此外，由於一個系統由多個團隊共用，因此效能、安全性和負載測試變得前所未有的重要。

操作考量 operational-considerations

共用資源 shared-resources

AEM在單一JVM中執行；任何部署的AEM應用程式除了在正常執行AEM時已消耗的資源之外，本身也會彼此共用資源。 在JVM空間本身中，沒有執行緒的邏輯分離，AEM可用的有限資源（例如記憶體、CPU和磁碟I/O）也會共用。 任何佔用資源的租使用者都會不可避免地影響其他系統租使用者。

效能 performance

如果不遵循AEM最佳實務，開發使用超出正常範圍之資源的應用程式是可能的。 這類範例會觸發許多繁重的工作流程操作（例如DAM更新資產）、透過許多節點使用MSM推播修改操作，或使用昂貴的JCR查詢來即時呈現內容。 這些不可避免地會對其他租使用者應用程式的效能造成影響。

記錄 logging

AEM提供現成的介面，用於健全的記錄器設定，這有助於我們在共用開發情境中進行優勢。 透過為每個品牌指定個別的記錄器（依封裝名稱），我們可達到一定程度的記錄分離。 雖然系統範圍作業（例如復寫和驗證）仍會記錄到中央位置，但非共用的自訂程式碼可個別記錄，讓每個品牌的技術團隊更容易進行監控和偵錯。

備份和還原 backup-and-restore

由於JCR存放庫的性質，傳統備份會在整個存放庫中使用，而不是在個別內容路徑中使用。 因此，不可能根據租使用者來輕鬆區分備份。 相反地，從備份還原將會復原系統上所有租使用者的內容和存放庫節點。 雖然您可以使用VLT等工具執行目標內容備份，或是選擇在個別環境中建置套件來還原內容，但是
方法不容易包含組態設定或應用程式邏輯，而且管理起來可能很麻煩。

安全性考量 security-considerations

ACL acls

當然，您可以使用存取控制清單(ACL)來控制誰有權根據內容路徑檢視、建立和刪除內容，這需要建立和管理使用者群組。 維護ACL和群組的困難取決於強調確保每個租使用者對其他人的瞭解為零，以及部署的應用程式是否依賴共用資源。 為了確保ACL、使用者和群組管理的高效率，我們建議建立一個具有必要監督的集中式群組，以確保這些存取控制項和主體以提升效率和安全性的方式重疊（或不重疊）。