Azure-流水线实用指南-二-

Azure 流水线实用指南（二）

原文：Hands-on Azure Pipelines

协议：CC BY-NC-SA 4.0

九、Azure 发布管道——服务连接、模板、工件、阶段和环境

在前几章中，我们讨论了设置构建管道的特性和选项。构建管道允许您构建源代码并使用构建的二进制文件创建可部署的包，使用代码分析工具检查源代码中的漏洞，以及运行单元测试。此外，您可以在构建管道中运行部署操作，尤其是在涉及 YAML 管道时，部署的实现也是通过 YAML 构建管道设置的。

Azure DevOps 中的发布管道具有各种功能，使您能够部署到几乎所有可用的目标和平台。在本章中，我们将探索 Azure DevOps 中与部署管道相关的一些可用功能，以便您能够理解这些功能的使用，从而实现自动化软件交付，甚至是生产目标。

第 9.01 课:服务连接

通常，在给定的软件中，不同的平台上可能有不同的部署目标。既可以有云目标，也可以有本地目标。此外，目标可以是云平台资源或云上的基础设施。为了支持部署到如此多样的平台，需要连接到这样的资源。换句话说，应该对给定资源中的端点进行身份验证，并且应该从 Azure DevOps 以服务连接的形式连接到端点，以便允许管道与资源进行交互。

例如，我们可以考虑 Azure 订阅或资源组。Azure 中的服务原则允许访问 Azure 资源。使用服务原则，您可以在 Azure DevOps 中建立 Azure 服务连接。见图 9-1 。

图 9-1

Azure 服务连接

您可以从 Azure DevOps 建立各种各样的服务连接。它们涉及诸如 Azure、AWS 之类的云服务目标，诸如 Bitbucket 和 GitHub 之类的代码回购，不同类型的部署工具 chefs、Octopus 以及许多其他连接代码质量工具的目标。

到 GitHub 和 Bitbucket 等源代码控制仓库的服务连接允许您将不同的源代码控制仓库连接到 Azure 管道。您可以通过将它们与服务连接联系起来，在这样的 repos 中构建可用的代码。

Azure DevOps 的 marketplace 扩展安装了一些服务连接类型。例如，要链接 sonar cube 服务器，您需要安装 sonar cube 扩展。一旦添加了扩展，就可以设置管道来触发源代码控制库中源代码的代码分析。另一个例子是面向 Amazon Web Services (AWS)的服务连接，允许部署到 AWS。参见图 9-2 。

图 9-2

不同类型的服务连接

在本课中，我们探讨了服务连接及其使用，以促进与 Azure DevOps 的外部资源连接。

第 9.02 课:使用模板

模板被预先创建为一组组合在一起的管道任务，用于给定的目的。这些模板还设置了常用的变量，以便快速部署到所需的目标。见图 9-3 。

图 9-3

发布模板

例如，如果您应用 Azure 机器学习模型部署模板作为您的管道模板，它将创建部署机器学习模式所需的两个步骤。您可以选择创建为服务连接的 Azure 订阅，并使用此模板快速开始机器学习模型部署。参见图 9-4 。

图 9-4

ML 模型部署模板

模板的主要用途是让您开始使用给定类型的应用，并快速完成目标部署。如果您是设置发布管道的初学者，这些模板将帮助您在更短的时间内熟悉发布管道，最大限度地减少学习工作量。您可以通过从 Visual Studio 市场设置扩展来安装附加模板。

我们在本课中讨论了模板的使用，这将帮助您快速开始使用发布管道。

第 9.03 课:发布的工件

正如我们在本书第七章中讨论的，构建管道应该生成可部署的二进制包，称为工件。这些工件可以在发布管道中使用，将它们的内容下载到目标上，并根据需要进行部署。

Azure 发布管道支持许多工件类型。参见图 9-5 。

图 9-5

工件类型

如果您已经在构建本身中将您的工件发布为发布的放置文件夹，那么您可以将该构建用作您的构建的工件类型。一旦构建完成，如果您想要设置发布的连续触发，那么将构建设置为通过其他方式发布构件的构件类型甚至是有用的，例如发布中的构件提要。

Azure repos 可以用作另一种工件类型。在发布步骤中可以使用代码或其他文件，如 YAML 部署支持文件。有时，甚至机器学习所需的基于 Python 的部署和部署后测试代码文件也可以存储在 Azure repos 中，并在发布管道中使用，以执行部署和测试步骤。通过使用 GitHub 和 Team Foundation 版本控制 repos 作为发布管道中的工件，可以达到类似的目的。

如第七章所解释的，Azure 工件可以用来在工件提要中存储生成的工件，比如 NuGet 包。工件提要可以在发布中使用，包可以下载并在部署代理中使用，以部署到所需的目标。

