了解端對端部署

5 分鐘

GitHub Actions 工作流程是彈性的工具，您可以透過許多不同的方式設定，使其符合您的需求。在本單元中，您將了解如何使用工作流程來部署整個解決方案，包括設定 Azure 基礎結構，以及執行其他部署作業。

有多少工作流程？

在某些組織中，管理 Azure 環境的小組與開發環境中所執行程式碼的小組不同。在這些情況下，通常想要建立多個工作流程，且每個工作流程都是由負責其特定區域的小組所擁有。例如，您可以建立一個工作流程來部署 Bicep 程式碼 (可部署網站 Azure 資源)，以及另一個工作流程來部署網站應用程式。

雖然這種方法能讓您在管理工作流程的方式上有一些彈性，但要讓所有項目保持同步可能會很困難。例如，假設您的網站小組在其 Azure App Service 應用程式上需要新的設定，以啟用其所建置的功能。在基礎結構部署工作流程成功完成之前，應用程式部署工作流程都無法執行。此外，在工作流程之間傳送資料 (例如基礎結構工作流程所建立 Azure 資源的名稱) 可能會變得很複雜。

相反地，最好建立單一工作流程來部署解決方案所需的所有項目，即使元件是由不同小組或不同人員所管理也一樣。您可以使用 Git 和 GitHub 之類的工具來協調您的工作。您在新增新功能時，可以使用分支對 Bicep 檔案進行必要的變更。當變更準備好進行整合及發行時，單一工作流程會執行建置和部署解決方案的所有必要步驟，進而減少發生不同步的機會。

提示

當您為解決方案建置程式碼時，可能需要經常部署該程式碼，以便測試其運作方式。您可能會發現，將基礎結構與應用程式程式碼一起部署時，會使您的工作流程執行速度變慢，並禁止您的進度。

如果您處於這個情況，則可以考慮停用開發環境的基礎結構部署。您可以使用路徑篩選、可重複使用的工作流程以及條件來達成此目的。不過，您應該讓其他環境的完整部署順序保持不變。

控制平面和資料平面

許多 Azure 資源都會提供兩個不同的平面可供存取。 控制平面會部署並設定資源。 資料平面可讓您存取資源的功能。

當您建立和部署 Bicep 檔案時，會與控制平面進行互動。在 Azure 中，控制平面是 Azure Resource Manager。您可以使用 Resource Manager 來定義每個資源的設定。

但您的工作流程通常不只需要與控制平面進行互動。例如，您可能需要：

將 Blob 上傳至儲存體帳戶。
修改資料庫結構描述。
對協力廠商服務進行 API 呼叫。
觸發機器學習模型更新。
將網站部署至 Azure App Service 應用程式。
將軟體部署至虛擬機器。
向協力廠商提供者註冊 DNS 項目。

當您考慮使用端對端工作流程時，通常需要部署 Azure 資源，然後針對這些資源的資料平面執行一系列作業。有時候，這些作業會稱為部署的最後一哩路，因為您要使用控制平面來執行大部分的部署，而且只有少量設定會保留下來。

注意

有些資源的控制平面與資料平面之間並沒有清楚的劃分。這些資源包括 Azure Data Factory 和 Azure API 管理。這兩項服務都支援使用 Bicep 進行完全自動化的部署，但需要特殊考量。您可以在課程模組結尾的 [摘要] 頁面上找到其他資訊的連結。

如何執行資料平面作業

當您建立的部署工作流程可與資源資料平面進行互動時，可以使用下列三種常見方法之一：

Resource Manager 部署指令碼
工作流程指令碼
工作流程動作

Resource Manager 部署指令碼是在 Bicep 檔案中進行定義。其會執行 Bash 或 PowerShell 指令碼，並可與 Azure CLI 命令和 Azure PowerShell Cmdlet 進行互動。您可以為部署指令碼建立受控識別，以用來向 Azure 進行驗證，而 Azure 會自動佈建和管理執行部署指令碼所需的其他資源。

當您必須在部署流程中執行基本指令碼時，部署指令碼便非常有用，但其無法讓您輕鬆地從工作流程存取其他元素。

您也可以從部署工作流程內執行自己的邏輯。 GitHub Actions 會針對您需要執行的一般工作，提供豐富的「動作」生態系統。如果您找不到符合您需求的動作，您可以使用「指令碼」來執行自己的 Bash 或 PowerShell 程式碼。工作流程動作和指令碼會從您工作流程的執行器執行。您通常需要向所使用服務的資料平面驗證動作或指令碼，而執行這項操作的方式則取決於服務。

工作流程動作和指令碼能賦予您彈性和掌控力。其也可讓您存取待會要認識的「工作流程成品」。在本課程模組中，我們的重點是工作流程動作。在課程模組結尾的 [摘要] 頁面上，我們會連結至 Resource Manager 部署指令碼的詳細資訊。

輸出

工作流程通常會部署 Bicep 檔案，藉此建立及設定您的 Azure 資源。接著，工作流程的後續部分會與這些資源的資料平面進行互動。為了能夠與資源進行互動，工作流程動作和步驟需要已建立之 Azure 資源的相關資訊。

例如，假設您的 Bicep 模組部署了儲存體帳戶。您需要工作流程部署儲存體帳戶，然後將某些 Blob 上傳至儲存體帳戶中的 Blob 容器。上傳 Blob 的工作流程步驟必須知道所要連線的儲存體帳戶名稱，以及要接收上傳檔案的 Blob 容器名稱。

最好讓 Bicep 檔案來決定 Azure 資源的名稱。其可能會使用參數、變數或運算式來建立儲存體帳戶和 Blob 容器的名稱。然後，Bicep 檔案可以將提供每個資源名稱的輸出公開。工作流程的後續步驟可以讀取輸出值。如此一來，您的工作流程定義就不必將可能在環境之間變更的任何名稱或其他資訊進行硬式編碼，或是以 Bicep 檔案中定義的規則為基礎。

透過 GitHub Actions 即可使用「工作流程變數」傳播輸出值。此 azure/arm-deploy 動作會自動為每個 Bicep 部署輸出建立變數。您也可以在指令碼中手動建立工作流程變數。您可以在本課程模組結尾的 [摘要] 頁面上找到其他資訊的連結。

當您存取在另一個工作中建立的變數時，您必須發佈變數，才能讓讀取變數的作業存取變數。例如，假設您建立了部署 Bicep 檔案的作業，而您需要將 appServiceAppName 輸出傳播至工作流程。您要使用 outputs 關鍵字，指定 appServiceAppName 工作流程變數應設定為 deploy 步驟所建立的 appServiceAppName 輸出變數值：

job1:
  runs-on: ubuntu-latest
  outputs:
    appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
  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 Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: Playground1
      template: ./deploy/main.bicep

然後，在稍後的工作中，您會包含 needs 關鍵字以在建立變數的工作上建立明確的相依性，並使用已發佈的變數名稱來參考變數：

job2:
  needs: job1
  runs-on: ubuntu-latest
  steps:
  - run: |
      echo "${{needs.job1.outputs.appServiceAppName}}"

您可以使用 Bicep 輸出和工作流程變數，藉此建立工作流程來部署 Bicep 程式碼，然後在部署期間對資源執行各種動作。

了解端對端部署

有多少工作流程？

控制平面和資料平面

如何執行資料平面作業

輸出

意見反應