下一步

使用 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 应用服务。
无服务器环境，例如 Azure Functions。

生成工件部署到环境中。通过 Azure Pipelines，可以轻松地部署到几乎任何类型的环境中，无论是本地环境还是云环境。

在 Azure Pipelines 中，“环境”一词还有第二种含义。在这里，环境是部署环境的抽象表示形式，例如 Kubernetes 群集、应用服务实例或虚拟机。

Azure Pipelines 环境会记录部署历史记录，以帮助确定更改源。通过使用 Azure Pipelines 环境，还可以定义安全检查以及控制将生成工件从管道的一个阶段提升到另一个阶段的方式。环境包含的内容取决于要对生成工件执行的操作。要在其中测试生成工件的环境可能与要在其中为最终用户部署生成工件的环境定义不同。

定义 Azure Pipelines 环境的一种方法是使用 YAML 文件。 YAML 文件包括一个 environment 部分，用于指定将在其中部署生成工件的 Azure Pipelines 环境。

在计划发布管道时，需要确定运行应用程序或服务的位置。我们来听听看 Andy 和 Mara 的决定。

Andy：从较高的层面来看，我们需要什么类型的环境？我们要在本地还是在云上部署？

Mara：我们可以让 Tim 在实验室中为我们创建一个 TM，但他的硬件总是不够用。如果使用云，我们自己就可以快速轻松地设置 POC。

Andy：我同意，但是有很多云选项可以考虑，我们可以使用 Azure Pipelines 部署到其中任何一个。我们应该尝试哪一种方案呢？

Mara：游戏开发团队使用 Azure 来托管他们的一些后端系统。他们可以快速设置，并且似乎对它很满意。我认为，对于云，应该坚持使用 Azure。

Andy：好，有道理！但是 Azure 提供了如此多的计算选项。我们应该选择哪一个？

Andy 在白板上列出了以下选项：

虚拟机
容器
Azure 应用服务
无服务器计算

注意

学完本模块后，你会了解有关这些计算选项的详细信息。

Mara：我知道容器和无服务器计算现在很常用。与 VM 相比，它们在资源方面都是轻量级的。它们也很容易替换和横向扩展。两者都很有趣，但我对于同时学习两种新技术感到不安。我更愿意只专注于生成管道。

Andy：我同意。那就剩下 VM 或应用服务了。我认为，如果要将需要对某些特定环境具有完全访问权限的业务线应用迁移到云中，则 VM 会是更好的选择。我们无需执行任何重要的操作。

Mara：那就剩下我要选择的应用服务了。它旨在与 Azure DevOps 一起使用，并且有很多优点。它是用于 Web 应用的平台即服务 (PaaS) 环境，因此可为我们减轻很多负担。我们无需担心基础结构。它还具有安全功能，使我们能够执行负载均衡和自动缩放。

Andy：应用服务听起来像是我们需要的。我们就使用应用服务吧。不管怎样，我们只是创建概念证明。如果我们以后要尝试其他操作，则可以随时更改计算选项。

Azure Pipelines 如何执行部署步骤？

若要部署应用程序，Azure Pipelines 首先需要对目标环境进行身份验证。 Azure Pipelines 提供了不同的身份验证机制。使用的内容取决于要部署到的目标环境。学完本模块后，你会了解有关这些机制的详细信息。

Andy：我们拥有生成工件，并且知道我们将在管道的各个阶段进行生成和部署。我们还为部署定义了目标环境。也就是应用服务。现在我的问题是，Azure Pipelines 如何对应用服务进行身份验证？我知道这将是 Tim 关注的问题之一。我们需要确保该过程是安全的。

经过一番研究，Andy 和 Mara 提出了可以将 Azure Pipelines 部署到应用服务的一般步骤：

在管道配置中指定目标部署环境。
提供一种方法，使 Azure Pipelines 可以验证对该环境的访问权限。
使用 Azure Pipelines 任务将生成工件部署到该环境。

Mara：根据我们的研究，我们需要创建一个服务连接以指定目标环境并验证对其的访问权限。定义服务连接后，它将可供所有任务使用。然后，我们需要使用内置任务 DownloadPipelineArtifact 将生成工件下载到管道代理，并使用 AzureWebApp 将应用程序部署到 Azure 应用服务。

什么是作业和策略？

现有的生成管道定义了一个生成代理、管道变量以及生成软件所需的任务。

管道的部署部分包含这些相同的元素。部署配置通常还会定义一个或多个作业、管道环境和策略。你之前已经了解了管道环境。

下面是稍后将在本模块中运行的示例配置。此配置将 Space Game 网站部署到 Azure 应用服务。

- 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 应用服务。

Azure Pipelines 如何连接到 Azure？

若要将应用部署到虚拟机或应用服务等 Azure 资源，你需要一个服务连接。服务连接通过使用以下两种方法之一来提供对 Azure 订阅的安全访问：

服务主体身份验证
Azure 资源的托管标识

学完本模块后，你可以了解有关这些安全模型的详细信息，但简言之：

服务主体是具有可访问 Azure 资源的受限角色的标识。将服务主体视作可代表你执行自动化任务的服务帐户。
Azure 资源的托管标识是 Microsoft Entra ID 的一项功能，可简化使用服务主体的过程。由于 Microsoft Entra 租户上存在托管标识，因此 Azure 基础结构可以自动对服务进行身份验证和管理帐户。

托管标识可简化使用服务主体的过程；但是在此模块中，我们将使用服务主体身份验证，因为服务连接可以自动发现 Azure 资源并为你分配适当的服务主体角色。

计划

Andy 和 Mara 准备开始了。他们将执行以下操作：

基于其现有的 Azure Pipelines 生成配置进行生成。
定义创建生成工件的生成阶段。
定义将生成工件部署到应用服务的部署阶段。

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