Azure container repositories 和 docker hub 作为工件，允许您使用它们中可用的 docker 映像，以便在发布管道中使用。此外，Jenkins 管道可以集成为一个工件源，这样您就可以在发布管道中使用 Jenkins 管道的输出。

一旦添加了工件，您就可以基于新工件的可用性为管道设置一个触发器，这允许连续的部署。使用生成时，可以为触发器添加额外的排除或包含分支筛选器。当使用 repo 时，它可以基于 pull 请求设置一个触发器，带有一个目标分支过滤器，您可以使用分支过滤器来触发提交。参见图 9-6 。

图 9-6

回购工件触发器

在本课中，我们讨论了可以在发布管道中使用的不同类型的工件，这使您能够基于新工件的可用性来触发发布管道。

第 9.04 课:发布阶段

发布阶段可用于控制发布管道的流量。您可以将它们视为管道中的部署环境表示。管道中的阶段为您提供了定义您想要的软件交付工作流的灵活性。在这一课中，让我们探索发布阶段的功能和用法，以管理软件项目向期望目标的交付。参见图 9-7 。

图 9-7

释放管道流量

可以用三种类型触发器设置阶段。手动触发要求您在从发布管道创建发布后，通过单击手动部署来手动触发阶段。“后阶段”允许您定义前面的阶段，以便仅当所有前面的阶段完成时才触发当前阶段。一旦为管道创建了发布，发布后将触发一个阶段，通过手动创建或在连接的工件上设置连续部署触发器。参见图 9-8 。此外，您可以为给定的阶段设置预定的发布。工件过滤器允许您过滤分支，排除或包含模式，或者设置其他工件条件。启用拉取请求部署将允许将基于拉取请求的发布部署到给定阶段；但是，建议在生产阶段禁用此功能。

图 9-8

阶段触发器

可以设置一个具有预部署批准的阶段。作为审批者，您可以添加个人或组，并设置审批超时。设置批准将在触发阶段时向批准人发送提醒电子邮件。批准者可以批准或拒绝部署到给定阶段。但是，如果需要，可以安排延迟时间来批准部署。这种预部署批准可以有效地用于保护所需的环境，如生产或演示环境。此外，当应用的一个版本正在被测试时，它可以被用来防止到诸如质量保证阶段的任何部署，以便它防止在质量保证阶段的应用的组件被意外地覆盖，直到 QA 团队决定接受新的版本进行测试。部署前审批设置见图 9-9 。部署后批准也可以像部署前批准一样进行设置，以表明如果某个已部署的应用通过了给定应用的必需的强制工作条件，则该应用将得到验证和考虑。见图 9-9 。

图 9-9

部署前批准

另一个可以应用于 stage 的预部署设置是 Azure pipelines 中的 gates。Gates 允许您调用第三方调用，并在继续某个特定阶段之前等待期望的结果。换句话说，gates 用于在部署给定阶段之前执行看门人的工作。例如，在允许发布部署 QA 阶段之外的任何阶段之前，查询工作项门可以评估是否有任何关键错误处于未解决的状态。参见图 9-10 。

图 9-10

盖茨

某个阶段的部署队列设置允许您定义多个发布在给定阶段排队时的行为。您可以定义在给定的阶段是否允许并行部署，但是这是一个极不可能的场景。当部署排队的多个版本时，可以使用一个序列中的所有版本。或者，您可以将设置为仅部署最新版本，并放弃其他以前的部署请求。参见图 9-11 。

图 9-11

部署队列设置

在部署后阶段，如本课前面所讨论的，可以设置批准以表示应用在该阶段工作正常，在部署到该阶段后，让它触发任何后续阶段。此外，您还可以向部署后阶段添加关卡。此外，您可以选择在部署阶段失败时设置重新部署触发器，以便它将当前阶段以前成功的部署再次部署到该阶段。参见图 9-12 。

图 9-12

重新部署触发器

您可以克隆一个阶段来创建另一个阶段，这使您可以轻松地创建发布工作流。在一个阶段中，您可以添加代理阶段、部署组阶段和无代理阶段，这些将在第十章中详细介绍。与构建管道类似，您可以将任务添加到发布阶段，以定义作为部署和自动化测试操作执行的步骤。见图 9-13 。

图 9-13

阶段

在本课中，我们讨论了前阶段和后阶段中可用于简化发布工作流的几个功能。

第 9.05 课:环境

可以用作部署目标的资源集合可以设置为 Azure DevOps 中的环境。一个环境可能包含一个 Kubernetes 集群、一组虚拟机或资源，例如 Azure web app 或 functions apps。

您可以创建一个有虚拟机、Kubernetes 或没有资源的环境。创建无资源环境时，可以在以后向环境中添加资源。参见图 9-14

图 9-14

环境

对于环境，您可以基于读者、用户和管理员的角色设置权限，其中管理员可以管理环境，用户可以使用管道中的环境，而读者只能查看。

