使用 Azure Pipelines 規劃發行管線

6 分鐘

在本節中，您將跟著 Andy 和 Mara 一起規劃在 Azure Pipelines 上執行的基本 CD 管線。

完成後，他們會向小組的其餘成員示範。此管線做為 POC，並隨著他們深入了解和獲得 Tim 和 Amita 的意見反應而改進和擴充。

基本 CD 管線的有哪些部分？

基本 CD 管線包含觸發程序來啟動程序，還有至少一個階段，即部署階段。階段是由作業組成。作業是一系列的步驟，定義如何組建、測試或部署應用程式。

Diagram that shows a hand-drawn illustration of an artifact moving to a deployment environment.

Andy：我們已有組建成品。這是我們現有的組建管線建立的 .zip 檔案。但要如何部署到即時環境？

什麼是管線階段？

階段是管線的一部分，可以獨立執行，並由不同的機制觸發。機制可能是前一個階段成功、排程，甚至是手動觸發程序。在下一個課程模組中，您將深入了解這些機制。

Mara：我們可以有一個階段來組建應用程式，也有另一個階段來執行測試。

Diagram that shows a hand-drawn illustration of a deployment pipeline that contains two stages, Build and Deploy.

Mara：我們已定義在管線中組建階段的工作。部署階段可能很類似，包含工作將組建部署至環境。

問題是，成品應該部署在哪裡？

什麼是環境？

您可能使用了「環境」一詞來指稱應用程式或服務執行所在的位置。例如，生產環境可能是終端使用者存取應用程式的地方。

據此範例，您的生產環境可能是：

實體機器或虛擬機器 (VM)。
容器化環境，例如 Kubernetes。
受控服務，例如 Azure App Service。
無伺服器環境，例如 Azure Functions。

成品部署至環境。 Azure Pipelines 可讓您輕鬆部署至幾乎任何一種環境，無論在內部或雲端。

在 Azure Pipelines 中，環境一詞有第二種意義。在此，環境是部署環境的抽象表示法，例如 Kubernetes 叢集、App Service 執行個體或虛擬機器。

Azure Pipelines 環境會記錄部署歷程，以協助您識別變更的來源。在 Azure Pipelines 環境中，您也可以定義安全性檢查，並設法控制成品如何升階到管線的另一個階段。環境包含的內容取決於您想對成品做什麼。定義來測試成品的環境可能不同於您想為終端使用者部署成品的環境。

定義 Azure Pipelines 環境的方式之一，是使用 YAML 檔案。 YAML 檔案中有一個 environment 區段指定您部署成品的 Azure Pipelines 環境。

當您規劃發行管線時，必須決定您的應用程式或服務的執行位置。接著，我們將在這段影片中了解 Andy 和 Mara 的決定為何。

Andy：概括而言，我們想要何種類型的環境？我們想部署在內部還是雲端？

Mara：我們可能要求 Tim 在實驗室中為我們建立 VM，但是他的硬體永遠不夠用。如果我們使用雲端，就可以輕鬆快速地設定 POC。

Andy：我同意;但有這麼多的雲端選項可以考慮，我們能使用 Azure Pipelines 部署至其中任何一個。該試哪一個？

Mara：遊戲開發小組使用 Azure 來裝載其部分的後端系統。很快就設定，而且好像不錯。我認為應該選定 Azure 當作雲端。

Andy：好吧，這很合理！但 Azure 提供這麼多計算選項。該選哪一個？

Andy 在白板上列出這些選項：

虛擬機器
容器
Azure App Service
無伺服器運算

注意

在本課程模組結尾，您可以找到每個計算選項的詳細資訊。

Mara：我知道容器和無伺服器運算現在很受歡迎。在資源方面都比 VM 更輕便。也很容易更換和擴增。這兩個都不錯，但我擔心要同時學習兩種新技術。我寧可只專心組建管線。

Andy：我同意。那就剩下 VM 或 App Service 了。如果要將需要完整存取特定環境的企業營運應用程式移至雲端，我認為選擇 VM 比較好。我們並不會執行那麼重要的作業。

Mara：那麼就只剩 App Service 了，這也是我的選擇。它原本就是要與 Azure DevOps 搭配運作的，而且有很多優點。是適用於 Web 應用程式的平台即服務 (PaaS) 環境，可幫我們減輕很多負擔。我們不必擔心基礎結構。它也提供安全性功能，並可讓我們執行負載平衡和自動調整。

