Azure 登陸區域的測試驅動開發
測試驅動開發 (TDD) 是軟體發展和 DevOps 程式，可改善程式碼型解決方案的新功能品質與改善。 TDD 會在開發實際程式碼之前建立單元測試案例，並針對測試案例測試程式碼。 這種方法不是先開發程式碼，稍後再建立測試案例。
登陸區域是裝載透過程式碼預先布建工作負載的環境。 登陸區域包含使用一組已定義雲端服務和最佳做法的基礎功能。 本文說明使用 TDD 部署成功登陸區域的方法，同時符合品質、安全性、作業和治理需求。
雲端基礎結構是程式碼執行的輸出。 結構完善、經過測試且經過驗證的程式碼會產生可行的登陸區域。 雲端式基礎結構及其基礎原始程式碼可以使用此方法，以確保登陸區域具有高品質且符合核心需求。
使用此方法在早期開發期間符合簡單的功能要求。 稍後在雲端採用生命週期中，您可以使用此程式來符合安全性、作業、治理或合規性需求。 此程式特別適用于以平行開發工作開發和重構登陸區域。
測試驅動開發週期
下圖顯示 Azure 登陸區域的測試驅動開發週期：
建立測試。 定義測試，以驗證已符合功能的接受準則。 在您開發時自動執行測試，以減少手動測試投入量，特別是針對企業級部署。
測試登陸區域。 執行新的測試和任何現有的測試。 如果雲端提供者的供應專案未包含必要的功能，且先前的開發工作尚未提供，測試應該會失敗。 執行現有的測試有助於驗證您的新功能或測試不會降低現有登陸區域功能的可靠性。
展開並重構登陸區域。 新增或修改原始程式碼以滿足所要求的值新增功能，並改善程式碼基底的一般品質。
為了符合 TDD 準則，雲端平臺小組只會新增程式碼以符合要求的功能。 不過，程式碼品質和維護是共同的工作。 當它們滿足新功能要求時，雲端平臺小組應該藉由移除重複專案並厘清程式碼，嘗試改善程式碼。 強烈建議在新的程式碼建立和重構原始程式碼之間執行測試。
部署登陸區域。 原始程式碼完成功能要求之後，請在受控制的測試或沙箱環境中，將修改過的登陸區域部署到雲端提供者。
測試登陸區域。 重新測試登陸區域，以驗證新程式碼是否符合所要求功能的接受準則。 一旦通過所有測試，功能就會被視為完成，且會被視為符合接受準則。
TDD 迴圈會重複上述基本步驟，直到符合 完成的完整定義為止。 當所有加值功能和驗收準則都通過其相關聯的測試時，登陸區域便已準備好支援雲端採用計劃的下一波。
讓 TDD 生效的迴圈通常稱為 紅色/綠色測試。 在這種方法中，雲端平臺小組會根據完成的定義和定義的接受準則，從失敗的測試或紅色測試開始。 針對每個功能或接受準則，雲端平臺小組會完成開發工作，直到測試通過，或具有綠色測試為止。
TDD 的目標是要解決更好的設計，而不是建立一套測試。 測試是完成程式的重要成品。
對完成的定義
成功可以是一種主體量值，可在登陸區域開發或重構期間提供雲端平臺小組少量可採取動作的資訊。 缺乏明確性可能會導致雲端環境中遺漏的期望和弱點。 在雲端平臺小組重新執行或擴充任何登陸區域之前，他們應該要清楚瞭解每個登陸區域已完成 (DoD) 的定義 。
DoD 是雲端平臺小組與其他受影響的小組之間的簡單協定，可定義預期新增價值的功能，以納入登陸區域開發工作。 DoD 通常是符合短期雲端採用計畫的檢查清單。
當小組採用更多工作負載和雲端功能時，DoD 和接受準則會變得更複雜。 在成熟程式中，預期的特徵各自有自己的接受準則，以提供更清楚的。 當加值功能全都符合接受準則時，登陸區域已足夠設定，以啟用目前採用波段或發行的成功。
簡單 DoD 範例
為了進行初始移轉工作，DoD 可能過於簡單。 下列範例是簡單的 DoD：
初始登陸區域會裝載 10 個工作負載以供初始學習之用。 這些工作負載對企業並不重要，而且無法存取敏感性資料。 未來，這些工作負載可能會發行至生產環境，但重要性和敏感度不會變更。
為了支援這些工作負載，雲端採用小組必須符合下列準則：
- 網路分割以配合建議的網路設計。 此環境應該是具有公用網際網路存取權的周邊網路。
- 存取計算、儲存和網路資源，以裝載與數位資產探索一致的工作負載。
- 命名和標記結構描述以方便使用。
- 在採用期間，雲端採用小組的暫時存取權會變更服務組態。
- 在生產版本之前，請與公司身分識別提供者整合，以控管進行中的身分識別和作業管理的存取權。 此時，應撤銷雲端採用小組的存取權。
最後一個點不是特徵或接受準則，但需要更多擴充的指標，而且應該提早與其他小組一起探索。
更複雜的 DoD 範例
雲端採用架構中的控管方法，提供了一段敘述性旅程，讓您了解治理小組的自然成熟度。 內嵌在該旅程中是 DoD 和接受準則的數個範例，格式為原則聲明。
初始原則語句。 根據治理早期採用需求的公司原則，初始 DoD 的範例。
擴充身分識別管理的累加式改善。 控管 DoD 以符合登陸區域的身分識別管理需求的公司原則範例。
擴充安全性需求的累加改善。 控管 DoD 以符合符合參考雲端採用計畫之安全性需求的公司原則範例。
擴充作業管理的累加改善。 管理 DoD 以符合基本作業管理需求的公司原則範例。
擴充成本管理的累加改善。 管理 DoD 以符合成本管理需求的公司原則範例。
上述範例是基本範例，可協助您開發登陸區域的 DoD。 您可以取得 雲端治理五個專業領域的範例原則。
支援登陸區域 TDD 的 Azure 工具和功能
下圖顯示 Azure 中可用的測試驅動開發工具：
您可以輕鬆地將這些 Azure 工具和功能整合到 TDD 中，以建立登陸區域。 這些工具會提供特定用途，讓您更輕鬆地開發、測試及部署登陸區域，以符合 TDD 週期。
Azure Resource Manager為建置和部署程式提供一致的平臺。 Resource Manager平臺可以根據原始程式碼定義來部署登陸區域。
Azure Resource Manager (ARM) 範本提供 Azure 中部署環境的主要原始程式碼。 Terraform 之類的某些協力廠商工具會提供自己的 ARM 範本，以提交至 Azure Resource Manager。
Azure 快速入門範本 提供原始程式碼範本，可協助加速登陸區域和工作負載部署。
Azure 原則提供在 DoD 中測試驗收準則的主要機制。 當部署偏離治理原則時，Azure 原則也可以提供自動化偵測、保護和解決。
在 TDD 迴圈中，您可以建立原則定義來測試單一接受準則。 Azure 原則包含可符合 DoD 內個別接受準則的內建原則定義。 此方法會在修改登陸區域之前提供紅色測試的機制。
Azure 原則也包含內建的原則計畫，可讓您用來測試並強制執行登陸區域的完整 DoD。 您可以將所有接受準則新增至指派給整個訂用帳戶的原則方案。 一旦登陸區域符合 DoD，Azure 原則就可以強制執行測試準則，以避免未來版本中測試失敗的程式碼變更。
設計並檢閱Azure 原則作為 TDD 方法一部分的程式代碼工作流程。
Azure 藍圖會將 原則和其他部署工具分組成可重複的套件，您可以指派給多個登陸區域。 藍圖適用于共用一般 DoD 的多個採用工作，您可能會想要隨著時間更新。 Azure 藍圖也可在後續的工作期間協助部署，以擴充和重構登陸區域。
Azure 藍圖提供各種藍圖範例，包括用於測試的原則，以及用於部署的範本。 這些藍圖範例可以加速在 TDD 週期中的開發、部署和測試工作。
Azure Resource Graph會根據部署在登陸區域中的資產相關資訊，提供建立資料驅動測試的查詢語言。 後續在採用計劃中，此工具也可以根據工作負載資產與基礎雲端環境之間的互動，來定義複雜的測試。
Resource Graph包含進階查詢範例，您可以用來瞭解工作負載在登陸區域內部署的方式，以進行進階測試案例。
視您慣用的方法而定，您也可以使用下列工具：
- 使用 Terraform 部署登陸區域。
- 使用 Bicep 部署登陸區域。
- 使用 AzOps 管理登陸區域，這是一個 PowerShell 模組，可在所有 Azure 範圍層級推送資源範本和 Bicep 檔案，並提取和匯出 Azure 資源階層。