环境可以添加检查，有点类似于 gates。检查甚至还包括工件的批准者评估。参见图 9-15 。

图 9-15

环境检查

YAML 管道可以使用环境作为部署行动的目标。参见图 9-16

图 9-16

YAML 的使用环境

环境促进了 YAML 管道基于批准的工作流实施，类似于传统发布管道中可用的阶段。

在本课中，我们已经确定了在 YAML 管道环境中的用法和可用选项。

摘要

本章给出了发布管道的初步介绍，强调了服务连接的功能和模板的使用，以便轻松地开始使用发布管道。然后我们讨论了工件在发布管道中的使用，以及设置基于工件的触发器来支持连续部署。还详细讨论了实现发布工作流的发布阶段功能，解释了每个可用选项的用法。此外，我们探索了允许为 YAML 管道设置部署目标的环境，类似于经典发布管道中的阶段。

在下一章中，我们将讨论发布管道阶段的可用阶段，以便您获得成功实施发布工作流所需的知识。此外，我们将探索其他选项和特性，例如变量、发布定义历史的使用，以及发布管道的导出和导入选项。

十、Azure 发布管道——作业、部署组、变量和其他选项

在前一章中，我们讨论了一些与发布管道相关的重要特性。描述了允许发布管理的各种部署目标的服务连接。此外，我们探索了可用于发布管道实现的模板的使用，发布管道中实现发布工作流的阶段，以及设置触发器、批准和关口的方法。还讨论了新的功能环境，以了解其用法。

作为上一章的延续，我们将探讨代理作业、部署组作业和无代理作业阶段及其用法。然后，我们简要地讨论变量及其在发布管道中的使用，这或多或少类似于变量在构建管道中的使用。

第 10.01 课:代理作业

代理作业需要安装 Azure DevOps 代理来执行作业。根据我们在本课中讨论的部署目标，代理计算机可以是托管代理计算机或本地计算机。

根据执行情况，代理的步骤技术要求会有所延迟。代理的需求可以作为代理阶段的需求。例如，如果您的部署步骤涉及 Azure CLI，要部署到 Azure 目标，您的代理计算机需要有可用的 Azure CLI。代理阶段的需求用于这些类型的技术需求。见图 10-1 。

图 10-1

代理需求

如果您正在部署到云目标，如 Azure 或 AWS，您可以使用 Microsoft 托管代理来执行部署操作。但是，如果您要部署到内部部署目标或更安全的 Azure 目标(如 Azure App Service Environment ),您可能需要设置自己的部署代理机器。大多数情况下，内部部署环境位于企业防火墙之后，托管代理无法看到针对此类目标执行的部署。与此类似，在 Azure App Service Environment (ASE)中，对平台服务的访问只能在 Azure ASE 中定义的虚拟网络中进行。因此，您需要在 Azure ASE 虚拟网络中设置一个配置为 Azure DevOps 代理的虚拟机，它可以访问 Azure ASE 中的平台服务。

有类似于构建管道的并行选项，允许您在单个代理或 multipliers 中指定的多个配置中运行作业步骤。当在多个配置上运行时，您可以指定代理数量限制。您可以在多个代理中运行同一组任务，也可以使用多代理选项。见图 10-2 。如果您希望部署到不同的目标，这些选项会很有用，因为指定的配置可能会启用调试配置上的部署，以诊断一些问题，同时还有一个发布配置目标。

图 10-2

平行

您可以在代理步骤中有选择地设置下载或跳过下载工件。见图 10-3 。例如，如果您有一个单独的代理作业来运行自动化测试，那么除了需要执行的自动化测试脚本之外，您可能不需要下载工件。因此，您可以跳过部署文件，只下载与测试执行相关的工件。

图 10-3

史前古器物

您可以设置允许脚本在代理阶段访问 OAuth 令牌，以便代理作业中的任何脚本任务都可以使用系统访问令牌来访问 Azure DevOps 的 REST API。

代理作业有两种超时设置。超时定义了作业可以在代理中执行的时间。作业取消超时定义在服务器终止作业之前，当发出取消请求时，给作业多少时间来完成。

执行选项允许您定义作业开始的条件。见图 10-4 。如果部署失败，您可能需要设置回滚过程，这在前面的代理作业中已定义。在这种情况下，您可以将其设置为在当前代理作业中的上一个作业失败时执行，并定义回滚任务。如果您希望在成功部署作业后执行自动化测试，您可以设置一个代理作业，以便在成功执行该作业后执行部署，从而在后续作业上执行功能测试，前提是前一个作业成功。但是，与生成代理作业不同，执行是在发布代理作业中按定义的顺序进行的，并且没有像在生成代理作业中那样定义依赖项的选项，因为执行是按发布管道中设置的作业顺序进行的，所以不需要依赖项。

图 10-4

OAuth 令牌和作业运行条件

