使用 Azure Pipelines 规划发布管道

在本部分中，你将和 Andy 和 Mara 一起计划一个在 Azure Pipelines 上运行的基本 CD 管道。

完成后，他们将将其演示给团队的其余部分。 该管道将充当 POC，随着了解更多并获得 Tim 和 Amita 的反馈，他们将会进行完善和扩展。

基本 CD 管道有哪些部分？

基本的 CD 管道包含一个 触发器 ，用于启动进程，以及至少一个 阶段，即至少一个部署阶段。 阶段由作业构成。 作业是一系列步骤，用于定义如何生成、测试或部署应用程序。

Andy：我们已拥有 生成工件。 我们现有的构建流水线创建的文件是 .zip 文件。 但是，我们如何将其部署到 实时环境？

什么是管道阶段？

阶段是管道的一部分，可以独立运行，并由不同的机制触发。 机制可以是上一阶段的成功、一份计划，甚至是手动触发器。 在下一个模块中，你将了解有关这些机制的详细信息。

玛拉： 我们可以有一个阶段来生成应用，另一个阶段运行测试。

玛拉： 我们已经在流水线中定义了构建阶段的任务。 我们的部署阶段 可能类似，其中包括将生成部署到环境中的任务。

问题是，我们应该在何处部署人工制品？

什么是环境？

你可能已使用术语 环境 来引用应用程序或服务的运行位置。 例如， 生产 环境可能是最终用户访问应用程序的位置。

以下示例中，生产环境可能是：

• 物理计算机或虚拟机（VM）。
• 容器化环境，例如 Kubernetes。
• 托管服务，例如 Azure 应用服务。
• 无服务器环境，例如 Azure Functions。

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

在 Azure Pipelines 中，术语环境具有第二个含义。 此处，环境是部署环境的抽象表示形式，例如 Kubernetes 群集、应用服务实例或虚拟机。

Azure Pipelines 环境记录部署历史记录，以帮助识别更改源。 通过使用 Azure Pipelines 环境，还可以定义安全检查以及控制项目如何从管道的一个阶段提升到另一个阶段的方法。 环境包括的内容取决于你想如何使用工件。 要测试人工制品的环境可能与想要为最终用户部署人工制品的环境定义不同。

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

规划发布管道时，需要确定应用程序或服务的运行位置。 让我们听一听，看看安迪和马拉决定什么。

安 迪： 概括而言，我们想要哪种类型的环境？ 是否要在本地或云中部署？

玛拉： 我们可以请 Tim 在实验室中为我们创建一个 VM，但他总是没有足够的硬件。 如果我们使用云，那么设置 POC 的速度会很快且容易。

安 迪： 我同意;但是需要考虑很多云选项，我们可以使用 Azure Pipelines 部署到其中任何一个。 我们应该尝试哪一个？

玛拉： 开发游戏的团队使用 Azure 托管其一些后端系统。 他们可以快速设置，并且似乎对它很满意。 我认为我们应该继续使用 Azure 作为我们的云平台。

安 迪： 好吧，这很有意义！ 但 Azure 提供了这么多的计算选项。 我们应该选择哪一个？

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

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

玛拉： 我知道容器和无服务器计算现在很受欢迎。 与 VM 相比，它们在资源方面都是轻量级的。 它们也易于替换和横向扩展。两者都很有趣，但我对同时学习两项新技术感到紧张。 我宁愿专注于构建管道。

安 迪： 我和你在一起 这意味着只剩下虚拟机或应用服务。 我认为，如果我们将业务线应用（需要完全访问某个特定环境的应用）迁移到云，则 VM 将是更好的选择。 我们没有做任何重要的事情。

玛拉： 剩下的是应用服务，这将是我的选择。 它旨在与 Azure DevOps 配合使用，并具有优势。 它是一个平台即服务（PaaS）环境，专为 Web 应用而设，因此大大减轻了我们的负担。 我们不必担心基础结构。 它还附带了安全功能，使我们能够执行负载均衡和自动缩放。

安 迪： 应用服务听起来像是我们需要的。 让我们使用应用服务。 不管怎样，我们只是创建概念证明。 如果以后要尝试其他内容，我们始终可以更改计算选项。

Azure Pipelines 如何执行部署步骤？

若要部署应用程序，Azure Pipelines 首先需要向目标环境进行身份验证。 Azure Pipelines 提供不同的身份验证机制。 您选择使用的取决于要部署的目标环境。 在本模块结束时，你将找到有关这些机制的详细信息。

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

经过一些研究，Andy 和 Mara 提出了允许 Azure Pipelines 部署到应用服务的一般步骤：

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

玛拉： 根据我们的研究，我们需要创建 一个服务连接 来指定目标环境并验证对它的访问权限。 定义服务连接后，它将可供所有任务使用。 然后，我们需要使用内置任务 DownloadPipelineArtifact@2 将生成项目下载到管道代理， AzureWebApp@1 将应用程序部署到 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 中部署的状态，从而提供审核日志。 部署作业还可以帮助定义部署策略，我们很快就会执行此操作。

策略

策略定义应用程序的推出方式。你将在将来的模块中详细了解蓝绿和金丝雀等策略。 现在，你将使用 runOnce 策略从管道下载 Space Game 包并将其部署到 Azure 应用服务。

Azure Pipelines 如何连接到 Azure？

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

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

可以在本模块末尾了解有关这些安全模型的详细信息，但简言之：

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

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

计划

安迪和马拉准备开始。 他们将执行以下操作：

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

安 迪： 此绘图是否正确？ 我们使用 Azure Pipelines 部署到 Azure 应用服务 。 为此，我们将构建工件 作为部署阶段 的输入。 部署阶段中的任务下载项目 ，并使用服务连接将项目部署到应用服务 。

玛拉： 差不多就是这样了。 让我们开始吧。