Azure 登陸區域的試用開發

測試驅動開發 （TDD） 是軟體開發和 DevOps 程式，可改善以程式代碼為基礎的解決方案新功能和改進品質。 TDD 會在開發實際程式碼之前建立單元測試案例，並針對測試案例測試程序代碼。 這種方法不一定先開發程序代碼，稍後再建立測試案例。

登陸區域是裝載透過程式碼預先布建的工作負載環境。 登陸區域包括使用一組已定義雲端服務和最佳做法的基礎功能。 本文說明使用 TDD 部署成功登陸區域的方法，同時符合品質、安全性、作業和治理需求。

雲端基礎結構是程式代碼執行的輸出。 經過妥善結構化、測試和驗證的程式代碼會產生可行的登陸區域。 雲端式基礎結構及其基礎原始程式碼可以使用此方法，以確保登陸區域具有高品質且符合核心需求。

使用此方法在早期開發期間滿足簡單的功能要求。 稍後在雲端採用生命週期中，您可以使用此程式來符合安全性、作業、治理或合規性需求。 此程式特別適用於以平行開發工作開發和重構登陸區域。

測試驅動開發週期

下圖顯示 Azure 登陸區域的測試驅動開發週期：

1. 建立測試。 定義測試，以驗證已符合功能的接受準則。 在開發時自動化測試，以減少手動測試投入量，特別是針對企業級部署。

2. 測試登陸區域。 執行新的測試和任何現有的測試。 如果雲端提供者的供應專案中未包含必要功能，且先前的開發工作尚未提供，測試應該會失敗。 執行現有的測試有助於驗證您的新功能或測試不會降低現有登陸區域功能的可靠性。

3. 展開並重構登陸區域。 新增或修改原始程式碼，以履行要求的加值功能，並改善程式代碼基底的一般品質。

   為了符合 TDD 準則，雲端平臺小組只會新增程式代碼以符合要求的功能。 不過，程式代碼質量和維護是共同的工作。 當他們滿足新功能要求時，雲端平臺小組應該嘗試藉由移除重複並釐清程序代碼來改善程序代碼。 強烈建議在新程式代碼建立和重構原始程式碼之間執行測試。

4. 部署登陸區域。 原始程式碼完成功能要求之後，請在受控制的測試或沙箱環境中，將修改後的登陸區域部署到雲端提供者。

5. 測試登陸區域。 重新測試登陸區域，以驗證新程序代碼是否符合所要求功能的接受準則。 所有測試都通過之後，功能就會被視為完成，且會被視為符合驗收準則。

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 Resource Graph 提供查詢語言，可根據部署在登陸區域中的資產相關信息來建立數據驅動測試。 稍後在採用計劃中，此工具也可以根據工作負載資產與基礎雲端環境之間的互動來定義複雜的測試。

  Resource Graph 包含進階 查詢範例，可用來瞭解在登陸區域內部署工作負載的方式，以取得進階測試案例。

視您慣用的方法而定，您也可以使用下列工具：

• 使用 Terraform 部署登陸區域。
• 使用 Bicep 部署登陸區域。
• 使用 AzOps 管理登陸區域，這是一個 PowerShell 模組，可推送所有 Azure 範圍層級的資源範本和 Bicep 檔案，並提取和導出 Azure 資源階層。

下一步

• DevOps 平臺的安全性考慮
• 登陸區域實作選項