您可以使用 Azure DevOps 中默认可用的许多任务，以及通过代理作业中的市场扩展添加的任务来执行所需的部署步骤。这些部署步骤可能涉及设置给定环境目标的基础设施，部署您的应用，甚至执行功能和集成测试。在 Azure DevOps 的市场中，你可以找到支持各种平台的任务和几乎所有你需要做的动作。如果找不到任务，你可以自己实现它们，我们将在第十一章详细讨论。您可以将您的任务分组为任务组，以便在多个代理作业中重用它们，我们在第二章中讨论了任务组。

在本课中，我们讨论了在发布管道中使用代理作业。

第 10.02 课:部署组作业

部署组作业意味着在定义的部署组上执行。我们已经在本书的第二章中讨论了部署组和部署池，以及如何将它们添加到具有角色的目标机器中。

在发布管道中，可以在部署组作业中使用团队项目中定义的部署组。您可以使用部署组目标中定义的角色作为给定部署组阶段的必需标记。例如，可以使用部署组作业中的标记将角色设置为 webSvr 的任何机器标识为 Web 服务器，这需要使用应用的 Web 服务器部署步骤进行部署。见图 10-5 。

图 10-5

部署组标记

与代理作业类似，部署组作业也有超时和作业取消超时设置，您可以使用这两个设置来分别确定作业在超时前可以执行的时间，以及在终止前发出取消请求后允许完成作业的时间。

要并行部署的目标设置根据部署组的目标中选定的标记和定义的角色，定义当部署组中有多个目标可用时，部署操作并行执行的目标数量。这使您能够在负载平衡的情况下部署多个 web 服务器，等等。，并行。超时 0 表示无限超时，超时以分钟为单位定义。见图 10-6 。

图 10-6

目标并行设置和超时

与部署组中的代理作业类似，您还可以定义在给定的作业中下载哪些工件。OAuth 令牌访问和基于条件的作业执行也可以像代理作业一样进行设置。这些功能可用于定义部署组的回滚和测试执行场景，正如我们在上一课中对代理作业所做的解释。当使用测试执行时，这种机器中的角色可以是基于标签(如 test client)的测试客户端角色。

这些任务可以在类似于代理作业的部署组阶段中使用，以根据其目标角色实现部署。即使在市场任务中，也可以根据需要利用任务组。

在本课中，我们探索了部署组作业中的可用选项，以在 Azure DevOps 中设置发布管道。

第 10.03 课:无代理作业

无代理作业对于执行不需要计算机来执行正在执行的步骤非常有用。无代理作业可执行的步骤数量有限。见图 10-7 。

图 10-7

无代理作业步骤

使用无代理阶段，您可以使用延迟步骤在给定代理或部署组作业后等待给定时间。延迟时间过后，可以执行下一个代理或部署组作业。这种类型的延迟在诸如在云平台目标上配置基础架构的场景中非常有用。一旦在这样的云平台上执行基础设施命令来提供所需的平台资源，可能会有时间要求。因此，延迟任务可以用来等待这样一个所需的时间。

类似于在管道阶段之间应用的门控，在部署前和部署后阶段，您可以利用无代理阶段来实现代理或部署组作业之间的门控，或者通过使用诸如调用 Azure 函数、调用 REST API、查询 Azure Monitor 警报和查询工作项任务等任务来实现。有关门控的更多信息，请参阅第九章。

手动干预任务可用于在代理或部署组作业之间实施批准、拒绝步骤。在执行管道的下一步之前，如果您希望手动执行某个操作，这些批准可能会很有用。

在无代理作业中，与代理或部署组作业相比，设置最少。参见图 10-8 。无代理作业可以针对乘数中指定的多种配置执行。可以指定超时来执行无代理阶段。运行条件允许您根据上一步成功或失败来定义是否应执行无代理阶段；或者使用自定义条件，帮助您确定是否需要根据管道执行流执行无代理作业。

图 10-8

无代理作业设置

在本课中，我们讨论了无代理阶段以及发布管道中无代理步骤的用法。

第 10.04 课:变量

类似于构建管道的发布管道包含变量。在发布管道的“变量”选项卡中，您可以定义键和值对。变量中包含的敏感信息可以定义为机密，这样的变量值一旦标记为敏感就不可见。参见图 10-9 。

图 10-9

敏感变量

如图 10-9 所示，发布管道中的变量的范围可以是发布或阶段。同一变量在每个阶段可以包含不同的值。对于发布管道中的每个变量，您可以在发布时将其设置为可设置的，这允许在创建发布时设置这些变量的值。参见图 10-10 。

图 10-10

发布时可设置

如第二章所述，变量组可用于为多个发布管道保存共享变量，甚至与构建管道共享变量。这样的变量组可以在具有发布范围或阶段范围的发布管道中使用。见图 10-11 。

图 10-11

发布管道中的变量组

