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。
支援登陸區域 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 Policy 可以執行測試準則，強制避免在未來版本中會導致測試失敗的程式代碼變更。
設計並檢閱 Azure 原則即程式碼工作流程，作為您 TDD 方法的一部分。
Azure Resource Graph 提供查詢語言，可根據部署在登陸區域中的資產相關信息來建立數據驅動測試。 稍後在採用計劃中，此工具也可以根據工作負載資產與基礎雲端環境之間的互動來定義複雜的測試。
Resource Graph 包含進階 查詢範例，可用來瞭解工作負載在著陸區內的部署方式，以用於進階測試情境。
視您慣用的方法而定，您也可以使用下列工具：
- 使用 Terraform部署登陸區域。
- 使用 Bicep部署登陸區域。
- 使用 AzOps管理登陸區域，這是一個 PowerShell 模組，可推送所有 Azure 範圍層級的資源範本和 Bicep 檔案，以及提取和導出 Azure 資源階層。