AEM as a Cloud Service的企業開發團隊設定 enterprise-setup

瞭解如何設定和擴展您的企業開發團隊，並瞭解AEM (Adobe Experience Manager) as a Cloud Service如何支援您的開發流程。

簡介 introduction

為了支援具有企業開發設定的客戶，AEM as a Cloud Service 與 Cloud Manager 及其專門建置的教條式 CI/CD 管道完全整合。 這些管道和服務根據最佳實務建置，以確保整體的測試和最高的程式碼品質。

Cloud Manager在企業團隊開發設定中的支援 cloud-manager

為確保快速入門，Cloud Manager提供開始開發數位體驗所需的一切，包括儲存自訂內容的Git存放庫。 Cloud Manager會建置、驗證及部署這些自訂專案。

使用Cloud Manager，開發團隊可以經常提交變更，而不需要Adobe員工的協助。

Cloud Manager 中提供了三種類型的環境。

可以使用非生產管道將程式碼部署到開發環境。 測試和生產環境總是一起執行，從而確保在生產部署之前進行驗證作為最佳實務，生產管道使用品質門檻來驗證應用計劃程式碼和設定變更。

生產管道會先將程式碼和設定部署到測試環境、測試應用計劃，最後部署到生產環境。

Cloud Service SDK一律使用最新的AEM as a Cloud Service改良功能進行更新，允許直接使用開發人員的本機硬體進行本機開發。 此方法可加快開發速度，縮短前置時間。 因此，開發人員可以留在他們熟悉的本機環境中，並從各種開發工具中進行選擇，以在他們認為合適的時候推動開發環境或生產。

Cloud Manager支援靈活的多團隊設定，可以根據企業的需求進行調整。 為了確保跨多個團隊的穩定部署，Cloud Manager教條式管道一起驗證和測試來自所有團隊的計畫碼。 此方法有助於防止一個團隊的變更影響所有團隊的生產情況。

範例情境 example-scenario

每個企業都有不同的需求，包括不同的團隊設定、流程和開發工作流程。 Adobe將下述設定用於在AEM as a Cloud Service之上提供體驗的多個專案。

例如，Adobe Creative Cloud應用程式（例如Adobe Photoshop或Adobe Illustrator）包含教學課程、範例和指南等內容資源。 使用者端應用程式會以Headless方式使用AEM as a Cloud Service的內容。 他們對AEM雲端發佈層進行API呼叫，以將結構化內容擷取為JSON資料流。 此外，AEM as a Cloud Service🔗中的內容傳遞網路(CDN)是用來以最佳效能提供結構化和非結構化內容。

為本專案貢獻內容的團隊應遵循以下流程。

每個團隊都使用自己的開發工作流程，並擁有單獨的Git存放庫。 額外的共用Git存放庫用於入門專案。 此Git存放庫包含Cloud Manager的Git存放庫的根結構，包括共用的Dispatcher設定。

加入新專案需要在共用Git存放庫根目錄下的反應器Maven專案檔案中列出。 針對Dispatcher設定，會在Dispatcher專案中建立新的設定檔案。 主要Dispatcher設定接著會包含此檔案。 每個團隊負責自己的Dispatcher設定檔。 共用Git存放庫很少發生變更，只有在新專案上線時才需要變更。 每個專案團隊都會在自己的Git存放庫中執行主要工作。

每個團隊的Git存放庫都是使用AEM專案原型設定的，因此遵循設定AEM專案的最佳實務。 唯一的例外是Dispatcher設定，此設定是在共用Git存放庫中完成，如上所述。

每個團隊都會使用簡化的Git工作流程，其中包含兩個+ N分支，遵循Git流程模型：

開發是在功能分支中完成的。 當功能成熟時，它會合併到開發分支中。 從開發分支中挑選完成和驗證的功能並合併到穩定分支中。

所有變更均透過PR （提取請求）完成。 品質門檻會自動驗證每個PR。 Sonar 用於對程式碼進行品質檢查，並執行一組測試套件以確保新程式碼不會引入任何迴歸。

Cloud Manager的Git存放庫中的設定有兩個分支。

在開發或穩定分支中，每次推送到團隊的Git存放庫都會觸發GitHub動作。

所有專案都遵循相同的穩定分支設定。 推送到專案的穩定分支會自動推送到Cloud Manager的Git存放庫中的穩定分支。 推送至穩定分支會觸發Cloud Manager中的生產管道。 任何團隊每次推送到穩定分支都會觸發生產管道。 如果所有品質門檻都通過，生產部署則會更新。

推送到開發分支的處理方式不同。 推送到團隊Git存放庫中的開發分支也會觸發GitHub動作。 這個動作會自動將程式碼推送到Cloud Manager的Git存放庫中的開發分支。 不過，此程式碼推送不會自動觸發非生產管道。 對Cloud Manager的API的呼叫會觸發它。

執行生產管道包括透過提供的品質門檻檢查所有團隊的程式碼。 將程式碼部署到階段後，就會執行測試和稽核，讓一切都如預期般運作。 透過了所有門檻後，這些變更就會在沒有任何中斷或停機的情況下推廣到生產環境。

對於本機開發，使用適用於 AEM as a Cloud Service的 SDK。 SDK可設定本機作者、發佈和Dispatcher。 此工作流程可啟用離線開發和縮短前置時間。 有時只使用作者環境進行開發，但快速設定Dispatcher和發佈環境允許在推送至Git存放庫之前在本機測試所有內容。

每個團隊的成員通常會從共用的Git中籤出程式碼，以供他們自己的專案程式碼使用。 不需要簽出其他專案，因為這些專案是獨立的。

此設定可作為參考，然後根據企業的需求進行自訂。 Git靈活的分支和合併概念能容許上述工作流程的變化，並根據每個團隊的需求進行自訂。 AEM as a Cloud Service 支援這些變化，而不會犧牲教條式 Cloud Manager 管道的核心價值。

多團隊設定的考量事項 considerations

有了Cloud Manager的Git存放庫和生產管道，完整的生產計畫碼一律會通過所有品質門檻，並將其視為一個部署單位。 如此一來，生產系統就始終可供使用，而不會中斷或停機。

相反地，如果沒有這樣的系統，因為每個團隊都可以單獨部署，所以單一團隊的更新可能會導致生產穩定性問題。 此外，它需要協調和規劃停機時間來推出更新。 隨著團隊數量增加，協調工作將變得更加複雜且很快會變得難以管理。

如果在品質門檻中偵測到問題，則生產不受影響，並且可以偵測和修復問題，而無需Adobe人員介入。 如果沒有AEM as a Cloud Service且沒有總是測試整個部署，部分部署可能會導致中斷，需要請求復原甚至從備份中完全還原。 部分測試也可能造成其他問題，必須於稍後解決，同樣需要Adobe員工的協調和支援。