当变量自动解析时，可以在另一个变量中使用$(variablename)来重用变量。这有助于在多个变量中重复值，并确保变量包含唯一的值，只需更改一个位置就可以更改变量值。

在本课中，我们讨论了变量及其在发布管道中的用法。

第 10.05 课:其他有用的功能

发布管道还有一些其他有用的功能:在“保留”选项卡、“选项”选项卡、“历史记录”选项卡中，以及在“导入”、“导出选项”等发布菜单中。

在“保留”选项卡中，您可以设置版本保留设置。有一个链接可以设置项目默认值以及留成。无论保留日期设置如何，您都可以设置保留版本的天数以及应保留的最小版本数。保留天数指定版本将保留的天数。无论天数是多少，在“要保留的最小发布次数”中指定的发布次数都将被保留。参见图 10-12 。

图 10-12

保留

您可以设置版本号格式，并向版本定义添加描述。发布号可以与带有修订版的内部版本号一起使用，以赋予完整发布号更多的含义。参见图 10-13 。

图 10-13

发布号

options 选项卡提供了发布管道的集成选项，可以与存储库、板和外部服务吉拉集成。参见图 10-14 。

图 10-14

集成

发布管道的历史记录提供了发布管道中的修订信息，您可以在其中进行版本比较，并在需要时恢复到给定版本。

在本课中，我们讨论了发布管道的一些有用选项。

摘要

在本章中，我们详细探讨了代理作业、部署组作业和无代理作业及其用法。此外，我们还研究了其他一些特性，如变量、选项、集成、保留设置、发布管道的历史及其使用。

在下一章，我们将探索 REST API 和命令行界面的特性以及它们的用法。

十一、REST API、命令行和扩展开发

在前几章，我们讨论了 Azure DevOps 中的构建和发布管道。我们已经研究了经典和 YAML 管道。对于我们讨论的管道功能，REST API 支持我们以编程方式处理许多操作。此外，Azure DevOps 的命令行界面(CLI)提供了几个命令，可用于构建和发布的编程管理。

对构建和发布管道的编程访问对于生成报告、操纵管道行为，甚至实现管道的可扩展性都很有用。在这一章中，让我们看看如何利用 REST API 和 CLI，以及先决条件是什么。接下来，我们讨论如何使用对构建和发布管道的编程访问来构建扩展。

第 11.01 课:使用构建和发布 REST APIs

Azure DevOps build 的 REST API 提供了几个 API。您可以使用 REST API 执行诸如运行构建、更新构建定义、获取关于构建的细节、标记构建等操作。

REST API 请求/响应对可以用下面列出的五个组件来标识。

• 请求 URI

  VERB https://{instance}[/{team-project}]/_apis[/{area}]/{resource}?api-version={version}

  其中instance将 Azure DevOps 组织或 Azure DevOps 服务器分别定义为dev.azure.com/{organization}或{server:port}/tfs/{collection}。

  资源路径应该是_apis/{area}/{resource}的形式，例如_apis/build/builds。API 版本应定义为表示 REST API 的版本，以{major}.{minor}[-{stage}[.{resource-version}]]的格式使用，例如api-version=5.0或api-version=5.0-preview或api-version=5.0-preview.1

• HTTPS 请求报头

  强制请求头/动词/操作，如 GET、POST、PUT、PATCH 或 HEAD。您可以选择提供一个授权头作为载体令牌。

• 消息请求正文

  为了支持 POST、PUT 操作，您可以为 JSON 这样的主体提供指定为 application/json 的内容类型。

• 响应报文头

  HTTP 响应代码，2xx 表示成功，4xxx、5xx 表示错误。可选的响应头，如 Content-type，以支持请求/响应。

• 响应消息正文

  JSON 或 XML 响应体。

每个请求都应该提供访问 REST API 的授权头。您可以在所需的访问范围内使用 Azure DevOps 中生成的个人访问令牌(PAT )(我们已经在 Azure Boards 手册中更详细地描述了 PAT)。

要在 PowerShell 中创建所需的授权头，可以使用下面的代码段。

$AzureDevOpsPAT = "yourazuredevopsPAT"
$User="";

$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $User,$AzureDevOpsPAT)));
$header = @{Authorization=("Basic {0}" -f $base64AuthInfo)};

然后，您可以在调用请求中使用这个头，如下所示。

$Url = 'https://dev.azure.com/'+ $OrganizationName + '/' + $teamProjectName +
            '/_apis/git/policy/configurations?repositoryId=' + $repository.id + '&refName=refs/heads/' + $fromBranch + '&api-version=5.1-preview.1';

$policies = Invoke-RestMethod -Uri $Url -Method Get -ContentType application/json -Headers $header

使用 REST API 来实现功能，这在 Azure DevOps 中是不可用的，是值得讨论的事情。例如，假设您使用构建策略来保护您的版本(发布)分支。如果您想将一个版本分支中的分支保护构建策略复制到另一个版本，没有现成的方法可以做到这一点。您必须在新分支中手动创建分支保护构建策略。但是，您可以使用 REST API，通过获取一个分支的策略并将其应用到另一个分支来实现 PowerShell 脚本。

