部署後測試資源

6 分鐘

藉由驗證和預覽 Bicep 部署，您就能夠建立 Bicep 檔案成功部署的信賴度。但部署並不是程序的全部。部署完成之後，檢查部署是否執行您預期的作業也很有幫助。

在此單元中，您將了解可在部署完成後執行的測試。如果情況未如預期般運作，您也將瞭解如何復原部署。

執行煙霧測試和負面測試

當您在 Bicep 檔案中定義資源時，您的目標不只是在 Azure 中建立資源。這是為了將價值傳遞給組織，同時符合組織的需求。驗證並預覽 Bicep 檔案之後，您會更加確信資源定義有效，但您不一定知道資源實際上是否如您所預期一樣執行。

例如，假設您使用 Bicep 部署管線來部署新的 Azure SQL 邏輯伺服器。伺服器的 Bicep 定義是有效的，因此其會通過 Linter 和預檢驗證階段。假設狀況命令會顯示將建立伺服器，也就是您預期的情況。部署也會順利完成。但在部署程序結束時，您仍然可能沒有可供使用的可運作資料庫伺服器。原因可能包括：

您尚未設定防火牆規則，以允許網路流量觸達伺服器。
您已在伺服器上啟用 Microsoft Entra 驗證 (但您不應該這麼做)，反之亦然。

即使您只是部署基本 Bicep 檔案，還是值得考量如何驗證您所部署的資源是否實際運作並符合需求。以下是如何套用此準則的範例：

部署網站時，請嘗試從管線連接 Web 應用程式。驗證您的管線已成功連線到網站，並接收有效的回應碼。
當您部署內容傳遞網路 (CDN) 時，請嘗試透過 CDN 連線到資源。驗證管線已成功連線到 CDN，並接收有效的回應碼。

這些測試有時稱為基礎結構煙霧測試。煙霧測試是一種簡單形式的測試，其設計目的是要找出部署中的主要問題。

注意

有些 Azure 資源不容易從 Microsoft 裝載的管線代理程式連線。如果您需要透過私人網路存取資源，您可能需要考量使用自我裝載代理程式來執行煙霧測試階段。

執行負面測試也是個不錯的主意。負面測試可協助您確認資源沒有不想要的行為。例如，當您部署虛擬機器時，最好使用 Azure Bastion 安全地連線到虛擬機器。您可以將負面測試新增至管線，以驗證您無法使用遠端桌面連線或 SSH 直接連線到虛擬機器。

重要

這些測試的目標是不是為了確認 Bicep 已正確部署資源。藉由使用 Bicep，您會假設其會部署您在 Bicep 檔案中指定的資源。相反地，目標是要確認您已定義的資源適用於您的情況，並符合需求。

從 Azure Pipelines 執行測試

您有許多方式可以在管線中執行測試。在本課程模組中，我們使用 Pester，這是一種開放原始碼工具，可執行透過 PowerShell 撰寫的測試。您可以選擇使用不同的測試架構，或甚至選擇在沒有測試工具的情況下執行測試。例如，另一個要考慮的測試工具是適用於 Azure 的 PSRule，其中包含適用於 Azure 的預建規則和測試。其可以在範本上執行驗證，也可以對已部署的 Azure 資源執行測試。我們會在摘要中連結到 PSRule。

使用支援的測試架構時，Azure Pipelines 會了解每個測試的結果。它會在管線執行資訊旁邊顯示測試結果，並追蹤一段時間內每個測試的歷程記錄。在下一個練習中，您將了解如何將 Azure Pipelines 與基礎結構煙霧測試搭配使用。

在步驟和階段之間傳遞資料

當您將管線分成多個階段時，每個作業都有自己的責任，您有時需要在這些階段之間傳遞資料。例如，某個階段可能會建立另一個階段需要使用的 Azure 資源。若要能夠傳遞資料，第二個階段必須知道已建立的資源名稱。例如，我們的煙霧測試階段需要存取部署階段已部署的資源。

Bicep 檔案會部署資源，以便存取資源屬性，並將其發佈為部署輸出。您可以在管線中存取部署輸出。在 Azure Pipelines 中，有一個特殊的語法可用來發佈變數，讓變數可在階段之間使用。

首先，您必須發佈管線階段的輸出變數。若要輸出變數，您可以將特別格式化的字串寫入管線記錄，其為 Azure Pipelines 知道的格式。在下列範例中，名為 myVariable 的變數會設定為值 myValue：

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines 會讀取和解譯來自管線記錄的字串，並使變數的值成為輸出。您可以將此值與更多指令碼結合，將 Bicep 部署輸出的值發佈為管線階段的輸出變數。您會在下一個練習中了解如何製作此指令碼。

其次，您必須讓變數可供您的煙霧測試階段作業使用。您可以定義作業的變數，並使用另一個特別格式化的 YAML 字串：

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

現在，煙霧測試作業內的任何步驟可如同任何其他變數一樣，使用語法 $(myVariable) 來存取 myVariable 值。您將在下個練習中使用變數。

其他測試類型

功能測試和和整合測試通常用來驗證已部署的資源是否如預期般運作。例如，整合測試可能會連線到網站並提交測試交易，然後等候確認交易順利完成。藉由使用整合測試，您可以測試小組所建置的解決方案，以及其執行所在的基礎結構。在未來的模組中，您將了解如何將這些類型的測試新增至管線。

您也可以從部署管線執行其他類型的測試，包括效能測試和安全性滲透測試。這些測試不在本課程模組的範圍內，但可以提高自動化部署程序的價值。

復原和向前復原

假設您的管線已成功部署資源，但測試失敗。接下來您應該怎麼做？

稍早在此模組中，您已了解 Azure Pipelines 可讓您建立在上一個階段失敗時可執行的復原階段。當測試階段報告非預期的結果時，您可以使用此方法來建立復原階段。如果您認為失敗是因為暫時問題，而該問題已解決，您也可以手動復原變更，或重新執行整個管線。

注意

將部署提交至 Azure Resource Manager 時，您可以要求 Resource Manager 在失敗時自動重新執行最後一次成功的部署。若要這樣做，您必須使用 Azure CLI 步驟來部署檔案，並在使用 az deployment group create 命令提交部署時新增 --rollback-on-error 參數。

處理復原階段應該執行的步驟通常很困難。一般來說，Bicep 部署相當複雜，而且不容易復原變更。當部署包含其他元件時，復原就變得特別困難。

例如，假設您的管線會部署定義 Azure SQL 資料庫的 Bicep 檔案，然後將一些資料新增至資料庫。復原部署時，應該刪除資料嗎？是否也應該移除資料庫？預測每個失敗和每次復原如何影響執行中環境是很困難的。

基於這個理由，許多組織偏好向前復原，這表示他們快速修正失敗的原因，然後再部署一次。藉由建置高品質的自動化部署程序，並遵循您在這些學習路徑中學到的所有最佳做法，您就可以快速修正問題並重新部署 Bicep 檔案，同時維持高品質。

提示