部署後測試資源

6 分鐘

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

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

執行煙霧測試和負面測試

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

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

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

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

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

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

注意

有些 Azure 資源無法從裝載 GitHub 的執行器輕鬆連線。如果您需要透過私人網路存取資源，您可能需要考慮使用自我裝載的執行器來執行煙霧測試作業。

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

重要

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

從 GitHub 工作流程執行測試

有許多方式可以在工作流程中執行測試。在本課程模組中，我們使用 Pester，這是一種開放原始碼工具，可執行透過 PowerShell 撰寫的測試。 Pester 會預先安裝在 GitHub 裝載的執行器上。您不需要執行任何特殊動作，即可在指令碼步驟中使用 Pester。

您可以選擇使用不同的測試架構，或甚至選擇在沒有測試工具的情況下執行測試。例如，另一個要考慮的測試工具是適用於 Azure 的 PSRule，其中包含適用於 Azure 的預建規則和測試。其可以在範本上執行驗證，也可以對已部署的 Azure 資源執行測試。我們會在摘要中連結到 PSRule。

當您從工作流程執行測試時，任何測試失敗都應該使工作流程無法繼續。在下一個練習中，您將瞭解如何搭配基礎結構煙霧測試使用工作流程。

測試結果會寫入工作流程記錄。 GitHub Marketplace 也包含非 Microsoft 動作，可顯示及追蹤一段時間的測試結果。

在作業之間傳遞資料

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

Bicep 檔案會部署資源，以便存取資源屬性，並將其發佈為部署輸出。當您透過 arm-deploy 動作執行 Bicep 部署時，此動作會將這些 Bicep 部署輸出儲存在其步驟輸出中。接下來，保存 arm-deploy 動作的作業現在可以將這些步驟輸出發佈為作業輸出。作業會參考步驟的 id 屬性，我們將其設為 deploy：

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

只要作業相依於產生輸出的作業，您就可以在任何後續作業中存取作業的輸出：

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

您也可以使用特殊語法，從工作流程指令碼傳遞輸出。我們在摘要中連結更多資訊。

其他測試類型

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

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

復原和向前復原

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

稍早在本課程模組中，您已瞭解 GitHub Actions 可讓您建立在先前作業失敗時執行的復原作業。當測試作業報告非預期的結果時，您可以使用此方法來建立復原作業。如果您認為失敗是由於已解決的暫時問題所造成的，您也可以手動復原變更，或重新執行整個工作流程。

注意

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

例如，您可以將復原作業新增至工作流程。復原作業會在煙霧測試作業失敗時執行：

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

此作業取決於煙霧測試作業。其只會在煙霧測試失敗時執行。根據預設，每當先前的作業失敗時，GitHub Actions 就會停止工作流程。 if 條件包含覆寫此行為的 always() 檢查。如果沒有運算式中的 always()，則每當先前的作業失敗時就會略過復原作業。

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

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

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

提示