另一个例子是，在向给定目标发布时，您可能想要从您的构建的相关变更和工作项中生成一个发布说明。给定目标的发布必须考虑之前对目标所做的发布，然后检查从上一个发布到目标的所有中间发布和构建，以识别当前发布中的所有变更。在这种情况下，REST API 将派上用场，您可以在 PowerShell 中实现所需的功能，并在发布管道中执行它来生成发布说明。

让我们快速看一下如何使用 REST API 对构建进行排队，以理解它是如何工作的。

POST https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.1

您必须为 REST API 的 post 请求提供主体。作为最低要求，所提供的 json 主体应该包含构建定义 id。此外，您可以提供更多信息，如源分支。注意，构建定义 id 48 在下面是硬编码的，它可以被参数化。

{
        "definition": {
            "id": 48
        },
        "sourceBranch": "master"}

此类请求的示例脚本如下所示。

$AzureDevOpsPAT = "yourPAT"
$OrganizationName = "yourAzureDevOpsOrgname"
$teamProjectName = 'yourteamprojectname'

$User="";

$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $User,$AzureDevOpsPAT)));
$header = @{Authorization=("Basic {0}" -f $base64AuthInfo)};

$Url = 'https://dev.azure.com/'+ $OrganizationName + '/' + $teamProjectName + '/_apis/build/builds?api-version=5.1'

$body = '{
        "definition": {
            "id": 48
        },
        "sourceBranch": "master",
    }';

$BuildQResponse = Invoke-RestMethod -Uri $Url -Method Post -ContentType application/json -Headers $header -Body $body

$BuildQResponse

在本课中，我们讨论了使用 REST API 执行构建和发布操作的可能性。此外，几个有用的场景解释了 REST API 可以在哪里使用，我们还看了一个示例来了解它如何与 PowerShell 一起工作。

第 11.02 课:使用 Azure 管道 CLI

与 REST API 类似，我们可以使用 Azure DevOps CLI 进行编程访问，并在 Azure 管道上执行操作。Azure DevOps CLI 是 Azure CLI 的扩展。作为先决条件，您需要安装 Azure CLI。

您可以通过在 PowerShell 窗口或命令提示符中执行az --version来检查当前安装的 Azure CLI 扩展。见图 11-1 。

图 11-1

已安装的 az 扩展

要设置 az devops 扩展，您可以在 PowerShell、命令提示符或终端窗口中执行az extension add --name azure-devops。见图 11-2 。

图 11-2

安装 az devops 扩展

要了解 az devops 扩展中可用的命令，请执行az devops --help。您可以看到有几个可用的命令。除此之外，让我们关注管道命令。见图 11-3 。

图 11-3

az devops 命令

您必须执行az devops login --org orgname，然后在提示获得 Azure DevOps 组织的 CLI 认证时提供 PAT 作为令牌。您也可以使用 Windows 中的$env:AZURE_DEVOPS_EXT_PAT = 'yourPAT'和 Linux 或 macOS 中的export AZURE_DEVOPS_EXT_PAT=yourPAT设置环境变量，然后登录。见图 11-4 。

图 11-4

使用 CLI 登录 Azure DevOps

让我们以 REST APPI 为例，尝试对一个构建进行排队，看看如何使用 CLI 来完成。为了理解 build queue 命令，您可以运行一个az pipelines build queue –help,，它会给出所有的帮助信息。要对一个构建进行排队，您可以运行一个命令，例如,az pipelines build queue -p 'Project X' --definition-id 48,这个构建就会被排队。见图 11-5 。

图 11-5

使用 CLI 构建队列

您可以在 PowerShell 脚本或批处理脚本中使用 CLI，然后将它们用作管道中的步骤或用于其他目的。

在本课中，我们讨论了如何使用 Azure DevOps CLI 对 Azure 管道进行编程访问。

第 11.03 课:开发和分发扩展

如果市场上现有的现成功能或可用的扩展不能满足您对管道的要求，您可以为 Azure 管道开发扩展。

您可以选择使用基于 typescript 或基于 PowerShell 的管道扩展来设置管道扩展。但是，只有 windows 代理能够运行基于 PowerShell 的任务。如果您打算在所有代理平台上运行管道扩展，建议使用 typescript 来开发管道扩展。

您需要在 PowerShell 的文件夹中或终端窗口中运行一个npm init来为扩展完成 npm 初始化。出现提示时提供所需的信息，初始 package.json 将在该文件夹中创建。见图 11-6 。

图 11-6

npm 初始化以创建 package.json

然后可以运行 NPM install azure-pipelines-task-lib-save 添加任务库来创建管道任务。见图 11-7 。这会将所需的节点模块安装到您的扩展文件夹中。

