將 Azure Resource Manager 範本的管理模組化（ARM 範本）可讓您減少重複、建立基礎結構開發中的最佳做法模型，並具有一致的標準部署。
實作這種模組化的範例使用案例是使用 T 恤大小的隱喻來部署虛擬機 （VM）。 假設您已部署數十或數百部 VM。 這些部署會使用 1.0.0 版的範本，並具有較舊系列的標準 中型 大小。 如果您只是部署新的範本，轉換至新的系列可能需要短暫的服務中斷。 不過，藉由建置 1.5.0 版並使用模組化，您可以使用更新的標準來部署新的基礎結構，同時讓舊基礎結構保持可部署的狀態。 藉由提供舊版的基礎結構，您的產品和應用程式小組有已知的良好設定，可在有時間升級至新版本時依賴。
存放庫的分層蛋糕：企業範例
當談到為什麼您可能想要對範本的所在位置、更新方式等有強烈偏好時，有兩個主要考慮： 分支 和 內部服務。
分支。 此範例案例可協助支援 Gitflow 和 GitHub 流程的 Git 分支模型。 如需 Gitflow 的詳細資訊，請參閱 使用 git-flow 將 Git 分支工作流程自動化，這是 Jeff Kreeftmeijer 的部落格文章。 如需 GitHub 流程的詳細資訊，請參閱 GitHub 檔中的 GitHub 流程 。
內部服務。 第二個是 內部環境，將開放原始碼軟體開發的共同作業做法帶入內部開發。 在這類案例中，您可以更自信地共用不同的範本和模組原始程式碼，而不需要擔心部署模型本身的許可權。 如需內部來源開發的詳細資訊，請參閱 GitHub 上的 innersource 簡介。
Bicep 是部署 Azure 資源的宣告式語言。 Bicep 的可重複使用程式碼可以使用 Azure Container Registry 作為私人登錄，以裝載已建立版本的 ARM 範本。 如此一來，您的企業就可以針對基礎結構擁有持續整合和持續傳遞 （CI/CD） 的程式。 您可以在 CI 程式中執行整合和單元測試，而容器登錄可以在成功建置模組之後接收模組。 應用程式小組可以繼續使用舊版，直到他們準備好升級，或者可以更新以利用較新版本範本中的功能。
除了使用 Container Registry 之外，您還可以將此模型與類似 Azure 已驗證模組的內容結合。 您的實作可能會從公用登錄取用，或者最好是監視公用存放庫，並將變更提取到您的私人登錄，以供進一步使用。 將變更提取到您自己的容器登錄可讓您對公用模組執行測試，同時確保它們不會用於生產環境，直到納入品質和安全性做法為止。
圖層
此範例案例中建議的模型是堆疊的模型。 更接近堆疊頂端的圖層具有更頻繁的部署和部署，這些部署更定製。 Bicep 程式代碼提供一致的部署。 開發小組會參與其貢獻，從下列各層中提供的服務和基礎結構進行建置。 較低層中沒有任何項目應該依賴上述圖層中的資源。 從第 0 層到第 3 層是全域連結庫、全球基礎結構（全球共用服務）、產品平臺（共用服務）和應用程式。
此模型會 建立具有對齊方式的自主權，這表示具有：
企業簡易的常見工具。 例如，每個人都使用 git 進行原始檔控制，而每個人都使用 GITHub Actions 進行 CI/CD。 然而，我們不過度過分。 例如，我們不強制所有小組都使用 Bicep;他們可以使用 Terraform、ARM 範本和其他工具。
共用最佳做法的能力。 它們可以採用ARM範本、黃金映像或代碼段的形式。 最佳做法也可以是特定技術的檔。 例如，如何在環境中輪替密鑰，以及如何測試程序代碼。
有些服務會在堆疊中向下移動。 例如，應用程式小組一開始可能會開發用來部署 Kubernetes 叢集的範本，而 Kubernetes 叢集稍後會以共用服務的形式提取至產品平臺。 此範本會變得如此實用，因此會提取至範例連結庫。
第 0 層 - 全域連結庫
最底層是 全域連結庫，這是未部署到生產環境的實用潮汐存放庫。 從訪問控制的觀點來看，應該將讀取存取權提供給要求它的公司任何人。 針對變更、建議等等，您的雲端卓越中心 （CCoE） 會核准PR並管理待辦專案，就好像這是任何其他產品一樣。
第 0 層不應包含：
- 部署在生產環境的範本。
- 秘密或環境特定組態。
第 0 層應 包含：
- 代碼段 （在 Python、C# 等中）。
- Azure 原則 範例。
- 可以做為範例的 ARM 範本、Bicep 範本或 Terraform 檔案。
其中一個範例是一個範例架構，說明貴公司如何針對三層式應用程式撰寫部署，而不需要任何環境特定資訊。 此範例架構可能包括標籤、網路、網路安全組等等。 排除環境的特定資訊很有用，因為並非所有專案都可以或需要放入模組中。 嘗試這樣做可能會導致過度參數化。
此外，第 0 層可以連結到其他已知的良好範例程式代碼來源，例如 Terraform 登錄或 Azure 資源模組。 如果您的組織採用上述任一來源的程式代碼或模式，建議您將程式代碼或模式提取到您自己的第0層，而不是直接從公用來源提取。 藉由依賴第 0 層，您可以撰寫自己的測試、調整和安全性設定。 藉由不依賴公用來源，您可以降低依賴可能意外刪除之項目的風險。
若要被視為良好的範例程式代碼，您的範本和模組應該遵循良好的開發做法，包括安全性和組織需求的輸入驗證。 若要維持此層級的嚴謹性，您應該將原則新增至主要分支，以要求提取要求 （PR） 和程式碼檢閱，以取得建議的變更，如果合併，會導致變更流向主要容器登錄。
第 0 層會饋送至 Azure Pipelines 或 GitHub Actions，以在 Azure Container Registry 中自動建立已建立版本的成品。 您可以建置 Git 認可訊息的自動化，以實 作成品的語意版本控制 。 若要正確運作，您必須有具決定性的命名標準，例如 <service.bicep>，讓自動化在一段時間內保持可維護。 使用適當的分支原則，您也可以將整合測試新增為程式代碼檢閱的必要條件。 您可以使用 Pester 之類的工具來檢測此專案。
有了這類原則和保護，容器登錄可以是企業中所有已準備好使用之基礎結構模組的真相來源。 您應該考慮標準化變更記錄，以及可用程式碼範例的索引，以允許此程式碼的可探索性。 未知的程式代碼是未使用的程序代碼！
第 1 層 - 全域基礎結構：全球共用服務
第 1 層是 Azure 登陸區域建構的存放庫。 雖然Microsoft提供範本來部署 Azure 登陸區域，但您會想要修改特定元件並提供參數檔案。 這類似於您將公用登錄和模組存放庫提取到第0層的方式，如先前所述。
Azure Container Registry 是此架構的重要部分。 即使您的公司沒有使用容器的計劃，您也必須部署 Container Registry，才能成功建立 Bicep 範本的版本設定。 Container Registry 可讓您的模組具有顯著的彈性和重複使用性，同時提供企業級的安全性和訪問控制。
第 1 層應包含：
- 在管理群組或訂用帳戶層級套用的原則指派和定義。 這些原則應符合您的公司治理需求。
- 核心網路基礎結構的範本，例如 ExpressRoute、VPN、虛擬 WAN 和虛擬網路（共用或中樞）。
- DNS。
- 核心監視（記錄分析）。
- 企業容器登錄。
您應該設定分支保護，以限制將變更推送至此存放庫的能力。 將其他開發人員的PR核准限制為 CCoE 或雲端治理的成員。 此層的參與者主要是與此層元件有歷史關聯之群組的成員。 例如，網路小組會建置網路的範本、作業小組設定監視等等。 不過，您應該將只讀存取權授與要求它的個人，因為您想要讓其他群組的開發人員建議對核心基礎結構所做的變更。 它們可能會提供改善，但您無法在未經核准和測試的情況下合併變更。
這些檔案應該會針對標準元件取用容器登錄中的模組。 不過，您也會有 Bicep 檔案或一系列的 Bicep 檔案，這些檔案是針對您企業的 Azure 登陸區域實作或類似的治理結構所自定義。
第 2 層 - 產品平臺：共用服務
您可以將第 2 層產品平臺視為特定產品線或業務單位的共用服務。 這些元件並非整個組織通用，但意在符合特定商務需求。 對於與第 1 層全域基礎結構中樞對等互連的虛擬網路而言，這會是適當的層。 金鑰保存庫是此層的另一個範例元件。 金鑰保存庫可以將共用密碼儲存到記憶體帳戶或此平臺內不同應用程式共用的資料庫。
第 2 層應包含：
- 在訂用帳戶或資源群組套用的原則指派，以符合產品特定需求。
- 密鑰保存庫、記錄分析、SQL 資料庫的 ARM 範本（如果產品內的各種應用程式使用資料庫），以及 Azure Kubernetes Service。
您應該實作許可權，以限制將變更推送至此存放庫的能力。 如同其他層，您應該使用分支保護來確保產品潛在客戶或擁有者可以核准來自其他開發人員的 PR。 產品平臺的讀取許可權沒有任何固定規則，但至少應將來自任何應用程式小組的開發人員授與讀取許可權，才能建議變更。 由於第 2 層可能包含一些專屬架構或類似的資訊，因此您可以選擇限制組織中使用平台的人員存取權。 不過，如果是這種情況，您會想要確保建置從此存放庫收集良好作法和代碼段的程式，以便與全域連結庫第0層共用。
第 3 層 - 應用程式
應用層第 3 層包含建置在產品平臺之上的元件。 這些元件會提供商務要求的功能。 例如，針對串流平臺，一個應用程式可以提供搜尋功能，而不同的應用程式則提供建議。
第 3 層應包含：
- C#、Python 等中的應用程式程序代碼。
- 個別元件的基礎結構（也就是只用於此應用程式）：函式、Azure 容器執行個體、事件中樞。
許可權會受到限制，以便將變更推送至此存放庫。 您應該使用分支保護，讓此應用程式的小組成員核准另一個小組成員所建立的PR。 不應允許小組成員核准自己的變更。 由於此層可能包含專屬的架構、商業規則或類似資訊，因此您可以選擇限制組織內建置此應用程式的存取權。 不過，如果是這種情況，您也應該建立從這一層收集良好作法和代碼段的程式，以與全域連結庫第0層共用。
各層的共通性
雖然本文說明每個圖層的一些特定詳細數據，但您一定要考慮的所有圖層也有一些品質。
基礎結構的運作方式應該如同是應用程式一樣。 這表示您應該有持續整合 （CI） 程式，其中新功能會完整測試，並搭配單元測試、煙霧測試和整合測試。 您應該只合併將這些測試傳遞至主要發行分支的程式代碼。
您也應該確定您已具備分支原則，以防止個人規避程式，即使是為了快速。 如果您的 CI 程式被視為障礙，這表示您已產生必須處理的技術債務。 這並不表示您需要移除原則和保護。
最後，雖然您可能沒有所有存放庫的索引及其內的程序代碼，但您的組織應該開發一個程式，讓個人要求存取存放庫。 某些規則可能會完全自動化。 例如，您可以實作一項規則，以授與讀取存取權，而不需檢閱，該規則會授與產品下任何應用程式的產品小組參與者。 這類規則通常可以使用您環境中的群組型成員資格和群組型角色指派來實作。 設定這類存取應該有助於促進內部來源和組織知識。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Tim Sullivan |資深技術專家
其他投稿人：
- Gary Moore | 程式設計師/作家
下一步
- 設計區域：平臺自動化和DevOps
- 成熟的小組結構
- 什麼是基礎結構即程序代碼？
- Azure/ResourceModules：此存放庫包含 CI 平臺，適用於成熟且策劃的 Bicep 模組集合。 此平台同時支援 Azure Resource Manager 和 Bicep，而且您可以搭配 GitHub 動作和 Azure Pipelines 使用其功能。
- 建立 Bicep 模組的私人登錄