Andy：看來我們需要 App Service。那就使用 App Service 吧。反正只是要建立概念證明而已。如果後來想做其他嘗試，隨時都可以更換計算選項。

Azure Pipelines 如何執行部署步驟？

若要部署您的應用程式，Azure Pipelines 必須先向目標環境進行驗證。 Azure Pipelines 提供不同的驗證機制。使用何種機制取決於您部署的目標環境。在本課程模組結尾，您可以找到這些機制的詳細資訊。

Andy：我們有組建成品，而且知道將在管線的各階段中組建和部署。我們也已定義部署的目標環境。也就是 App Service。現在的問題是，Azure Pipelines 如何向 App Service 進行驗證？我知道這是 Tim 的顧慮之一。我們必須確保程序的安全性。

稍加研究後，Andy 和 Mara 擬出大致的步驟，可讓 Azure Pipelines 部署至 App Service：

在管線設定中指定目標部署環境。
設法讓 Azure Pipelines 驗證對該環境的存取權。
使用 Azure Pipelines 工作將組建成品部署至該環境。

Mara：根據我們的研究，我們必須建立服務連線，以指定目標環境並驗證其存取權。定義服務連線後，即可供所有工作使用。然後，我們需要使用內建工作 DownloadPipelineArtifact，將組建成品下載到管線代理程式和 AzureWebApp，以將應用程式部署至 Azure App Service。

什麼是作業和策略？

現有的組建管線定義組建代理程式、管線變數，以及組建軟體所需的工作。

管線的部署組件包含這些相同的元素。部署設定通常也定義一或多個作業、管線環境和策略。您先前已了解管線環境。

以下是您稍後在本課程模組中將執行的範例設定。此設定會將 Space Game 網站部署至 Azure App Service。

- stage: 'DeployDev'
  displayName: 'Deploy to dev environment'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: 'Release Pipeline'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppName)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

工作

作業是當成一個單元循序執行的一系列步驟或工作。每個管線階段預設都有一個作業，即使該階段未使用 job 關鍵字也一樣。

作業可以在代理程式集區或在容器上執行，或直接在 Azure DevOps 伺服器上執行。此處顯示的範例作業在 Microsoft 裝載的 Ubuntu 代理程式上執行。

您可以指定每個作業據以執行的條件。此處顯示的範例作業未定義任何條件。依預設，如果作業未依存於任何其他作業，或其所依存的所有作業都已順利完成，則該作業會執行。

您也可以平行或循序執行作業。以您現有的組建管線為例，您可以使用平行作業，同時在 Windows、Linux 和 macOS 代理程式上組建您的軟體。

部署作業是一種特殊作業，在部署階段扮演重要角色。部署作業會記錄您在 Azure Pipelines 中的部署狀態，而為您提供稽核記錄。部署作業也協助您定義部署策略，我們馬上就會這樣做。

策略

策略定義應用程式的推出方式。在未來的課程模組中，您將進一步了解策略，例如藍綠和 Canary。目前，您將使用 runOnce 策略從管線下載 Space Game 套件，並部署至 Azure App Service。

Azure Pipelines 如何連線至 Azure？

若要將您的應用程式部署至 Azure 資源 (例如虛擬機器或 App Service)，必須要有服務連線。服務連線有兩種方法讓您安全地存取 Azure 訂用帳戶：

服務主體驗證
適用於 Azure 資源的受控識別

在本課程模組最後，您可以深入了解這些安全性模型，但簡言之：

服務主體是具有受限角色的身分識別，可存取 Azure 資源。您可以將服務主體視為能夠代表您執行自動化工作的服務帳戶。
Azure 資源的受控識別是 Microsoft Entra ID 的一個功能，可簡化使用服務主體的流程。因為受控識別存在於 Microsoft Entra 租用戶上，因此 Azure 基礎結構可自動驗證服務，並為您管理帳戶。

受控識別可簡化使用服務主體的流程；但在此課程模組中，我們將使用服務主體驗證，因為服務連線可以自動探索您的 Azure 資源，並為您指派適當的服務主體角色。

方案

Andy 和 Mara 已準備開始。他們將會：

依據現有的 Azure Pipelines 組建組態來建立。
定義組建階段來建立成品。
定義部署階段將成品部署至 App Service。

Diagram that shows a hand-drawn illustration of a deployment pipeline that contains two stages. The deployment stage deploys the artifact to App Service.