图 11-7

添加管道任务库

然后，您需要通过执行以下命令来添加 typescript 类型。

npm install @types/node --save-dev
npm install @types/q --save-dev

运行tsc –init以确保在构建扩展时 typescripts 被编译成 javascripts。如果您的机器中还没有安装 typescript，您需要使用npm install -g typescript命令全局安装它。

有了这个所有需要开发的结构，你的扩展就创建在文件夹中了。接下来，您需要将任务 json 添加到扩展任务文件夹中。您可以使用下面显示的模板，并用所需的值替换{{placeholder}}。Microsoft 文档中提供了该模板，建议从文档中复制最新的模板。以下文件内容中的输入是为示例任务设计的，您可能需要根据您的任务需求使用输入。

{
    "$schema": "https://raw.githubusercontent.com/Microsoft/azure-pipelines-task-lib/master/tasks.schema.json",
    "id": "{{taskguid}}",
    "name": "{{taskname}}",
    "friendlyName": "{{taskfriendlyname}}",
    "description": "{{taskdescription}}",
    "helpMarkDown": "",
    "category": "Utility",
    "author": "{{taskauthor}}",
    "version": {
        "Major": 0,
        "Minor": 1,
        "Patch": 0
    },
    "instanceNameFormat": "Echo $(samplestring)",
    "inputs": [
        {
            "name": "samplestring",
            "type": "string",
            "label": "Sample String",
            "defaultValue": "",
            "required": true,
            "helpMarkDown": "A sample string"
        }
    ],
    "execution": {
        "Node10": {
            "target": "index.js"
        }
    }
}

上述任务 json 文件中的可替换值可以像下面这样更新。

    "id": "bdf70ab0-8600-45fd-98d4-834e22030ff6",
    "name": "chamindacdemotask",
    "friendlyName": "My Demo Task",
    "description": "Demo Task",
    "helpMarkDown": "",
    "category": "Utility",
    "author": "chamindac",

然后，我们可以使用下面的内容创建一个 intex.ts (typescript 文件)来启用演示/示例任务的功能。

import tl = require('azure-pipelines-task-lib/task');

async function run() {
    try {
        const inputString: string | undefined = tl.getInput('samplestring', true);
        if (inputString == 'bad') {
            tl.setResult(tl.TaskResult.Failed, 'Bad input was given');
            return;
        }
        console.log('Hello', inputString);
    }
    catch (err) {
        tl.setResult(tl.TaskResult.Failed, err.message);
    }
}

run();

然后可以从扩展文件夹中执行tsc，将 typescript 编译成 javascript。现在，如果您运行node index.js,，它将在本地测试扩展；但是，由于没有提供输入，它将失败。见图 11-8 。

图 11-8

测试扩展任务

您可以提供一个带有$env:INPUT_SAMPLESTRING="Chaminda"的输入字符串，并测试它来检查是否成功执行。见图 11-9 。

图 11-9

提供输入参数值的测试函数

要部署扩展，您需要打包它。但是在打包之前，您需要为它创建一个清单文件。对于我们使用的示例，您可以创建一个名为 vss-extension.json 的文件，并添加下面的内容。

{
    "manifestVersion": 1,
    "id": "build-release-task",
    "name": "Chamidac Build and Release Tools",
    "version": "0.0.1",
    "publisher": "chamindac",
    "targets": [
        {
            "id": "Microsoft.VisualStudio.Services"
        }
    ],
    "description": "Tools for building/releasing with chamindac. Includes one build/release task.",
    "categories": [
        "Azure Pipelines"
    ],
    "icons": {
        "default": "img/extension-icon.png"
    },
    "files": [
        {
            "path": "buildAndReleaseTask"
        }
    ],
    "contributions": [
        {
            "id": "custom-build-release-task",
            "type": "ms.vss-distributed-task.task",
            "targets": [
                "ms.vss-distributed-task.tasks"
            ],
            "properties": {
                "name": "buildAndReleaseTask"
            }
        }
    ]
}

要打包您的扩展，您需要有 tfx CLI，它可以用npm i -g tfx-cli命令安装。您必须在扩展文件夹中创建一个名为buildAndReleaseTask的文件夹，并移动除了vss-extension.json文件之外的所有文件和文件夹。您可以在扩展中添加更多文件夹，并添加更多任务来创建包含多个任务的扩展。然后从扩展文件夹中，run tfx extension create --manifest-globs vss-extension.json命令将扩展打包。

要创建发布者，您必须登录 https://marketplace.visualstudio.com/manage 并设置您的发布者档案。然后，您可以使用tfx extension publish --manifest-globs vss-extension.json --share-with https://dev.azure.com/yourorgname 命令将您的扩展发布、共享到您的组织。

发布后，您的扩展模块可以共享给其他组织或公开共享。参见图 11-10 。

