原文：
annas-archive.org/md5/b9af5174af71449b8d6f11a56dee9821译者：飞龙
第四章：
第五章：了解 Azure DevOps Pipelines
在您的组织中采用Azure DevOps时，必须做出的一个重要决定是如何定义您开发流程的流水线。流水线是公司定义的模型，描述了代码库必须支持的步骤和操作，从构建到最终发布阶段。它是任何 DevOps 架构中的关键部分。
在本章中，我们将学习如何使用 Azure DevOps 定义和使用流水线来构建代码。
我们将涵盖以下主题：
-
实现 CI/CD 流程
-
Azure Pipelines 概述
-
创建和使用构建代理
-
YAML 格式概述
-
使用 Azure DevOps 创建 CI/CD 流水线
-
保留构建记录
-
多阶段流水线
-
使用 GitHub 仓库构建流水线
-
在 Azure Pipelines 中使用容器作业
-
让我们开始吧！
技术要求
要学习本章内容，您需要具备以下条件：
-
在 Azure DevOps 中的有效组织
-
一个 Azure 订阅，您可以在其中创建 Azure 虚拟机或在这些环境中的本地计算机上安装构建代理软件
-
使用 Visual Studio 或 Visual Studio Code 作为开发环境
-
访问以下 GitHub 仓库以克隆项目：
github.com/Microsoft/PartsUnlimited
实现 CI/CD 流程
在公司中采用 DevOps 时，实施正确的 DevOps 工具与正确的 DevOps 流程至关重要。DevOps 实施中的一个基本流程是持续集成（CI）和持续交付（CD）过程，这可以帮助开发者以更快、更结构化、更安全的方式构建、测试和分发代码库。
CI 是一种软件工程实践，开发团队中的开发者在中央仓库中每天多次集成代码修改。当代码修改集成到特定分支（通常通过拉取请求，如上一章所述）时，会触发新的构建，以便快速检查代码并检测集成错误。此外，在此阶段会执行自动化测试（如果有的话）以检查是否存在故障。
CD 是紧随 CI 流程之后的过程。在此过程中，CI 阶段的输出会被打包并无错误地交付到生产阶段。这非常有帮助，因为我们始终拥有一个经过测试、一致且准备部署的主分支。
在 DevOps 中，您还可以实施持续部署流程，在此流程中，您可以自动化将代码修改部署到最终生产环境，而无需人工干预。
典型的 DevOps CI/CD 循环在以下著名的“循环”图中表示：
图 4.1 – DevOps CI/CD 循环
一个典型的 CI/CD 流水线实现包含以下阶段：
-
提交阶段：在这里，新的代码修改被集成到代码库中，并执行一组单元测试，以检查代码的完整性和质量。
-
构建阶段：在这里，代码会自动构建，然后将构建过程的最终结果（构建产物）推送到最终的注册表。
-
测试阶段：构建的代码将部署到预生产环境，在那里进行最终测试，然后再进行生产部署。在这里，代码会通过采用 Alpha 和 Beta 部署进行测试。Alpha 部署阶段是开发人员检查新构建的性能以及不同构建之间的交互。在 Beta 部署阶段，开发人员执行手动测试，以再次检查应用程序是否正常工作。
-
生产部署阶段：这是最终应用程序在成功通过所有测试要求后，正式发布到生产环境的阶段。
在你的组织中实施 CI/CD 流程有很多好处，主要的好处如下：
-
提高代码质量和早期发现 bug：通过采用自动化测试，你可以在早期发现 bug 和问题，并及时修复。
-
完整的可追溯性：整个构建、测试和部署过程都被追踪，可以在之后进行分析。这确保了你可以检查特定构建中包含的哪些更改，以及这些更改对最终测试或发布的影响。
-
更快的测试和发布阶段：自动化地在每次提交（或发布前）对代码库进行构建和测试。
在接下来的部分，我们将概述 Azure 平台提供的用于实现 CI/CD 的服务：Azure Pipelines。
Azure Pipelines 概述
Azure Pipelines 是 Azure 平台提供的一项云服务，允许你自动化开发生命周期的构建、测试和发布阶段（CI/CD）。Azure Pipelines 支持任何语言或平台，它集成在 Azure DevOps 中，你可以在 Windows、Linux 或 macOS 机器上构建你的代码。
Azure Pipelines 对于公共项目是免费的，而对于私有项目，每月提供最多 1,800 分钟（30 小时）的管道使用时间。有关定价的更多信息，请参见这里：
azure.microsoft.com/en-us/pricing/details/devops/azure-devops-services/
Azure Pipelines 的一些重要特性总结如下：
-
它是平台和语言独立的，这意味着你可以在任何平台上使用你想要的代码库构建代码。
-
它可以与不同类型的代码库集成（Azure Repos、GitHub、GitHub Enterprise、BitBucket 等）。
-
有很多扩展（标准和社区驱动）可用于构建你的代码和处理自定义任务。
-
允许你将代码部署到不同的云服务商。
-
你可以处理容器化应用程序，如 Docker、Azure 容器注册表或 Kubernetes。
要使用 Azure Pipelines，你需要具备以下条件：
-
一个 Azure DevOps 组织，你可以在其中创建公共或私有项目
-
存储在版本控制系统中的源代码（如 Azure DevOps Repos 或 GitHub）
Azure Pipelines 按如下架构工作：
图 4.2 – Azure Pipelines 架构
当你的代码提交到某个仓库中的特定分支时，构建管道引擎启动，构建和测试任务会执行，如果所有任务都成功完成，你的应用程序就会构建完成，并且你会得到最终的输出（工件）。你还可以创建一个发布管道，将构建的输出发布到目标环境（预发布或生产环境）。
要开始使用 Azure Pipelines，你需要创建一个管道。Azure DevOps 中的管道可以通过以下两种方式创建：
-
使用经典界面：这允许你从可能的任务列表中以视觉方式选择一些任务。你只需要填写这些任务的参数。
-
使用一种名为 YAML 的脚本语言：通过在你的仓库中创建一个 YAML 文件，并在其中定义所有需要的步骤来定义管道。
使用经典界面最初可能更为简单，但请记住，许多功能仅在 YAML 管道中可用。YAML 管道定义是一个文件，并且可以像仓库中的其他文件一样进行版本控制和管理。你可以轻松地在项目之间移动管道定义（经典界面无法实现此操作）。
一个 Azure Pipeline 可以如下表示（感谢 Microsoft）：
图 4.3 – Azure Pipeline 表示
一个管道从触发器（手动触发、仓库中的推送、拉取请求或计划任务）开始。管道通常由一个或多个阶段（管道中的逻辑分离，如构建、测试、部署等；它们可以并行运行）组成，每个阶段包含一个或多个作业（一组也可以并行运行的步骤）。每个管道至少包含一个阶段，如果你没有显式创建，它会自动创建。每个作业都在一个代理（执行作业的服务或软件）上运行。每个步骤由一个任务组成，该任务对你的代码执行某些操作（按顺序执行）。管道的最终输出是一个工件（构建过程中发布的文件或包的集合）。
在创建管道时，你需要定义一组任务和作业，用于自动化构建（或多阶段构建）。你可以原生支持集成测试、发布门、自动报告等功能。
在管道中定义多个作业时，这些作业会并行执行。包含多个作业的管道被称为扇出场景：
图 4.4 – 扩展管道
一个包含多个作业的单个阶段管道可以表示如下：
pool:
vmImage: 'ubuntu-latest'
jobs:
- job: job1
steps:
- bash: echo "Hello!"
- bash: echo "I'm job 1"
- job: job2
steps:
- bash: echo "Hello again…"
- bash: echo "I'm job 2"
如果在定义管道时使用阶段，这就属于所谓的扩展/汇集场景：
图 4.5 – 扩展管道
在这里，每个阶段都是一个汇集操作，阶段中的所有作业（可以由多个顺序执行的任务组成）必须完成，才能触发下一个阶段（每次只能执行一个阶段）。我们将在本章后面讨论多阶段管道。
了解构建代理
要使用 Azure Pipelines 构建和部署代码，您至少需要一个代理。代理是一个运行管道中定义作业的服务。这些作业的执行可以直接发生在代理的主机机器上，也可以在容器中进行。
在为您的管道定义代理时，您基本上有两种类型的代理：
-
Microsoft 托管代理：这是一个完全由 Microsoft 管理的服务，在每次管道执行时都会清除（每次管道执行时，您都会获得一个全新的环境）。
-
自托管代理：这是一个需要您自己设置和管理的服务。它可以是 Azure 上的自定义虚拟机，也可以是您基础设施内的自定义本地机器。在自托管代理中，您可以安装构建所需的所有软件，并且这些软件会在每次管道执行时保留下来。自托管代理可以运行在 Windows、Linux、macOS 或 Docker 容器中。
Microsoft 托管代理
Microsoft 托管代理是为您的管道定义代理的最简单方式。Azure Pipelines 默认提供一个名为Azure Pipelines的 Microsoft 托管代理池：
图 4.6 – Azure Pipelines 默认代理池
通过选择这个代理池，您可以为执行管道创建不同类型的虚拟机。截止到本文写作时，可用的标准代理类型如下：
https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Table_1.1.jpg
表 1.1
每个镜像都具有一套自动安装的软件。您可以通过在管道定义中使用预定义的工具安装程序任务来安装额外的工具。更多信息请参阅：
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops#tool.
当使用 Microsoft 托管代理创建管道时，您只需要从前面的表格中指定要为代理使用的虚拟机镜像的名称。例如，这是使用 Windows Server 2019 和 Visual Studio 2019 镜像的托管代理定义：
- job: Windows
pool:
vmImage: 'windows-latest'
使用 Microsoft 托管代理时，您需要记住以下几点：
-
您不能在代理机器上登录。
-
该代理运行在标准 DS2v2 Azure 虚拟机上，且无法增加该容量。
-
它以管理员用户身份在 Windows 平台上运行，并以 无密码 sudo 用户身份在 Linux 平台上运行。
-
对于公共项目，您有 10 个免费的 Microsoft 托管并行作业，每个作业最多可运行 360 分钟，每月没有总体时间限制。
-
对于私人项目，您有一个免费的并行作业，每个作业最多可运行 60 分钟，每月最多为 1,800 分钟（30 小时）。如果您需要更多的容量，可以支付额外的并行作业费用。这样，每个作业的运行时间最多为 360 分钟。
-
Microsoft 托管代理运行在与您的 Azure DevOps 组织相同的 Azure 地理区域内，但不能保证它也会在相同的区域内运行（一个 Azure 地理区域包含一个或多个区域）。
自托管代理
虽然 Microsoft 托管代理是一个 SaaS 服务，但自托管代理是私有代理，您可以通过使用 Azure 虚拟机或直接使用本地基础设施来根据您的需求进行配置。您负责提供执行管道所需的所有软件和工具，并负责维护和升级代理。
自托管代理可以安装在以下平台上：
-
Windows
-
Linux
-
macOS
-
Docker
创建自托管代理包括完成以下活动：
-
准备环境
-
在 Azure DevOps 上准备权限
-
下载并配置代理
-
启动代理
这些步骤在所有环境中是相似的。接下来，我们将学习如何创建自托管 Windows 代理。
创建自托管 Windows 代理
自托管 Windows 代理用于构建和部署基于 Microsoft 平台（如 .NET 应用程序、Azure 云应用程序等）构建的应用程序，也可用于其他平台类型，如 Java 和 Android 应用程序。
创建代理时执行的第一步是将代理注册到您的 Azure DevOps 组织中。为此，您需要以管理员身份登录到您的 DevOps 组织，并从 用户设置 菜单中点击 个人访问令牌：
图 4.7 – 个人访问令牌
在这里，您可以为您的组织创建一个新的个人访问令牌，设置过期日期，并选择完全访问或自定义定义的访问级别（如果选择自定义定义范围，您需要为每个范围选择所需的权限）。要查看可用范围的完整列表，请点击窗口底部的 显示所有范围 链接：
图 4.8 – 创建一个新的个人访问令牌
请确保 代理池 范围内启用了 读取和管理 权限。
完成后，点击 创建，然后在关闭窗口之前复制生成的令牌（它只会显示一次）。
重要提示
用于代理的用户必须具备注册代理的权限。你可以通过进入组织设置 | 代理池，选择默认池并点击安全来检查此权限。
现在，你需要下载代理软件并进行配置。从组织设置 | 代理池，选择默认池，在代理选项卡中点击新建代理：
图 4.9 – 创建新代理
获取代理窗口将打开。选择Windows作为目标平台，根据你的目标代理平台（机器），选择x64或x86，然后点击下载按钮：
图 4.10 – 代理软件下载页面
这个过程将下载一个包（通常名为vsts-agent-win-x64-2.166.4.zip）。你需要在代理机器（一个 Azure 虚拟机或本地服务器，它将作为你的构建代理）上运行这个包（config.cmd）：
图 4.11 – 代理软件包
设置将要求你输入以下内容：
-
你的 Azure DevOps 组织的 URL（
dev.azure.com/{your-organization}） -
使用的个人访问令牌（之前创建的）
运行代理时（无论是交互式运行还是作为服务运行），如果你想自动化构建，建议将其作为服务运行。
输入这些参数后，设置将注册代理：
图 4.12 – 代理注册
要注册代理，你需要插入代理池、代理名称和工作文件夹（你可以保持默认值不变）。
最后，你需要决定是否让代理以交互式或作为服务的方式运行。正如我们之前提到的，建议将代理作为服务运行，但在很多情况下，交互式选项也很有帮助，因为它会给你一个控制台，便于查看状态并运行 UI 测试。
在这两种情况下，请注意你为运行代理所选择的用户帐户。默认帐户是内置的网络服务用户，但该用户通常没有本地文件夹的所有必需权限。使用管理员帐户可以帮助解决很多问题。
如果设置成功，你应该能看到在代理机器上运行的服务，并且在 Azure DevOps 中的代理池中弹出一个新代理：
4.13 – 新代理创建
如果你选择代理后进入功能部分，你将能够看到它的所有功能（操作系统版本、操作系统架构、计算机名称、已安装的软件等）：
图 4.14 – 代理功能
代理的能力可以通过代理软件自动发现，或者如果你点击添加新能力操作，你也可以由用户定义能力。能力被流水线引擎用于根据流水线所需的能力（需求）将特定构建重定向到正确的代理。
当代理在线时，它准备好接受你的代码构建，这些构建应该排队等待。
记住，你还可以在同一台机器上安装多个代理（例如，如果你希望能够执行核心流水线或并行处理任务），但这种情况仅建议在代理不共享资源时使用。
何时使用微软托管代理或自托管代理
微软托管代理通常在你有一个标准的代码库，且不需要特定软件或环境配置来构建代码时非常有用。如果你处于这种情况，建议使用微软托管代理，因为你不必担心创建环境。例如，如果你需要构建一个 Azure Function 项目，通常你不需要在构建代理上安装自定义软件，微软托管代理可以完美工作。
自托管代理是在需要特定环境配置时的最佳选择，尤其是当你需要在代理上安装特定的软件或工具，或者需要更强大的构建能力时。自托管代理也是在你需要在每次构建运行之间保持环境一致性时的理想选择。通常，当你需要更好地控制代理，或者希望将构建部署到本地环境（外部不可访问）时，自托管代理是正确的选择。它通常还可以帮助你节省成本。
现在我们已经讨论了可以用于构建流水线的可能代理，在接下来的部分中，我们将概述 YAML，这种脚本语言允许你定义流水线。
YAML 语言概述
YAML，即YAML 不是标记语言，是一种可读性强的脚本语言，通常用于数据序列化和处理应用程序配置定义。它可以视为 JSON 的超集。
YAML 使用缩进来处理对象定义的结构，并且对引号和大括号不敏感。它仅仅是一种数据表示语言，不能用于执行命令。
在 Azure DevOps 中，YAML 至关重要，因为它允许你通过使用脚本定义来定义流水线，而不是使用图形界面（图形界面无法在项目之间迁移）。
官方 YAML 网站可以在这里找到：
YAML 结构是基于键值元素的：
Key: Value # 这是一个注释
在接下来的部分中，我们将学习如何在 YAML 中定义对象。
标量
例如，以下是已在 YAML 中定义的标量变量：
Number: 1975 quotedText: "some text description"notQuotedtext: strings can be also without quotes boolean: true nullKeyValue: null
你也可以通过使用 ?，后跟一个空格来定义多行键，如下所示：
? |
This is a key
that has multiple lines
: and this is its value
集合和列表
这是一个用于集合对象的 YAML 定义：
Cars:
- Fiat
- Mercedes
- BMW
你还可以定义嵌套的集合：
- Drivers:
name: Stefano Demiliani
age: 45
Driving license type:
- type: full car license
license id: ABC12345
expiry date: 2025-12-31
字典
你可以通过以下方式使用 YAML 定义一个 Dictionary 对象：
CarDetails:
make: Mercedes
model: GLC220
fuel: Gasoline
文档结构
YAML 使用三个破折号 --- 来分隔指令和文档内容，并标识文档的开始。例如，以下 YAML 定义了一个文件中的两个文档：
---# Products purchased
- item : Surface Book 2
quantity: 1
- item : Surface Pro 7
quantity: 3
- item : Arc Mouse
quantity: 1
# Product out of stock
---
- item : Surface 4
- item : Microsoft Trackball
复杂对象定义
作为定义复杂对象的示例，以下是 Invoice 对象使用的表示方式：
---
invoice: 20-198754
date : 2020-05-27
bill-to: C002456
Name : Stefano Demiliani
address:
lines:
Viale Pasubio, 21
c/o Microsoft House
city : Milan
state : MI
postal : 20154
ship-to: C002456
product:
- itemNo : ITEM001
quantity : 1
description : Surface Book 2
price : 1850.00
- sku : ITEM002
quantity : 2
description : Arc Mouse
price : 65.00
tax : 80.50
total: 1995.50
comments:
Please deliver on office hours.
Leave on the reception.
现在我们已经简要概述了 YAML 语法，接下来的章节中，我们将学习如何使用 Azure DevOps 创建构建管道。
使用 Azure DevOps 创建构建管道
如果你想为代码实现持续集成（在每次提交时自动构建和测试代码），那么拥有一个构建管道是基础步骤。
使用 Azure DevOps 创建构建管道的前提条件显然是代码已经存储在一个仓库中。
要使用 Azure DevOps 创建构建管道，你需要进入 管道 中心并选择 管道 操作：
图 4.15 – 构建管道创建
在这里，你可以通过选择 新建管道 按钮来创建一个新的构建管道。当点击此按钮时，你将看到以下界面，它会询问你代码仓库的信息：
图 4.16 – 选择一个仓库
这个屏幕非常重要。通过这个界面，你可以以两种可能的方式开始创建构建管道（如前所述）：
-
使用 YAML 文件来创建你的管道定义。这是在此窗口中选择仓库时发生的事情。
-
使用经典编辑器（图形用户界面）。这是当你点击页面底部的 使用经典编辑器 链接时发生的事情。
在接下来的章节中，我们将学习如何通过这两种方法创建构建管道。
使用经典编辑器定义管道
经典编辑器允许你通过选择预定义的操作图形化地定义项目的构建管道。如前所述，使用这种方式创建的管道定义不在源代码管理之下。
当你点击 使用经典编辑器 链接时，你需要选择存储代码的仓库（Azure Repos Git、GitHub、GitHub Enterprise Server、Subversion、TFVC、Bitbucket Cloud 或 其他 Git）以及构建管道将连接的分支：
图 4.17 – 经典编辑器管道定义
然后，您需要选择一个适合您正在构建的应用程序类型的模板。您可以选择一组预定义的模板（稍后可以自定义），也可以从空模板开始：
图 4.18 – 管道模板选择
如果预定义模板满足您的需求，您可以直接使用它们；否则，建议通过选择所需的操作创建自定义管道。
在这里，我的应用程序存储在 Azure DevOps 项目仓库中，是一个 ASP.NET Web 应用程序（一个名为 PartsUnlimited 的电子商务网站项目；您可以在以下网址找到公共仓库：github.com/Microsoft/PartsUnlimited），因此我选择了 ASP.NET 模板。
选择后，这是将自动为您创建的管道模板：
图 4.19 – 从模板创建的管道
让我们详细查看管道的每个部分。
该管道（在这里叫做 PartsUnlimited-demo-pipeline）基于vs2017-win2016模板（Windows Server 2016 和 Visual Studio 2017），在 Microsoft 托管的代理（Azure Pipelines 代理池）上运行，如下截图所示：
图 4.20 – 管道中的代理规格
代理作业首先安装 NuGet 包管理器，并还原所需的包，以便在所选仓库中构建项目。对于这些操作，管道定义包含了您在以下截图中看到的任务：
图 4.21 – NuGet 任务
然后，有一个用于构建解决方案的任务：
图 4.22 – 构建解决方案任务
还有一个用于测试解决方案并发布测试结果的任务：
图 4.23 – 测试程序集任务
最后的步骤是将构建过程的源代码作为构件（构建输出）发布：
图 4.24 – 发布任务
如果选择变量选项卡，您将看到在构建过程中使用的一些参数。在这里，您可以创建自己的变量，在需要时在管道中使用：
图 4.25 – 管道变量
下一部分叫做触发器。在这里，您可以定义启动管道的触发条件。默认情况下，初始时没有发布任何触发器，但在这里，您可以启用 CI，以便在所选分支的每次提交时自动启动管道：
图 4.26 – 管道触发器
重要说明
启用 CI 是推荐的做法，如果您希望每次在分支（例如，master 分支）上提交的代码都能得到测试并安全控制。在这种方式下，您可以确保代码始终按预期工作。
在选项选项卡中，您可以设置与构建定义相关的一些选项。例如，在这里，您可以创建指向所有工作项的链接，以便在构建成功完成时，它们与相关的更改进行关联，构建失败时创建工作项，设置管道的状态徽章，指定超时等：
图 4.27 – 管道选项
保留选项卡则用于配置该特定管道的保留策略（例如，保持工件多少天，保持运行和拉取请求多少天等）。这样做会覆盖一般的保留设置。我们将在后面的构建的保留部分讨论这些内容。
完成管道定义后，您可以点击保存并排队以保存定义。点击保存并运行时，管道将被放入队列并等待代理：
图 4.28 – 运行管道
当找到代理时，管道会被执行，您的代码将被构建：
图 4.29 – 管道执行开始
您可以跟踪管道每个步骤的执行，并查看相关日志。如果管道成功结束，您可以查看其执行摘要：
图 4.30 – 管道 – 最终结果
您还可以选择测试选项卡以查看测试执行状态：
图 4.31 – 管道测试结果
在下一部分，我们将学习如何为这个应用创建一个 YAML 管道。
YAML 管道定义
如前所述，当您开始使用 Azure DevOps 创建构建管道时，向导默认会创建一个基于 YAML 的管道。
要开始创建 YAML 管道，请转到 Azure DevOps 中的管道部分，并点击新建管道。
在这里，您可以选择仓库类型，而不是像我们在上一部分中那样选择经典编辑器（Azure Repos Git、GitHub、BitBucket等）：
图 4.32 – YAML 管道定义
然后，从可用的仓库列表中选择您的仓库：
图 4.33 – YAML 管道 – 仓库选择
系统现在分析您的代码库，并根据代码库中存储的代码推荐一组可用的模板。您可以从一个空白的 YAML 模板开始，也可以选择一个模板。在这里，我选择了 ASP.NET 模板：
图 4.34 – YAML 管道 – 模板选择
系统创建了一个 YAML 文件（称为 azure-pipelines.yml），如以下截图所示：
图 4.35 – YAML 管道定义
生成的 YAML 定义包含了一组任务，就像前面的例子一样，但在这里，这些任务在它们的 YAML 定义中。完整的生成文件如下所示：
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
inputs:
restoreSolution: '$(solution)'
- task: VSBuild@1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: VSTest@2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
Here I add two more tasks for publishing the symbols and the final artifacts of the pipeline:
task: PublishSymbols@2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: PublishBuildArtifacts@1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Parameters.ArtifactName)'
condition: succeededOrFailed()
如您所见，YAML 文件包含了触发器，它启动管道（在这里是主分支上的提交），使用的代理池，管道变量，以及每个任务执行的顺序（带有其特定参数）。
如前所示，点击“保存并运行”以排队执行管道。以下截图显示了已执行的 YAML 管道。
图 4.36 – 已执行的 YAML 管道
若要添加新任务，可以使用编辑框右侧的助手工具。它允许您拥有一个任务列表，您可以在其中搜索任务，填写必要的参数，然后获得最终的 YAML 定义：
图 4.37 – YAML 管道任务选择
当您选择使用 YAML 创建管道时，Azure DevOps 会创建一个文件，并将其存储在与您的代码相同的代码库中：
图 4.38 – 创建的 YAML 管道文件
此文件在源代码管理中，并在每次修改时版本化。
有关管道 YAML 模式的完整参考，我建议访问以下链接：
构建保留
当您运行管道时，Azure DevOps 会记录每个步骤的执行，并存储每次运行的最终工件和测试。
Azure DevOps 对管道执行的默认保留策略为 30 天。您可以通过进入项目设置 | 管道 | 设置来更改这些默认值：
图 4.39 – 管道保留策略
您还可以使用复制文件任务将构建和工件数据存储到外部存储中，以便您可以将它们保存比保留策略中指定的时间更长：
图 4.40 – 复制文件任务
该任务的 YAML 定义如下：
- task: CopyFiles@2
displayName: 'Copy files to shared network'
inputs:
SourceFolder: '$(Build.SourcesDirectory)'
Contents: '**'
TargetFolder: '\\networkserver\storage\$(Build.BuildNumber)'
重要说明
请记住，任何通过发布构建工件任务保存的数据都会定期删除。
更多关于复制文件任务的信息可以在这里找到：
docs.microsoft.com/zh-cn/azure/devops/pipelines/tasks/utility/copy-files?view=azure-devops&tabs=yaml。
多阶段流水线
正如我们之前解释的，你可以将流水线中的工作组织成 stages。Stages 是流水线流中的逻辑边界（可以分配给代理的工作单元），它们允许你隔离工作、暂停流水线并执行检查或其他操作。默认情况下，每个流水线由一个阶段组成，但你可以创建多个阶段并将这些阶段安排成依赖关系图。
多阶段流水线的基本 YAML 定义如下：
stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Build!
- stage: Test
jobs:
- job: TestOne
steps:
- script: echo Test 1
- job: TestTwo
steps:
- script: echo Test 2
- stage: Deploy
jobs:
- job: Deploy
steps:
- script: echo Deployment
作为如何使用 YAML 创建多阶段流水线的示例，让我们来看一个在你的代码库中构建代码（使用 .NET Core SDK）并将工件发布为 NuGet 包的流水线。流水线定义如下。该流水线使用 stages 关键字来标识这是一个多阶段流水线。
在第一个阶段定义（Build）中，我们有构建代码的任务：
trigger:
- master
stages:
- stage: 'Build'
variables:
buildConfiguration: 'Release'
jobs:
- job:
pool:
vmImage: 'ubuntu-latest'
workspace:
clean: all
steps:
- task: UseDotNet@2
displayName: 'Use .NET Core SDK'
inputs:
packageType: sdk
version: 2.2.x
installationPath: $(Agent.ToolsDirectory)/dotnet
- task: DotNetCoreCLI@2
displayName: "NuGet Restore"
inputs:
command: restore
projects: '**/*.csproj'
- task: DotNetCoreCLI@2
displayName: "Build Solution"
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration (buildConfiguration)'
在这里，我们使用了 Azure DevOps 中提供的UseDotnet标准任务模板安装了 .NET Core SDK（更多信息请参见：docs.microsoft.com/zh-cn/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer?view=azure-devops)）。之后，我们恢复了所需的 NuGet 包并构建了解决方案。
现在，我们有创建 NuGet 包发布版本的任务。该包保存在工件暂存目录的 packages/release 文件夹中。在此任务中，我们将使用 nobuild = true，因为在此任务中，我们无需重新构建解决方案（无需再进行编译）：
- task: DotNetCoreCLI@2
displayName: 'Create NuGet Package - Release Version'
inputs:
command: pack
packDirectory: '$(Build.ArtifactStagingDirectory)/packages/releases'
arguments: '--configuration $(buildConfiguration)'
nobuild: true
下一步，我们需要创建 NuGet 包的预发布版本。在此任务中，我们使用 buildProperties 选项将构建号添加到包版本中（例如，如果包版本是 2.0.0.0，构建号是 20200521.1，则包版本为 2.0.0.0.20200521.1）。在这里，构建包是强制性的（用于获取构建 ID）：
- task: DotNetCoreCLI@2
displayName: 'Create NuGet Package - Prerelease Version'
inputs:
command: pack
buildProperties: 'VersionSuffix="$(Build.BuildNumber)"'
packDirectory: '$(Build.ArtifactStagingDirectory)/packages/prereleases'
arguments: '--configuration $(buildConfiguration)'
下一个任务将包作为工件发布：
- publish: '$(Build.ArtifactStagingDirectory)/packages'
artifact: 'packages'
接下来，我们需要定义第二个阶段，称为 PublishPrereleaseNuGetPackage。在这里，我们跳过了代码库的检出步骤，下载步骤下载了我们在先前构建阶段发布的 packages 工件。然后，NuGetCommand 任务将预发布包发布到 Azure DevOps 中的一个名为 Test 的内部源：
- stage: 'PublishPrereleaseNuGetPackage'
displayName: 'Publish Prerelease NuGet Package'
dependsOn: 'Build'
condition: succeeded()
jobs:
- job:
pool:
vmImage: 'ubuntu-latest'
steps:
- checkout: none
- download: current
artifact: 'packages'
- task: NuGetCommand@2
displayName: 'Push NuGet Package'
inputs:
command: 'push'
packagesToPush: '$(Pipeline.Workspace)/packages/prereleases/*.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: 'Test'
现在，我们必须定义第三个阶段，叫做 PublishReleaseNuGetPackage，它用于为 NuGet 创建我们的包的发布版本：
- stage: 'PublishReleaseNuGetPackage'
displayName: 'Publish Release NuGet Package'
dependsOn: 'PublishPrereleaseNuGetPackage'
condition: succeeded()
jobs:
- deployment:
pool:
vmImage: 'ubuntu-latest'
environment: 'nuget-org'
strategy:
runOnce:
deploy:
steps:
- task: NuGetCommand@2
displayName: 'Push NuGet Package'
inputs:
command: 'push'
packagesToPush: '$(Pipeline.Workspace)/packages/releases/*.nupkg'
nuGetFeedType: 'external'
publishFeedCredentials: 'NuGet'
这个阶段使用一个部署任务将包发布到配置好的环境中（在此，我们称之为 nuget-org）。环境是管道内的一组资源。
在 NuGetCommand 任务中，我们指定要推送的包，并且我们推送包的源是外部的（nuGetFeedType）。该源通过使用 publishFeedCredentials 属性检索，该属性设置为我们创建的服务连接的名称。
对于这个阶段，我们已经创建了一个新的环境：
图 4.41 – 创建新的环境
一旦创建了环境，为了将其发布到 NuGet，您需要通过以下步骤创建一个新的服务连接：进入 项目设置 | 服务连接 | 创建服务连接，从可用的服务连接类型列表中选择 NuGet，然后根据您的 NuGet 帐户配置连接：
图 4.42 – 新的 NuGet 服务连接
通过这一方式，我们创建了一个多阶段构建管道。当管道执行并且所有阶段成功完成时，您将看到一个如下所示的结果图：
图 4.43 – 多阶段构建管道执行情况
现在我们已经理解了什么是多阶段管道，我们将在下一节创建一些与 GitHub 仓库相关的管道。
使用 GitHub 仓库构建管道
GitHub 是最流行的源代码管理平台之一，通常，我们会遇到将代码存储在 GitHub 仓库中，并且希望使用 Azure DevOps 来管理 CI/CD 的场景。
通过使用 Azure DevOps 和 Azure Pipeline 服务，您还可以为存储在 GitHub 上的仓库创建管道，从而在 GitHub 仓库中的每次提交时触发构建管道。我们将通过以下步骤实现这一点：
-
要使用 Azure Pipelines 构建您的 GitHub 仓库，您需要添加
Azure Pipelines。选择 Azure Pipelines 扩展，并点击 设置计划，如以下截图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_04_044.jpg图 4.44 – GitHub 上的 Azure Pipelines – 设置
-
选择 免费 计划，点击 免费安装 按钮，然后点击 完成订单并开始安装。
-
现在，Azure Pipelines 安装将询问您是否希望此应用程序对所有仓库可用，还是仅对选定的仓库可用。选择所需的选项并点击 安装：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_04_045.jpg
图 4.45 – GitHub 上的 Azure Pipelines – 安装
-
你将被重定向到 Azure DevOps，在那里你可以创建一个新项目（或选择一个现有项目）来处理构建过程。在这里，我将创建一个新项目：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_04_046.jpg
图 4.46 – 设置 Azure Pipelines 项目
-
现在，你需要授权 Azure Pipelines 以便它可以访问你的 GitHub 账户：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_04_047.jpg
图 4.47 – 授权 Azure Pipelines 访问 GitHub
当获得必要的授权后，项目将在 Azure DevOps 上为你创建，管道创建过程将开始。你将立即被提示从你账户中的可用 GitHub 仓库列表中选择一个 GitHub 仓库作为构建来源：
图 4.48 – 选择 GitHub 仓库
-
在这里，我选择了一个包含 Azure Function 项目的仓库。正如你所见，Azure Pipelines 已经识别了我的项目，并为管道提供了一组可用的模板（但你也可以从空白模板开始，或者从仓库中任何分支的 YAML 文件开始）。在这里，我将选择 GitHub 仓库中的
azure-pipelines.yml）:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_04_050.jpg图 4.50 – 多阶段 YAML 管道定义
该管道会在每次提交到主分支时触发。
-
点击保存并运行按钮。在这里，管道将被排队并等待代理，然后执行。
每次你在 GitHub 仓库中提交代码时，Azure DevOps 上的构建管道将会自动触发。
如果你正在构建一个公共 GitHub 仓库，展示所有用户该仓库中的代码已经通过构建管道检查和测试是非常有用的。然后，你可以展示构建结果。你可以通过在仓库中放置一个徽章来做到这一点。
徽章是一个动态生成的图像，反映构建的状态（未构建、成功或失败），并托管在 Azure DevOps 上。
-
为此，选择 Azure DevOps 中的管道，点击右侧的三个点，并选择状态徽章：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_04_051.jpg
图 4.51 – 状态徽章定义
-
从这里，你可以复制 GitHub 仓库中的
Readme.md文件：
图 4.52 – 构建状态徽章的 Markdown
每当用户访问你的仓库时，他们将能够通过图形徽章查看最新构建的状态：
图 4.53 – 构建管道状态徽章
接下来，让我们看看如何并行执行作业。
在 Azure Pipelines 中并行执行作业
在 Azure 管道中，您还可以并行执行作业。每个作业可以独立于其他作业运行，也可以在不同的代理上执行。这将帮助您加速构建时间并提升管道的性能。
作为如何在管道中处理并行作业的示例，考虑一个简单的管道，您需要执行三个 PowerShell 脚本，分别叫做 任务 1、任务 2 和 最终任务。任务 1 和 任务 2 可以并行执行，而 最终任务 只有在前两个任务完成后才能执行。
当您开始创建一个新的管道时（这里为了简便，我使用经典编辑器），Azure DevOps 会创建一个代理作业（这里称为 代理作业 1）。您可以将任务添加到此代理中。通过选择代理作业，您可以指定运行该任务的代理池。在这里，我希望此任务在 Microsoft 托管的代理池中执行：
图 4.54 – 代理规格
然后，要将新的代理池添加到管道中（用于独立执行其他任务），请点击管道旁边的三个点，选择 添加代理作业：
图 4.55 – 添加代理作业
现在，我们将添加一个第二个代理作业（这里称为 代理作业 2），它运行在自托管代理上。此作业将执行 任务 2 PowerShell 脚本：
图 4.56 – 代理选择
最后，我们将添加一个新的代理作业（这里称为 代理作业 3），用于执行 最终任务，该任务将运行在 Microsoft 托管的代理上。然而，此作业有来自 代理作业 1 和 代理作业 2 的依赖：
图 4.57 – 代理作业依赖关系
通过这种方式，前两个任务将并行启动，最终作业将在前两个任务执行完成后再运行。
若要了解有关 Azure 管道中并行作业的更多信息，我建议查看以下页面：
docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml
运行在 Azure 容器实例上的代理
如果标准的 Microsoft 托管代理无法满足您的需求（如要求、性能等），您还可以为 Azure DevOps 创建一个自托管代理，运行在 Azure 容器实例 (ACI) 服务的 Docker 容器内。
您可以通过使用自定义镜像或重用 Microsoft 提供的镜像来创建一个运行在 Azure 容器实例上的构建代理。
要创建一个运行在 ACI 上的构建代理，您需要为您的 Azure DevOps 组织创建一个 个人访问令牌。为此，您需要从 Azure DevOps 组织的首页打开用户设置（右上角），并选择 个人访问令牌。
当您拥有代理的个人访问令牌时，您可以通过执行以下 Azure CLI 命令（在连接到您的 Azure 订阅后）在 ACI 上创建代理：
az container create -g RESOURCE_GROUP_NAME -n CONTAINER_NAME --image mcr.microsoft.com/azure-pipelines/vsts-agent --cpu 1 --memory 7 --environment-variables VSTS_ACCOUNT=AZURE_DEVOPS_ACCOUNT_NAME VSTS_TOKEN=PERSONAL_ACCESS_TOKEN VSTS_AGENT=AGENT_NAME VSTS_POOL=Default
这里，我们有如下内容：
-
RESOURCE_GROUP_NAME是您在 Azure 中用于创建此资源的资源组名称。 -
CONTAINER_NAME是 ACI 容器的名称。 -
AZURE_DEVOPS_ACCOUNT_NAME是您的 Azure DevOps 账户名称。 -
PERSONAL_ACCESS_TOKEN是您之前创建的个人访问令牌。 -
AGENT_NAME是您要创建的构建代理的名称。该名称将在 Azure DevOps 中显示。
在此命令中，还有另外两个重要的参数：
-
--image用于选择用于创建代理的 Azure Pipelines 镜像的名称，具体说明请见：hub.docker.com/_/microsoft-azure-pipelines-vsts-agent。 -
VSTS_POOL用于选择您的构建代理的代理池。
请记住，您可以通过使用 az container stop 和 az container start 命令来启动和停止 ACI 实例。这可以帮助您节省费用。
在 Azure Pipelines 中使用容器作业
在本章中，我们看到，当您创建流水线时，您定义了作业，而当流水线执行时，这些作业会在安装了代理的主机上运行。
如果您使用的是 Windows 或 Linux 代理，您也可以在容器中运行作业（与主机隔离）。要在容器中运行作业，您需要在代理上安装 Docker，并且流水线必须有权限访问 Docker 守护进程。如果您使用的是 Microsoft 托管的代理，实际上支持在 windows-2019 和 ubuntu-16.04 池镜像上运行容器中的作业。
作为示例，这是在 Windows 流水线中使用容器作业的 YAML 定义：
pool:
vmImage: 'windows-2019'
container: mcr.microsoft.com/windows/servercore:ltsc2019
steps:
- script: date /t
displayName: Gets the current date
- script: dir
workingDirectory: $(Agent.BuildiDirectory)
displayName: list the content of a folder
如前所述，要在 Windows 容器中运行作业，您需要使用 windows-2019 镜像池。要求主机和容器的内核版本匹配，因此这里我们使用 ltsc2019 标签来获取容器的镜像。
对于基于 Linux 的流水线，您需要使用 ubuntu-16.04 镜像：
pool:
vmImage: 'ubuntu-16.04'
container: ubuntu:16.04
steps:
- script: printenv
如您所见，流水线基于选定的镜像创建一个容器，并在该容器内运行命令（步骤）。
摘要
在本章中，我们提供了 Azure Pipelines 服务的概述，并展示了如何通过使用 Azure DevOps 实现 CI/CD 流程。我们还演示了如何通过图形界面和 YAML 创建一个针对托管在仓库中的代码的流水线，以及如何使用和创建构建代理。接着，我们介绍了如何使用经典编辑器和 YAML 定义创建构建流水线。我们还展示了一个多阶段流水线的示例，以及如何使用 Azure DevOps 流水线在 GitHub 仓库中构建代码，然后讲解了如何在构建流水线中使用并行任务来提高构建性能。最后，我们学习了如何在 Azure 容器实例上创建构建代理，并如何使用容器的作业。
在下一章中，我们将学习如何在构建流水线中执行代码库的质量测试。
第五章：
第六章：在构建管道中运行质量测试
在上一章中，我们介绍了 Azure Pipelines，并学习了如何使用 Azure DevOps、GitHub 和容器实现 CI/CD 流程。
在本章中，我们将讲解如何在构建管道中运行质量测试。我们将首先解释自动化测试的好处。接着，我们将探讨如何在构建管道中运行单元测试，如何进行代码覆盖测试，以及如何查看测试结果。最后，我们将介绍如何使用特性标志在生产环境中测试代码。
本章将涵盖以下主题：
-
自动化测试的好处
-
单元测试介绍
-
在构建管道中运行单元测试
-
代码覆盖测试介绍
-
执行代码覆盖测试
-
将测试结果分配给工作项
-
特性标志介绍
-
使用特性标志在生产环境中测试
技术要求
要跟随本章内容，您需要有一个活跃的 Azure DevOps 组织。本章将使用的组织名为 Parts Unlimited 组织，它是在第一章**，Azure DevOps 概述中创建的。您还需要安装 Visual Studio 2019，可以从visualstudio.microsoft.com/downloads/下载。为了获得最新的演示，您需要安装 Visual Studio Code 并配置 C#扩展，以及安装.NET Core SDK 版本 3.1 或更高版本。
我们的示例应用程序的源代码可以从以下链接下载：
github.com/PacktPublishing/Learning-Azure-DevOps---B16392/tree/master/Chapter%205/RazorFeatureFlags
自动化测试的好处
在为应用程序添加新功能后，您希望知道它是否能够在所有可能的交互情况下正确运行。您还希望确保这个新功能不会破坏其他功能，并希望知道代码是否容易理解且可维护。
所有这些都可以手动测试。但是随着项目和代码库的不断增长，手动测试所有这些功能可能会变得重复且容易出错。这时，自动化测试就显得至关重要。
关于自动化测试一直存在许多争议。很多人认为测试创建和维护成本过高。的确，当测试创建不当时，这种观点是成立的。但如果自动化测试得当，它将大大降低与频繁手动测试或发布低质量软件相比的时间和成本。通过使用自动化测试，您的项目将能够更频繁地发布软件。它可以重复使用并反复运行，为团队提供更快的结果和反馈。问题越早被发现，修复的成本就越低。
与 CI 配合使用时，代码会自动推送到生产环境，自动测试将帮助团队避免在软件中发布漏洞。然而，这也有权衡。开发人员需要投入更多时间来编写和维护测试代码。然而，通过投入这额外的时间，最终的结果将是更高质量的代码，并且这些代码已经经过验证，能够完全按预期运行。
你可以执行不同类型的自动化测试；例如，你可以运行回归测试、验收测试和安全性测试。在本章中，我们将重点介绍开发测试，这也是 CI 中使用的，可以直接从构建流水线中完成。
Visual Studio 和 Azure DevOps 都提供了测试功能。它们与测试框架无关，因此你可以插入自己的框架并引入第三方工具。你可以轻松地添加测试适配器以便运行测试并查看结果。这可以使测试成为你日常软件构建过程的一部分。
在接下来的章节中，我们将介绍单元测试和代码覆盖率测试，这些都是开发测试的一部分。首先，我们将描述如何从构建流水线中运行自动单元测试，然后介绍如何从构建流水线中进行代码覆盖率测试和 UI 测试。
单元测试简介
使用单元测试，你将代码拆分成小块，称为单元，这些单元可以独立地进行测试。这些单元可以是类、方法或单行代码。这里越小越好。这样可以让你更好地了解代码的表现，并且测试可以快速运行。
在大多数情况下，单元测试是由编写代码的开发人员来编写的。编写单元测试有两种不同的方式：在编写实际的生产代码之前，或者之后。大多数程序员是在事后编写的，这是一种传统的做法，但如果你使用的是测试驱动开发（TDD），你通常会在之前编写单元测试。单元测试还可以使代码文档变得更容易。它鼓励更好的编码实践，你可以在代码中留下描述代码功能的部分。这里，你将更多地关注更新检查系统。
在接下来的部分中，我们将介绍如何在构建流水线中运行单元测试。
在构建流水线中运行单元测试
我们的Parts Unlimited测试项目已经创建了单元测试。因此，这是进行演示的一个好选择。首先，我们将查看应用程序和已创建的测试。因此，我们需要将仓库克隆到本地文件系统并在 Visual Studio 中打开解决方案。
下载源代码
我们将为 Parts Unlimited 的 Web 应用程序创建单元测试。首先，我们需要将仓库从 Azure DevOps 克隆到本地文件系统。这将允许我们使用 Visual Studio Code 添加单元测试。因此，我们必须执行以下步骤：
-
打开网页浏览器，访问
dev.azure.com/。 -
使用您的 Microsoft 帐户登录并选择Parts.Unlimited项目。然后，从左侧菜单中选择Repos。这样您就可以导航到项目的源代码。
-
从右上角菜单中，选择克隆：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_001.jpg
图 5.1 – 搜索结果
-
在下一个屏幕上，确保选择了在 Visual Studio 中克隆，然后点击如下所示的按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_002.jpg
图 5.2 – 克隆仓库
-
现在，Visual Studio 将会打开。在这里，我们将简要查看已经存在于项目中的测试类。为此，请打开解决方案资源管理器窗口，并导航至test > PartsUnlimited.UnitTests：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_003.jpg
图 5.3 – 单元测试项目
-
该项目中有不同的测试项目。花些时间熟悉一下实际测试的内容。这里使用的是 Visual Studio 的默认测试框架，即MS Test。
-
在 Visual Studio 中，您可以构建并运行应用程序。为此，请按F5。或者，从顶部菜单中选择调试 > 开始调试：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_004.jpg
图 5.4 – 单元测试项目
-
一旦项目构建完成，网站将如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_005.jpg
图 5.5 – 示例网站
-
返回 Visual Studio 并停止调试器。
现在一切都已正常工作，我们可以开始创建构建管道，其中包括运行单元测试项目。
创建管道
要创建管道，我们需要回到 Azure DevOps。在那里，按照以下步骤操作：
-
从左侧菜单中，选择管道（Pipelines）。
-
在屏幕右上角，找到并点击新建管道：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_006.jpg
图 5.6 – 创建新管道
-
创建构建管道的向导将会出现。在第一个屏幕上，选择使用经典编辑器，以使用设计器创建管道：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_007.jpg
图 5.7 – 使用经典设计器选项
-
在下一个屏幕上，确保选择了Azure Repos Git。保持默认设置不变，并点击继续：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_008.jpg
图 5.8 – 管道源设置
-
接下来，我们需要选择一个模板。从概览中选择ASP.NET，然后点击应用：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_009.jpg
图 5.9 – 选择 ASP.NET 模板
-
这样，流水线就会创建完成。默认情况下，流水线会添加各种任务。我们将在这里使用这些任务。在本次演示中，我们将重点关注测试程序集任务。点击此任务并确保选择版本2。在测试选择下，您将看到以下设置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_010.jpg
图 5.10 – 测试选择设置
-
默认情况下，在选择测试方式下会选择测试程序集。请保持选择此项。由于我们希望自动运行单元测试，这是我们需要选择的选项。单元测试通常存储在程序集内部。
-
此外，默认情况下，已经填充了一些程序集。如果需要，您可以更改它们。在本次演示中，我们将保持默认设置不变，因为任务会在不同的文件夹中查找包含
test的程序集。我们的测试项目名为PartsUnlimited.UnitTests，所以任务会自动找到该程序集。 -
搜索文件夹是用来搜索测试程序集的文件夹。在这种情况下，这是默认的工作目录。
-
测试结果文件夹是存储测试结果的地方。测试运行之前，结果目录将始终被清空。
-
我们现在准备运行测试。点击顶部菜单中的保存并排队，然后再次点击保存并排队子菜单项以执行构建流水线：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_011.jpg
图 5.11 – 执行构建流水线
-
运行流水线的向导将打开。在这里，您可以指定一个评论，然后选择代理池、代理规范以及您希望使用的分支/标签：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_012.jpg
图 5.12 – 运行流水线的参数
-
点击保存并运行以排队流水线。
将显示作业的概览页面，在这里您可以查看执行状态：
图 5.13 – 我们的作业概览
-
几分钟后，流水线将完成。从右上角的菜单中，点击测试与覆盖率，您将能够看到此构建的测试通过百分比。点击此处可查看测试结果（另外，您也可以通过点击左上角的测试菜单来查看：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_014.jpg
图 5.14 – 测试概览
-
在测试页面，您将看到测试数量，以及通过和失败的测试。您还可以看到运行的持续时间。
-
在屏幕底部，您可以按特定的测试进行筛选。例如，您可以筛选出通过、失败和中止的测试：
图 5.15 – 更详细的测试结果
在这个演示中，我们创建了一个包含自动单元测试的构建管道，用于我们的源代码。在下一部分，我们将探讨代码覆盖率测试。
代码覆盖率测试简介
通过代码覆盖率测试，你可以衡量应用程序的哪些源代码将被测试。代码覆盖率测试衡量的是在运行自动化测试（如单元测试）时，执行了多少行代码、代码块和类。
测试的代码越多，团队对其代码更改的信心就越大。通过查看代码覆盖率测试的结果，团队可以识别出哪些代码没有被这些测试覆盖。这些信息非常有用，因为它有助于随着时间推移减少测试负担。
Azure DevOps 支持从构建管道执行代码覆盖率测试。测试程序集任务允许我们收集代码覆盖率测试结果。还有一个独立的任务，称为发布代码覆盖率结果，它也可以发布这些结果。该任务对流行的覆盖率结果格式（如 Cobertura 和 JaCoCo）提供开箱即用的支持。
重要提示
Cobertura 和 JaCoCo 都是计算测试访问的代码百分比的 Java 工具。有关 Cobertura 的更多信息，请参考 cobertura.github.io/cobertura/。有关 JaCoCo 的更多信息，请参考 www.eclemma.org/jacoco/。
在下一部分，我们将讨论如何使用 Azure DevOps 执行代码覆盖率测试。
执行代码覆盖率测试
为了执行代码覆盖率测试，我们需要打开在前一演示中创建的构建管道。让我们开始吧：
-
打开构建管道后，选择右上角的编辑按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_016.jpg
图 5.16 – 编辑前一演示中的管道
-
导航到测试程序集任务以打开设置。
在执行设置中，勾选启用代码覆盖率框：
图 5.17 – 启用代码覆盖率测试
-
现在，
.coverage文件可以下载并用于在 Visual Studio 中进行进一步分析。 -
执行管道后，在构建概览页面上，选择
.coverage扩展名将被下载到你的本地文件系统。 -
双击下载的文件，这样它会在 Visual Studio 中打开。从这里，你可以深入查看不同的类和方法，获取测试结果的概览：
图 5.18 – Visual Studio 中的代码覆盖率测试结果
在这个演示中，我们从构建管道启用了代码覆盖率测试。在下一部分，我们将把这些测试结果分配到用户故事中。
将测试结果分配到工作项
一旦测试自动运行并且构建过程完成，你可以将结果分配给已添加到待办事项和冲刺中的工作项。为此，你需要执行以下步骤：
-
返回构建流水线，选择上次运行的流水线。在顶部菜单中点击测试。
-
对于结果表格，确保选中了已通过，并且已失败和已中止已被取消选择：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_019.jpg
图 5.19 – 选择所有通过的测试
-
然后，选择几个测试。完成后，在顶部菜单中点击链接：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_020.jpg
图 5.20 – 链接项目
-
搜索
作为测试人员并选择显示为搜索结果的工作项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_021.jpg图 5.21 – 选择工作项
-
点击关联以将工作项链接到测试结果。
-
现在，点击一个与工作项链接的测试结果。这将显示该项目的详细信息。在这里，你可以点击顶部菜单中的工作项，这将显示我们在前一步中链接的工作项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_022.jpg
图 5.22 – 链接的工作项
-
通过点击该工作项，你可以查看它的详细信息。
在本示范中，我们讲解了如何将测试结果链接到工作项。在接下来的部分，我们将讲解如何使用功能标志在生产环境中进行测试。
功能标志简介
你可以使用功能标志来打开或关闭代码中的功能，比如特定的方法或代码段。当你想在解决方案中隐藏（禁用）或公开（启用）某些功能时，这非常有帮助。尚未完成并准备发布的功能可以被隐藏或公开。这使得我们可以在生产环境中针对一部分用户进行代码测试。例如，你可以基于用户的登录名为一部分用户启用代码，并让他们在将功能发布给其他用户之前进行测试。然而，功能标志也有一个缺点：它们会增加代码的复杂性，因此最好限制应用程序中切换标志的数量。
创建功能标志时，推荐的方法是将它们保存在应用程序外部。例如，网页或应用配置文件是添加功能标志的好地方，因为你可以轻松更改它们，而无需重新部署应用程序。
在接下来的部分，我们将实现一个 .NET Core 解决方案中的功能标志（Feature Flag）。
使用功能标志在生产环境中进行测试
在本示范中，我们将创建一个新的 .NET Core 应用程序，在 Visual Studio Code 中进行开发。然后，我们将为此应用程序实现功能标志。
我们将添加一个非常基本的功能标志，将欢迎信息从Welcome更改为Welcome to Learn Azure DevOps。这将仅对一部分用户进行测试。因此，我们需要打开带有.NET Core 的Razor应用程序。我在本地文件系统中创建了一个名为FeatureFlags的新文件夹用于此目的。在 Visual Studio Code 中打开该文件夹。有关详细步骤，请查看下一部分。
创建一个新的.NET Core 应用程序
创建一个新的.NET Core 应用程序，请按照以下步骤操作：
-
在Visual Studio Code打开时，从顶部菜单中点击终端 > 新终端。
-
在终端中，添加以下代码行以创建一个新项目：
dotnet new webapp -o RazorFeatureFlags code -r RazorFeatureFlags -
新创建的项目现在将打开。再次打开终端，并将以下代码行添加到终端中测试项目：
dotnet run运行此代码的输出如下所示：
图 5.23 – 终端中的输出
-
通过点击终端输出中的本地主机 URL 之一，导航到.NET Core 应用程序。您将看到以下内容：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_024.jpg
图 5.24 – 运行新项目
-
下一步是将
Microsoft.FeatureManagementNuGet 包添加到项目中。因此，请将以下代码行添加到终端：dotnet add package Microsoft.FeatureManagement -
安装完该包后，打开
Program.cs类，并添加以下using语句：using Microsoft.FeatureManagement; -
现在，打开
appsettings.json文件。我们将在此文件中创建一个FeatureManagement部分。将文件中的代码替换为以下内容：{ 'Logging': { 'LogLevel': { 'Default': 'Information', 'Microsoft': 'Warning', 'Microsoft.Hosting.Lifetime': 'Information' } }, 'FeatureManagement': { 'ChangeBanner': false }, 'AllowedHosts': '*' } -
然后，打开
Startup.cs类。在这里，再次添加using语句，并将以下内容添加到ConfigureServices方法中：public void ConfigureServices(IServiceCollection services) { //... services.AddFeatureManagement(); } -
现在，我们可以将其注入到一个控制器中。例如，打开应用程序首页背后的代码，代码可以在
Index.cshtml.cs文件中找到，并再次添加using语句。然后，将IndexModel类替换为以下代码：public class IndexModel : PageModel { private readonly IFeatureManager _featureManager; public IndexModel(IFeatureManager featureManager) { _featureManager = featureManager; } public static string WelcomeMessage { get; set; } public async Task OnGetAsync() { WelcomeMessage = await _featureManager.IsEnabledAsync('ChangeBanner') ? 'Welcome to Learn Azure DevOps' : 'Welcome'; } } } -
Index.cshtml.cs类将如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/B16392_05_025.jpg图 5.25 –
Index.cshtml.cs文件概览 -
最后，打开
Index.cshtml文件，并用以下内容替换其中的代码：<div class='text-center'> <h1 class='display-4'>@IndexModel.WelcomeMessage</h1> <p>Learn about <a href='https://docs.microsoft.com/aspnet/core'>building Web apps with ASP.NET Core</a>.</p> </div -
这将把欢迎信息注入到网页中。
-
通过打开一个新的终端窗口并将以下代码行添加到终端来构建并运行代码：
dotnet run -
让应用程序在浏览器中打开，然后再次在 Visual Studio Code 中打开
appsettings.json文件。将ChangeBanner功能标志更改为true，然后通过按F5重新加载浏览器中的网站。这样将会得到以下输出：
图 5.26 – 基于提供的功能标志更改的欢迎信息
在这个演示中，我们使用 Microsoft 的 Featuremanagement NuGet 包向我们的应用程序添加了一些功能标志（Feature Flags）。通过这些功能标志，我们更改了应用程序首页的欢迎信息。本章到此结束。
总结
在本章中，我们更深入地讨论了如何在构建管道中运行质量测试。通过这些，你现在可以从构建管道中运行单元测试，并从 Azure DevOps 执行覆盖率测试。最后，我们讲解了如何在应用程序中创建未来标志（Future Flags），这些标志可以在你的未来项目中使用。
在下一章中，我们将专注于如何在 Azure Pipelines 中托管构建代理。
进一步阅读
查看以下链接以获取更多关于本章所涵盖主题的信息：
-
单元测试基础：
docs.microsoft.com/en-us/visualstudio/test/unit-test-basics?view=vs-2019 -
通过使用 Azure Pipelines 在你的构建管道中运行质量测试：
docs.microsoft.com/en-us/learn/modules/run-quality-tests-build-pipeline/ -
探索如何为部分或所有用户逐步在生产环境中暴露你的功能：
docs.microsoft.com/en-us/azure/devops/migrate/phase-features-with-feature-flags?view=azure-devops
第六章：
第七章：托管你自己的 Azure 管道代理
在前两章中，我们看到了如何通过 Azure Pipelines 设置持续集成，并使用 Microsoft 托管的代理。在本章中，我们将建立一个自托管代理，并更新管道以使用我们自己的代理，而不是使用 Microsoft 托管的代理。
我们将首先查看可用的管道代理类型，然后深入探讨设置代理池的技术规格。我们还将了解如何使用 VM 扩展集来支持大规模的 Azure DevOps 项目。
我们将涵盖以下主题：
-
Azure 管道代理概述
-
了解 Azure Pipelines 中代理的类型
-
规划并设置你自己的 Azure 管道代理
-
更新你的 Azure 管道以使用自托管代理
-
使用容器作为自托管代理
-
扩展规划 – 使用 Azure VM 扩展集作为自托管代理
技术要求
要跟随本章，你需要有一个有效的 Azure DevOps 组织和一个 Azure 订阅来创建虚拟机。
准备项目前提条件：本节要求你在自己的 DevOps 组织中准备好PartsUnlimited项目。如果你正在继续上一章内容，第五章，在构建管道中运行质量测试，你应该已经有该项目了。
如果你在 DevOps 组织中没有准备好项目，可以使用 Azure DevOps Demo Generator 导入它 – azuredevopsdemogenerator.azurewebsites.net/：
-
登录到Azure DevOps Demo Generator网站。
-
输入项目名称并选择你的DevOps 组织。
-
点击选择模板并找到PartsUnlimited。
-
一旦准备好，点击创建项目：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.01_B16392.jpg
图 6.1 – 创建示例 DevOps 项目
项目导入需要几分钟时间，你可以使用显示的进度条来监控进度。
-
完成后，点击导航到项目：
图 6.2 – 项目成功创建
我们将在本章中贯穿使用这个项目。
Azure 管道代理概述
Azure 管道代理是负责执行管道定义中任务的组件。这个代理通常运行在虚拟机或容器中，并包含成功运行管道所需的前提条件。
在大多数情况下，你需要一个代理来运行管道。随着项目规模和开发人员数量的增加，你将需要更多的代理来支持扩展。
每次执行管道时，都会在一个代理上启动一个作业，并且每个代理一次只能运行一个作业。Azure 管道代理可以托管在云端或本地的以下计算基础设施中：
-
服务器或客户端主机（物理或虚拟）
-
容器
-
Azure VM 扩展集（预览版）
Azure 管道代理被分组为 代理池。你可以根据需要创建任意数量的代理池。
重要提示
Azure Pipelines 支持运行基本任务，例如调用 REST API 或 Azure Function，而无需任何代理。有关无代理执行 Azure Pipelines 的更多详情，请参考 docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#server-jobs。
了解 Azure Pipelines 中代理的类型
Azure Pipelines 提供两种类型的代理：
-
Microsoft 托管代理
-
自托管代理
让我们详细看一下它们。
Microsoft 托管代理
Microsoft 托管代理是完全托管的虚拟机，由 Microsoft 部署和管理。你可以选择使用 Microsoft 托管代理，无需任何额外的前置要求或配置。Microsoft 托管代理是最简单的，且无需额外费用。
每次执行管道时，你都会获得一个新的虚拟机来运行任务，且使用一次后就会被丢弃。
自托管代理
自托管代理是你拥有的服务器，运行在你拥有的任何云平台或数据中心中。由于安全性、可扩展性和性能等多种原因，自托管代理更受欢迎。
你可以配置自托管代理以预先安装所需的依赖项，这将帮助你减少管道执行的时间。
选择 Microsoft 托管代理和自托管代理取决于多种因素，以下是一些考虑因素：
-
代码库的大小
-
开发人员数量
-
构建和发布的频率
-
构建过程中所需的依赖项和包
-
安全性和合规性要求
-
性能
如果你的代码库较小且构建管道经过优化，最好使用 Microsoft 托管代理，因为下载所有依赖项所需的时间不多。然而，如果你有一个庞大的代码库和大量的依赖项，使用自托管代理会是一个更好的选择，因为你可以通过提前在自托管环境中配置它们，从而消除管道中的各种构建前期任务。如果你需要比 Microsoft 托管代理提供的更多 CPU 和内存，可以使用自托管代理并自定义大小。
推荐从 Microsoft 托管代理开始，等到 Microsoft 托管代理在你的构建和发布过程中成为瓶颈时，再转向自托管代理。
规划和设置你的自托管 Azure 管道代理
为了在 Azure Pipelines 中使用自托管代理，您需要设置一台机器并根据管道需求进行配置。通常，您会根据项目的框架、库和构建工具兼容性选择最适合的操作系统版本。
为了演示，我们将在 Azure 中设置一台虚拟机，并将其配置为使用自托管代理。您可以选择将代理服务器托管在任何云环境或本地环境中。
为代理虚拟机选择正确的操作系统/镜像
设置虚拟机时的第一个决定是选择操作系统/镜像，这取决于您的目标部署。如果您在本地环境中部署，您可以选择一个支持的操作系统版本（例如 Windows Server 2016）并安装必要的软件。对于云部署，您可以选择多种操作系统版本和预安装工具的组合镜像。
建议与开发人员共同规划代理虚拟机的规格，以确保其最适合您的项目需求。以下是一种推荐的做法：
-
确定您的应用程序是构建为运行在 Windows、Linux 还是 macOS 上。如果是跨平台的，请选择运行效果最佳且支持您正在使用的构建工具的操作系统。
-
列出所使用的底层框架和外部库/组件及其版本。
-
从步骤 1中选择的顶层操作系统中选择最新版本的操作系统。
-
确定它是否与原始设备制造商（OEM）支持的所有依赖项兼容，依赖项详见步骤 2。
-
依次选择每个版本，直到选定一个与项目所需所有依赖项兼容的版本。
根据此过程确定的规格，您可以选择从原生操作系统开始，安装所需的框架和构建工具，或者在云中选择一个预创建的镜像。
安装 Azure Pipelines 代理的操作系统支持及前提条件
Azure 支持多种操作系统版本作为自托管代理使用；根据您选择的操作系统，您需要完成一组前提条件，才能在主机上安装 Azure Pipelines 代理。
支持的操作系统
以下是支持的操作系统列表：
-
基于 Windows：
a) Windows 7，8.1 或 10（如果您使用的是客户端操作系统）
b) Windows Server 2008 R2 SP1 或更高版本（Windows Server 操作系统）
-
基于 Linux：
a) CentOS 7，6
b) Debian 9
c) Fedora 30，29
d) Linux Mint 18，17
e) openSUSE 42.3 或更高版本
f) Oracle Linux 7
g) Red Hat Enterprise Linux 8，7，6
h) SUSE Enterprise Linux 12 SP2 或更高版本
i) Ubuntu 18.04，16.04
-
ARM32：
a) Debian 9
b) Ubuntu 18.04
-
基于 macOS：
a) macOS Sierra（10.12）或更高版本
前提软件
根据您选择的操作系统，您必须在将主机设置为 Azure Pipeline 代理之前，先安装以下前提条件：
-
基于 Windows：
a) PowerShell 3.0 或更高版本
b) .NET Framework 4.6.2 或更高版本
-
基于 Linux/ARM/macOS：
a) Git 2.9.0 或更高版本。
b) RHEL 6 和 CentOS 6 需要安装专门的 RHEL.6-x64 版本的代理。
Linux 的代理安装程序包括一个脚本，用于自动安装所需的先决条件。您可以通过运行./bin/installdependencies.sh来完成先决条件安装，该脚本位于下载的代理目录中。下载代理的过程将在本章的后续部分中介绍。
重要提示
请注意，上述先决条件仅用于在主机上安装 Azure Pipelines 代理；根据您的应用程序开发需求，您可能需要安装其他工具，例如 Visual Studio 构建工具、Subversion 客户端以及您的应用程序可能需要的任何其他框架。
现在我们已经了解了先决条件，我们将为我们的示例项目PartsUnlimited创建一个代理虚拟机。
为您的项目在 Azure 中创建虚拟机
PartsUnlimited 项目使用 .NET Framework 4.5 和 Visual Studio 作为主要的 IDE 工具进行构建。您可以通过浏览 PartsUnlimited 项目的 Azure DevOps 仓库来查看该信息。
看来看去，我们最好的选择是使用基于 Visual Studio 的服务器操作系统。让我们在 Azure 中查看并探索我们在这方面的选择：
-
登录到 Azure 门户并点击**+ 创建资源**。
-
搜索Visual Studio并选择Azure 的 Visual Studio 镜像选项:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.03_B16392.jpg
图 6.3 – Azure 门户中的 Visual Studio
-
现在，您将能够从各种可用组合中进行选择。我们将选择Visual Studio Community 2017 on Windows Server 2016(x64):https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.04_B16392.jpg
图 6.4 – Azure 中可用的 Visual Studio 镜像
重要提示
基于 Visual Studio 2019 的镜像可以直接在 Azure 门户的搜索结果中找到。
-
点击创建开始创建虚拟机。根据您的偏好选择所需的订阅、资源组和其他设置。
-
在后续页面中，您可以修改设置以使用预先创建的虚拟网络，并自定义存储设置及其他管理方面的内容。请查看文档，了解更多关于在 Azure 中创建虚拟机的信息。
重要提示
请参考 Microsoft 文档，了解如何在 Azure 中创建虚拟机：
docs.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-portal。 -
创建虚拟机后，登录并安装所需的先决条件。
现在我们已经准备好虚拟机，我们将其设置为我们项目的 Azure Pipelines 代理。
设置构建代理
在本节中，我们将配置新创建的虚拟机，以将其用作自托管的管道代理。
在 Azure DevOps 中设置代理池
您可以在 Azure DevOps 中将您的代理组织为 代理池。代理池是您自托管代理的集合，它们帮助您在池级别组织和管理代理，而不是单独管理每个代理。
代理池 在组织级别进行管理，并可以同时供多个项目使用。让我们创建一个 代理池 来开始：
-
登录到 Azure DevOps 并点击 组织设置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.05_B16392.jpg
图 6.5 – Azure DevOps 组织设置
-
在 管道 下点击 代理池：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.06_B16392.jpg
图 6.6 – Azure DevOps 代理池
-
您会看到已创建了两个默认的代理池。点击 添加池 创建一个新池：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.07_B16392.jpg
图 6.7 – Azure DevOps – 添加代理池
-
提供池类型、名称、描述和管道权限。在权限选项下，您可以选择让此池同时适用于所有管道和项目。准备好后点击 创建：
a) –池类型：自托管
b) –名称 和 描述：为其起个有意义的名称，以便以后可以引用：
图 6.8 – Azure DevOps – 添加代理池配置
-
现在您的代理池应该已列在 代理池 下。
现在我们将为代理虚拟机设置访问令牌，以便其能够与 Azure DevOps 进行身份验证。
设置代理通信的访问令牌
在此任务中，您将创建一个个人访问令牌，Azure Pipelines 代理将使用它与您的 Azure DevOps 组织进行通信：
-
使用管理员用户帐户登录您的 Azure DevOps 组织。
-
转到您的用户个人资料并点击 个人访问令牌：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.09_B16392.jpg
图 6.9 – 个人访问令牌
-
点击 新建令牌。
-
按照此处提供的令牌规格进行设置：
–名称：自托管代理令牌。
–组织：您的 Azure DevOps 组织。
–到期时间：您可以根据需要选择一个日期。这只是一次性设置；一旦此令牌过期，您不需要重新配置代理。
–范围：自定义定义。
-
在 范围 中，建议仅授予管理代理所需的权限。点击 显示所有范围 并选择 读取 和 读取与管理 权限：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.10_B16392.jpg
图 6.10 – 代理池访问
-
查看所有设置并点击 创建：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.11_B16392.jpg
图 6.11 – 为代理池创建个人访问令牌
-
一旦您点击创建，Azure DevOps 会显示个人访问令牌。请复制该令牌并将其保存在安全位置。如果您丢失了该令牌，必须为新代理的设置创建一个新的令牌。
我们将在设置 Azure Pipelines 代理时使用此令牌。
重要提示
如果您计划使用部署组，创建令牌时需要赋予额外的权限（更多信息请参考：
docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups/?view=azure-devops）。
现在我们已经在 Azure DevOps 中完成了代理池的设置，我们可以开始在之前创建的虚拟机上安装代理。
安装 Azure Pipelines 代理
现在，您可以在之前创建的虚拟机上安装 Azure Pipelines 代理。让我们下载 Azure Pipelines 代理。在开始之前，请使用远程桌面登录到之前创建的虚拟机：
-
在您的 Azure DevOps 账户中，浏览到 组织设置 > 代理池。
-
选择您新创建的代理池并点击新建代理：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.12_B16392.jpg
图 6.12 – 添加代理
-
在下一页，您可以根据操作系统和架构（x64/x32）下载代理安装程序。在我们的示例中，我们使用的是基于 Windows Server 2016 的虚拟机。我们将选择 Windows 和 x64 架构。您还可以复制下载 URL，并在您的自托管代理机器上直接下载代理。您也可以选择根据操作系统在 Azure DevOps 门户中提供的安装步骤来安装代理：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.13_B16392.jpg
图 6.13 – 代理命令
提示
如果您无法在 Visual Studio 机器上下载代理文件，您可以使用不同的浏览器（如非 Internet Explorer）或在服务器管理器中禁用增强的 IE 安全性配置。您可以参考
www.wintips.org/how-to-disable-internet-explorer-enhanced-security-configuration-in-server-2016/了解如何禁用 Internet Explorer 增强的安全性配置。 -
启动一个提升权限的 PowerShell 窗口，并通过运行
cd C:\命令更改到C:目录根目录：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.14_B16392.jpg图 6.14 – 更改目录
-
运行以下 PowerShell 命令在
C盘创建一个代理目录，并将代理文件提取到新目录中。请注意，您可能需要根据您下载的代理版本和保存下载文件的目录更改文件名/路径：mkdir agent ; cd agent Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory("$HOME\Downloads\vsts-agent-win-x64-2.171.1.zip", "$PWD") -
提取文件将需要一分钟左右的时间。完成后，请浏览到新的目录。您应该会看到如下截图中的文件：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.15_B16392.jpg
图 6.15 – 代理文件
-
您可以以两种模式运行 Azure 管道代理：
–
run批处理文件存储在代理目录中。如果您停止交互式认证，您的代理将停止响应管道。–作为服务运行：在这个版本中，您将配置代理作为 Windows 服务运行，该服务将始终保持在线，并在重启时自动启动。这是生产环境推荐的设置。
-
让我们配置代理为服务运行。在您的 PowerShell 窗口中，运行
.\config.cmd。这将询问有关您 Azure DevOps 组织的一系列问题。
-
输入您的 Azure DevOps 组织作为服务器 URL。通常，这将是
dev.azure.com/YourOrganizationName。 -
按 Enter 键选择 PAT（个人访问令牌）作为 Azure DevOps 的认证机制。
-
提供您之前生成的个人访问令牌。
-
提供您之前创建的代理池名称。
-
为此代理提供一个名称。
-
为代理提供一个工作目录，作为默认目录。
-
最后，按 Y 并按 Enter 键，将代理配置为作为 Windows 服务运行。
-
您可以接受默认帐户来运行此服务。
-
这将完成代理设置；最后，您应该看到一条消息，表示服务已成功启动：
图 6.16 – 安装代理
现在，如果您在 Azure DevOps 门户中的代理池下查看，应该会看到这个代理列出：
图 6.17 – Azure Pipelines 代理列出
现在，您已经拥有一个可用的自托管代理来运行您的 Azure 管道！此自托管代理可用于运行您的 Azure 管道作业，并且您可以以类似的方式添加任意数量的代理。您可以在同一个池中拥有多种类型的托管代理；根据管道要求，系统会自动选择合适的代理，或者您也可以在执行时专门选择一个代理。通常，在大型环境中，您会预先创建一个代理服务器的镜像，以便在需要时能够更快地配置额外的代理。在接下来的章节中，我们将更新我们的管道，以利用新设置的自托管代理。如果您希望使用基于 Linux 的托管代理，请参考以下文档：docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops。
请参考以下链接，了解基于 macOS 的代理：docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-osx?view=azure-devops。
重要提示
如果你的自托管代理机器位于网络防火墙或代理后面，在安装 Azure 管道代理时，必须定义代理地址。你可以通过在配置命令中指定代理 URL、用户名和密码来完成此操作：
./config.cmd --proxyurl http://127.0.0.1:8888 --proxyusername "myuser" --proxypassword "mypass"
更新你的 Azure 管道以使用自托管代理
在本节中，我们将修改上几章中涵盖的 Azure 管道场景（PartsUnlimited），以使用我们新创建的自托管代理。这将使我们能够使用自托管代理来运行管道，而不是使用 Microsoft 提供的代理。
准备你的自托管代理来构建PartsUnlimited项目
在我们开始使用自托管代理之前，我们必须准备它以支持构建我们的示例项目PartsUnlimited。PartsUnlimited项目是使用 Visual Studio 构建的，依赖于 .NET Framework、Azure 开发工具和 .NET Core、Node.js 等技术。为了使用我们的自托管代理构建解决方案，我们必须在运行管道作业之前安装所需的依赖项：
-
登录到你的自托管代理虚拟机。
-
通过以下链接下载 Visual Studio 构建工具：
visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=16。这将启动 Visual Studio 安装程序。
-
选择ASP.Net 和 Web 开发以及Azure 开发。
-
点击修改。这将开始安装所需的框架和工具。
-
完成后，请下载并安装 .NET Core 2.2。你可以从这个链接下载：
dotnet.microsoft.com/download/dotnet-core/thank-you/sdk-2.2.110-windows-x64-installer。你可以在这里找到所有的 .NET 下载：
dotnet.microsoft.com/download。 -
通过在提升权限的 PowerShell 窗口中运行以下命令来安装 Azure PowerShell：
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Install-Module AzureRM -AllowClobber -
从
nodejs.org/download/release/v6.12.3下载 Node.js 版本 6.x。你可以下载名为node-v6.12.3-x64.msi的文件，并使用交互式安装程序进行安装。
你的主机现在已准备好构建PartsUnlimited解决方案。
运行 Azure 管道
在这个任务中，我们将运行管道作业，使用我们自己的自托管代理构建PartsUnlimited解决方案：
-
登录到Azure DevOps门户并浏览到PartsUnlimited项目。
-
浏览到Pipelines：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.18_B16392.jpg
图 6.18 – Azure Pipelines
-
打开名为
PartsUnlimitedE2E的预创建管道。 -
点击编辑管道。
-
在管道中，将代理池更改为您新创建的代理池：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.19_B16392.jpg
图 6.19 – 为管道选择代理池
-
保存管道。您还可以选择在保存后运行它，方法是选择保存并排队：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.20_B16392.jpg
图 6.20 – 保存管道
-
现在，我们准备好执行管道。点击运行管道：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.21_B16392.jpg
图 6.21 – 运行管道
-
在代理池下，将池名称更改为您在前一部分配置的代理池名称，然后点击运行：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.22_B16392.jpg
图 6.22 – 运行管道向导
-
这将开始在您的自托管代理上执行管道作业。完成此操作可能需要几分钟：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.23_B16392.jpg
图 6.23 – Azure 管道作业日志
-
您可以点击作业名称以实时查看日志。
您现在已经完成了 Azure 管道的设置，该管道使用基于 VM 的自托管管道代理来运行作业。
使用容器作为自托管代理
Azure Pipelines 支持使用 Docker 容器作为运行管道作业的计算目标。您可以使用 Windows 容器（Windows Server Core/Nano Server）和 Linux 容器（Ubuntu）来托管您的代理。
为了将容器连接到您的 Azure DevOps 组织，您需要传递一些环境变量，例如代理池名称、个人访问令牌等。
设置 Windows 容器作为 Azure 管道代理
为了将 Windows 容器作为 Azure 管道代理使用，您需要先构建容器镜像，然后用 Azure DevOps 组织的环境变量运行它。让我们看看这个过程。
构建容器镜像
按照以下步骤构建容器镜像：
-
启动命令提示符并运行以下命令：
mkdir C:\dockeragent cd C:\dockeragent -
创建一个名为
Dockerfile（无扩展名）的新文件，并用以下内容更新它。您可以使用记事本打开该文件：FROM mcr.microsoft.com/windows/servercore:ltsc2019 WORKDIR /azp COPY start.ps1 . CMD powershell .\start.ps1 -
创建一个新的 PowerShell 文件，命名为
start.ps1，并从此处复制内容：github.com/PacktPublishing/Learning-Azure-DevOps---B16392/blob/master/Chapter-6/start.ps1。 -
运行以下命令以构建容器镜像：
docker build -t dockeragent:latest.
您的容器镜像现在已准备好使用。您可以使用dockeragent作为镜像名称来引用此镜像。可选地，您也可以将此镜像保存在您的容器仓库中。
运行 Azure Pipelines 代理容器
现在，您已经准备好容器镜像，您可以通过运行该容器将其用作管道代理。
启动命令提示符窗口并运行以下命令。请确保更新 Azure DevOps 组织 URL、令牌和代理名称：
docker run -e AZP_URL=<Azure DevOps instance> -e AZP_TOKEN=<PAT token> -e AZP_AGENT_NAME=mydockeragent dockeragent:latest
现在，你的基于容器的 Azure 管道代理已经准备好使用。如果你希望每次只为一个作业使用容器并在作业执行完毕后重新创建容器，你可以使用 –-once 标志，仅使用一个容器运行一个作业，并使用容器编排工具（如 Kubernetes）在当前作业执行完毕后重新创建容器。
重要提示
请参考 Microsoft 文档 – docs.microsoft.com/en-us/virtualization/windowscontainers/about/ – 了解有关 Windows 容器的更多细节。
在接下来的部分中，我们将介绍如何将基于 Linux 的容器设置为 Azure Pipelines 代理。
设置 Linux 容器作为 Azure Pipelines 代理
为了将 Linux 容器用作 Azure 管道代理，你可以选择使用 Microsoft 在 Docker Hub 上发布的 Docker 镜像，或者自行构建 Docker 镜像。
Microsoft 的 Azure 管道代理镜像可以在此找到： hub.docker.com/_/microsoft-azure-pipelines-vsts-agent。你可以直接运行此镜像，并通过环境变量传入 Azure DevOps 组织的相关信息：
docker run \
-e VSTS_ACCOUNT=<name> \
-e VSTS_TOKEN=<pat> \
-it mcr.microsoft.com/azure-pipelines/vsts-agent
或者，你也可以选择构建自己的 Docker 镜像来作为你的管道代理使用。该过程类似于为 Windows 容器构建镜像。请参考 Microsoft 文档：docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops – 获取有关入口点脚本的参考。
使用 Azure 容器实例作为代理
Azure 容器实例 (ACI) 是一种托管服务，可以在 Azure 云中运行 Windows 和 Linux 容器。如果标准的 Microsoft 托管代理不符合你的需求（如要求、性能等），而且你没有足够的基础设施来在本地托管容器，你可以使用 ACI 来为 Azure DevOps 创建自托管代理。
你可以通过使用自定义镜像或重用 Microsoft 提供的镜像之一，在 ACI 上创建构建代理。
要在 ACI 上运行 Azure 管道代理，你需要 Azure DevOps 账户名、个人访问令牌和代理名称。获取所需的详细信息后，你可以通过在 Azure CLI 中执行以下命令来创建 ACI 上的代理（在连接到你的 Azure 订阅后）：
az container create -g RESOURCE_GROUP_NAME -n CONTAINER_NAME --image mcr.microsoft.com/azure-pipelines/vsts-agent --cpu 1 --memory 7 --environment-variables VSTS_ACCOUNT=AZURE_DEVOPS_ACCOUNT_NAME VSTS_TOKEN=PERSONAL_ACCESS_TOKEN VSTS_AGENT=AGENT_NAME VSTS_POOL=Default
在这里，我们有以下内容：
-
RESOURCE_GROUP_NAME是你希望在 Azure 中创建该资源的资源组名称。 -
CONTAINER_NAME是 ACI 容器的名称。 -
AZURE_DEVOPS_ACCOUNT_NAME是你的 Azure DevOps 账户名。 -
PERSONAL_ACCESS_TOKEN是之前创建的个人访问令牌。 -
AGENT_NAME是你希望创建的构建代理名称，并将在 Azure DevOps 中显示。
在此命令中，还有其他两个重要参数：
-
--image参数用于选择用于创建代理的 Azure Pipelines 镜像名称，如下所述：hub.docker.com/_/microsoft-azure-pipelines-vsts-agent。 -
VSTS_POOL 参数用于选择你的构建代理池。
请记住，你可以使用 az container stop 和 az container start 命令来启动和停止 ACI 实例，这可以帮助你节省成本。
让我们来看看你可以与 Azure 管道代理容器一起使用的一些额外环境变量。
环境变量
运行在容器上的 Azure DevOps 管道代理可以通过使用额外的环境变量进一步自定义。环境变量及其目的如下所述：
-
AZP_URL：Azure DevOps 组织的 URL -
AZP_TOKEN：个人访问令牌 -
AZP_AGENT_NAME：你的 Azure 管道代理名称 -
AZP_POOL：代理池名称（默认值为Default） -
AZP_WORK：工作目录（默认值为_work）
在这一部分，我们了解了如何使用容器作为 Azure 管道代理来执行管道作业。
规划扩展 – Azure 虚拟机规模集作为 Azure 管道代理
Azure 虚拟机规模集是 Azure 服务，允许你创建和管理数百个相同的虚拟机，具备自动或手动扩展虚拟机数量的能力。Azure 虚拟机规模集可以作为 Azure 管道代理，适用于大规模项目，在这些项目中，你需要根据 Azure 管道作业执行负载的需求来动态扩展容量。
Azure 虚拟机规模集最多支持 1,000 个虚拟机。
规划扩展
基于 Azure 虚拟机规模集的代理可以根据 Azure Pipelines 作业需求自动扩展。规模集代理相比专用代理有几个优势：
-
你在某个时刻需要更多的计算能力（CPU 和内存），而且这一需求会根据工作负载波动。
-
Microsoft 托管的代理无法满足你的管道需求。
-
你的作业运行时间较长或需要较长时间才能完成。
-
你希望连续使用相同的代理来执行多个作业，以便利用缓存等功能。
-
你不想一直运行专用代理，因为这样会产生成本。
-
你希望定期更新运行作业的虚拟机镜像。
Azure 虚拟机规模集可以根据 Azure Pipelines 当前的需求自动增加/减少可用的管道代理数量。这有助于节省成本，并支持你的扩展需求。
创建 Azure 虚拟机规模集
在本节中，我们将创建一个 Azure VM 扩展集，用作 Azure Pipeline 代理。请注意，Azure Pipelines 要求以特定配置创建扩展集，因此您可能无法使用现有的扩展集：
-
登录 Azure 门户并点击**+ 创建资源**。
-
图 6.24 – Azure 门户中的 VM 扩展集
-
点击创建。
-
按照此处描述的方式填写值：
–订阅：选择您希望部署此扩展集的订阅。
–资源组：选择现有的资源组或创建一个新组。
–虚拟机扩展集名称：您选择的标识符。
–区域：选择您选择的 Azure 区域；建议选择离您最近的区域。
–可用性区域：建议选择所有三个区域以实现高可用性。
–镜像：为 Azure Pipelines 代理选择一个支持的 Windows 或 Linux 镜像。
–Azure Spot 实例：可以帮助降低成本。详情请参阅
azure.microsoft.com/en-us/pricing/spot/。–大小：为您的代理选择虚拟机大小。
–身份验证：用户名/密码或 SSH 密钥：
图 6.25 – 创建 VM 扩展集
-
点击下一步：磁盘 >。
-
您可以自定义磁盘性能层和加密设置，并在需要时添加额外的磁盘。如果不确定，接受默认设置并点击下一步。
-
在网络页面上，如果您的扩展集需要访问任何网络资源并确保安全连接，您可以选择将扩展集连接到现有的虚拟网络。请确保使用负载均衡器设置为否，以用于 Azure Pipelines 扩展集。配置完成后，点击下一步：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.26_B16392.jpg
图 6.26 – Azure VM 扩展集负载均衡设置
-
在扩展部分，提供初始实例数量，并将扩展策略设置为手动。将其他设置保持为默认，点击下一步：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.27_B16392.jpg
图 6.27 – 扩展集设置
-
在管理部分，确保升级模式设置为手动。将其他设置保持为默认，点击下一步：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.28_B16392.jpg
图 6.28 – 扩展集升级策略
-
在健康和高级设置页面上，您可以选择更改任何希望自定义的环境设置。准备好创建扩展集时，点击审核并创建。
-
验证成功后，点击创建以开始部署。
部署完成可能需要几分钟的时间。请耐心等待部署完成。虚拟机扩展集准备好后，我们将设置它作为 Azure Pipelines 代理使用。
使用虚拟机规模集设置 Azure 管道代理
在上一节中，我们创建了一个虚拟机规模集。现在，我们将其设置为 Azure 管道代理：
-
登录到你的 Azure DevOps 组织，进入 项目设置 > 代理池。
-
点击 添加池。
-
按照这里定义的值填写：
–池类型：虚拟机规模集
–服务连接的项目：选择你的 Azure DevOps 项目
–Azure 订阅：选择你创建虚拟机规模集的 Azure 订阅：
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.29_B16392.jpg)
图 6.29 – 为规模集添加代理池
-
点击 授权，以启用对你 Azure 订阅的访问权限。你可能会被要求在此过程中登录到 Azure 帐户。
-
验证身份后，选择一个现有的虚拟机规模集，并按照这里描述的值填写：
–你选择的代理池的名称和描述。
–可选地，配置规模集在每次执行后删除虚拟机。
–虚拟机的最大数量。
–保留备用的代理数量。虽然这有助于更快地完成任务，但可能会增加你的 Azure 成本。
-
填写完所有值后，点击 创建：![图 6.30 – 创建基于规模集的代理池]
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.29_B16392.jpg)
图 6.30 – 创建基于规模集的代理池
-
现在，代理池的创建将开始。请注意，代理池准备好接收任务可能需要大约 15 分钟。在完成时，你应该能看到代理池中的代理处于活动状态：
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_6.31_B16392.jpg)
图 6.31 – 代理
一旦代理池准备就绪，你可以更新你的 Azure 管道，开始使用这个池来执行任务。
总结
在本章中，我们讨论了如何使用微软托管的代理和自托管代理来运行你的 Azure 管道任务。我们深入了解了设置自托管代理的过程，并更新了管道以使用自托管代理。
我们还讨论了如何使用 Docker 容器、Azure 容器实例和 Azure 虚拟机规模集作为你的 Azure 管道代理。通过本章内容，你应该能够为你的项目规划并实现适当的管道代理解决方案。
在下一章中，我们将学习 Azure DevOps 中的工件（Artifacts）。
扫一扫
88
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
