Automation
在軟體定義的雲端基礎結構中，小組會使用各種工具和技術來布建、設定和管理基礎結構。 隨著小組的發展和成長，他們可以從使用入口網站轉換，以及使用程式代碼和自動化來布建、設定及管理基礎結構和服務。
平臺自動化考慮
- 實作所有專案即程序代碼 （EaC） 方法可讓小組解除鎖定重要優點、建立強大的開發文化，並讓每個小組中的每個人都能夠檢查部署資源的方式和方式。 EaC 也可協助平臺小組採用可改善其靈活度和效率的重要開發做法。 您的小組可以追蹤變更，並控制哪些變更會移至生產環境，方法是將程式代碼儲存在存放庫中，並使用版本控制系統來管理它。
- Teams 可以遵循 4 眼睛原則 ，並使用 對等程式設計 或 對等檢閱 來確保永遠不會單獨進行程式碼變更。 對等程式設計與對等檢閱可改善程式代碼品質、讓小組共同負責變更，以及增加小組對所同意和部署內容的知識。 程式代碼檢閱是小組成員學習編碼和自動化的新技術和方法的絕佳方式。
- Teams 應該使用 Git 之類的版本控制系統，以及 Git 存放庫，以強制執行對等檢閱。 Git 存放庫可讓您的小組定義重要的分支，並使用分支原則加以保護。 您可以使用原則來要求這些分支上的程式碼變更，以符合特定準則，例如最少數量的小組成員核准，才能合併至受保護的分支。
- Teams 應將 EaC 方法和變更檢閱程式與持續整合和持續傳遞 （CI/CD） 程式連接在一起。 每個程式代碼變更都應該自動觸發 CI 程式，以執行靜態程式代碼分析、驗證和測試部署。 CI 可確保開發人員儘早檢查其程式代碼（通常稱為 快速 或 左移測試失敗）是否有可能導致未來問題的錯誤。 視 小組所使用的分支策略 而定，任何重要分支的變更都應該觸發部署到不同的 環境。 一旦核准變更並合併至
main，CD 程式會將這些變更部署到生產環境。 此程式代碼管理系統會為您的小組提供每個環境中執行之專案的單一 事實 來源。 - 為了確保您的平臺完全自我修復，併為工作負載小組提供自助，您的平臺小組必須致力於將布建、設定和平臺管理到工作負載小組登陸區域訂用帳戶布建的所有專案自動化（通常稱為 「極端自動化」。 極端自動化可讓您的平臺小組專注於提供價值，而不是部署、設定和管理您的平臺。 極端自動化也會建立自我增強週期，讓您的小組有更多時間建置更多自動化。
- 隨著您的平臺小組自動化作業活動並減少人為介入，他們應該將其焦點轉移到重要工作，以啟用和加速 Azure 上的工作負載小組創新。 為了達成此目的，您的平臺小組必須逐一查看多個週期的建置和開發，因為它們會放置平臺的工具、腳本和功能增強功能。
- 有多個選項可協助您的小組開始使用其 Azure 登陸區域部署。 這些選項取決於目前的小組功能，而且隨著小組的發展而成長。 更具體來說，針對 平臺部署，您可以根據個別 Teams 的 IaC 熟練程度和工具喜好設定，選擇入口網站、Bicep 或 Terraform 型體驗。
- 仍在瞭解 基礎結構即程序代碼 （IaC） 且更熟悉使用入口網站部署和管理資源的全新和新興平臺小組，可以使用 Azure 登陸區域加速器 來啟動，這可支援仍在使用 ClickOps 方法的團隊。 ClickOps 是透過按兩下入口網站、管理主控台和精靈來布建、設定和管理資源的程式。 此加速器可讓您的團隊使用入口網站作為初始部署工具，並隨著平臺工程成熟度成長而逐漸成長，進一步使用 Azure CLI、PowerShell 或 IaC。
- AzOps 解決方案可讓小組從 ClickOps 驅動到支援 DevOps 的平臺自動化和管理做法。 您的小組可以從使用其個人帳戶存取權轉換至使用僅依賴 CI/CD 與 AzOps 和 IaC 的 DevOps 原則和做法。 AzOps 可讓您的小組自備架構、使用 Azure 登陸區域入口網站加速器所部署的架構（在初始入口網站型部署之後，因為 AzOps 整合不屬於 ALZ 入口網站體驗的一部分）、與棕色地帶部署整合，或使用自定義範本 （Bicep 或 ARM） 來建置及運作您的平臺。
- 具有已建立技能和功能的平臺小組可以採用遵循DevOps原則和做法的編纂方法。 您的小組應該以 IaC 和新式開發實務為基礎，從在其個人帳戶上使用 Azure 存取權，以及透過 CI/CD 管線執行所有作業。 您的小組應該使用以 IaC 為基礎的加速器，例如 ALZ-Bicep 或 Azure 登陸區域 Terraform 模組 來加速此轉換。
- 以 IaC 為基礎的加速器具有有限的管理範圍。 新版本提供更多功能和更高的資源管理功能。 如果使用加速器，您的小組應該考慮以加速器開頭的分層方法，然後新增一層自動化。 自動化層提供小組所需的功能，以便使用舊版應用程式的域控制器部署等平臺功能，完全支援工作負載小組。
- 當平臺小組轉換至 DevOps 方法時，他們需要建立處理緊急修正的程式。 他們可以使用 Privileged Identity Management （PIM） 合格許可權來要求存取以執行修正，稍後將它帶回程式代碼來限制設定漂移，也可以使用程式代碼來實作快速修正。 您的小組應該一律在其待辦項目中註冊快速修正，以便稍後重新處理每個修正程式，並限制其技術債務。 技術債務過多會導致未來的減速，因為某些平臺程式代碼並未完整檢閱，且不符合小組程式代碼撰寫指導方針和原則。
- 您可以使用 Azure 原則 將一些自動化新增至您的平臺。 請考慮使用 IaC 來部署和管理 Azure 原則，通常稱為「原則即程式代碼」（PaC）。 這些原則可讓您將記錄收集之類的活動自動化。 許多PaC架構也會實作豁免程式，因此請規劃工作負載小組要求豁免原則。
- 當小組嘗試部署不符合安全性控制的資源時，請使用「原則驅動治理」向工作負載小組發出訊號。 請考慮針對這些情況部署
deny原則，這可讓您的工作負載小組也將 [所有專案] 視為程序代碼，並避免程序代碼宣告一件事且原則在部署時間變更設定的設定漂移。 避免使用modify效果，例如工作負載小組部署在其程式代碼中定義的記憶體帳戶supportOnlyHttpsTraffic = false，其中modify原則會在部署時間變更為true，使其符合規範。 這會導致程式代碼偏離所部署的內容。
平臺自動化設計建議
- 遵循所有專案即程序代碼方法，以取得 Azure 平臺、檔、部署和測試程式的完整透明度和組態控制。
- 使用 版本控制 來管理您的所有程式代碼存放庫，包括：
- 基礎結構即程式碼
- 原則即程序代碼
- 設定即程式碼
- 部署即程序代碼
- 檔即程序代碼
- 實作 4 眼睛原則和對等程式設計或對等檢閱的程式，以確保您的小組會在部署至生產環境之前先檢閱所有程式代碼變更。
- 為您的小組採用分支策略，併為您想要保護的分支設定分支原則。 使用分支原則時，小組必須使用 提取要求 來進行合併變更。
- 使用 持續整合和持續傳遞 （CI/CD） 將程式代碼測試和部署自動化到不同的環境。
- 工作可將 所有專案自動化，例如平臺的布建、設定和管理，以及為您的工作負載小組布建登陸區域訂用帳戶。
- 使用其中一個符合小組功能的可用加速器，開始部署 Azure 登陸區域。
- 規劃使用分層部署方法來新增加速器未涵蓋但需要完全支援工作負載小組的功能。
- 建立程式，以使用程式代碼來實作快速修正。 請務必在小組待辦項目中註冊快速修正，以便稍後可重新處理每個修正程式，而且您可以限制技術債務。
- 使用 基礎結構即程式代碼 來部署和管理 Azure 原則 （通常稱為原則即程式碼）
- 實作原則的豁免程式。 規劃工作負載小組要求原則豁免，並準備好在需要時解除封鎖小組。
- 當工作負載小組嘗試部署不符合安全性控制的資源時，請使用「原則驅動治理」來封鎖工作負載小組。 這有助於減少組態漂移，其中程式代碼宣告的狀態與最終部署的狀態不同。