图 11-10

扩展ˌ扩张

在本课中，我们讨论了如何为 Azure pipelines 构建扩展。

摘要

在本章中，我们讨论了使用 REST API 和命令行界面对 Azure 管道的编程访问。此外，我们已经讨论了构建管道扩展所需的基本步骤。

在下一章中，我们将看看测试自动化与 Azure 管道的集成选项。

十二、将测试集成到管道中

测试是软件交付过程中非常重要的一个方面。为了保证交付的软件项目或产品的质量，一些测试类型可以很容易地自动化，并与构建和发布管道相集成。

在这一章中，我们将会看到可以自动化的测试类型，以及我们可以用来有效运行管道自动化测试的特性和组件。

第 12.01 课:使用管道运行单元测试

用单元测试验证应用的代码以确保代码按预期运行是很重要的。实现单元测试是为了测试开发人员使用测试驱动开发方法(TDD)和行为驱动开发(BDD)编写的代码。

构建管道可以用来执行用许多类型的单元测试工具编写的单元测试。通常的做法是构建代码，然后执行单元测试，并将代码打包成可部署的二进制文件。要使用构建管道执行测试，您可以找到几个可用的任务。见图 12-1 。

图 12-1

测试任务

使用 Visual Studio 测试任务，您可以执行使用测试框架(如 MSTest、xUnit、NUnit 等)开发的多种类型的测试。该任务允许您在代理作业中使用多代理配置的同时，将测试分布在多个代理中，以便高效地运行它们。

还有其他任务，如 dotnet 命令行任务，允许您运行 dotnet 测试来执行使用开发的测试。NET 核心。命令行任务可用于执行机器学习代码单元测试运行等任务。见图 12-2 。

图 12-2

运行 Python 测试

当从 VS 测试任务或 dotnet 测试运行测试时，测试运行的结果会自动发布到管道。但是，如果您使用命令行执行测试，例如 Python 测试，则可能需要将测试结果的输出发布到管道，以便结果显示在已执行构建的 test 选项卡中。若要发布测试结果，可以使用“发布测试结果”任务，并指定测试执行的结果输出文件和测试结果的格式，以便将其发布到管道。见图 12-3 。

图 12-3

发布测试结果

在本课中，我们讨论了如何利用可用于管道的任务，通过构建管道来设置单元测试执行。

第 12.02 课:使用管道运行功能测试

集成和功能测试用于测试部署的应用。它们可能被实现为使用不同测试框架的 API 级测试或用户界面测试。Selenium 是广泛使用的主要测试框架之一。Net 等语言。还有其他的测试框架，比如 Cypress，它也在促进基于场景的功能 UI 测试实现。

测试应用的自动化功能测试应该在部署到给定目标后执行，以确保目标应用按预期运行。自动化和使用部署管道运行自动化的功能测试使团队能够为每个版本运行他们的大部分测试，从而在交付的应用中实现更高的质量。

基于 Selenium 的功能测试要求您以交互模式运行代理来执行测试。我们在本书第三章中讨论了如何设置代理。然而，Cypress 框架 UI 测试也可以用非交互式代理来执行。

要执行基于 Selenium 的测试，您可以利用虚拟机或物理机中的代理设置作为交互式代理。这样的代理应该为 Visual Studio 测试平台安装程序任务的测试执行做好准备。见图 12-4 。

图 12-4

VS 测试平台安装程序

然后，您可以使用 VS 测试任务来执行使用 C#用 Selenium 编写的测试。如果您已经用 Java 开发了测试，那么您可以使用 Maven 任务来执行发布管道中的测试。

测试执行可能需要您使用虚拟机作为测试客户端，尤其是当您需要运行交互式代理时。您可能需要设置多台测试客户机来有效地分发和运行您的功能测试。然而，保持这些虚拟机在诸如 Azure 的云平台中持续运行将是昂贵的。为了最小化成本，您可以在测试执行之前设置机器的按需启动；一旦测试执行完成，关闭测试客户端，这样云平台上的费用将被最小化。见图 12-5 。

图 12-5

测试客户端按需启动和停止

在本课中，我们讨论了使用发布管道来执行功能测试。

摘要

在这一章中，我们讨论了使用单元测试和功能测试来确保所交付的应用的质量。

在本书中，我们讨论了关于 Azure pipelines 的几个重要事实。在介绍性章节中，我们已经讨论了为什么我们需要实现持续集成和交付。然后，我们探讨了代理池和代理，甚至部署设置。接下来，我们将在接下来的几章中详细讨论经典的构建管道。还讨论了 YAML 管道，使您能够理解管道作为代码的用法。除此之外，我们还讨论了发布管道的使用，以及在发布和构建管道中测试执行的实现和使用。总的来说，这本书让你对实现和使用 Azure pipelines 有了基本的了解，使你能够快速部署软件应用，同时不影响所交付的应用的质量。