原文：
annas-archive.org/md5/b9af5174af71449b8d6f11a56dee9821译者：飞龙
第三部分：工件与部署
在本节中，我们将介绍如何在 Azure DevOps 中使用工件以及如何通过管道部署应用程序。
本节包含以下章节：
-
第七章，在 Azure DevOps 中使用工件
-
第八章，使用 Azure DevOps 部署应用程序
第七章：
第八章：在 Azure DevOps 中使用 Artifacts
在上一章中，我们讲解了如何在 Azure Pipelines 中托管构建代理。在本章中，我们将讲解如何在 Azure DevOps 中使用 Artifacts。我们将从解释什么是 Artifacts 开始。然后，我们将看看如何在 Azure DevOps 中创建它们，以及如何从构建管道中生成工件包。接下来，我们将讲解如何使用发布管道部署供稿。然后，我们将讲解如何设置供稿权限，以及如何在 Visual Studio 中消费包。最后，我们将讲解如何使用 WhiteSource Bolt 扫描包漏洞。
本章将涵盖以下主题：
-
介绍 Azure Artifacts
-
使用 Azure Artifacts 创建工件供稿
-
使用构建管道生成包
-
从构建管道将包发布到供稿中
-
从供稿设置中配置供稿权限
-
从 Artifacts 供稿中在 Visual Studio 中消费包
-
使用 WhiteSource Bolt 扫描包漏洞
技术要求
要跟随本章内容，你需要有一个活跃的 Azure DevOps 组织。我们将在本章中使用的组织是PartsUnlimited组织，具体内容在第一章**，Azure DevOps 概述中创建。你还需要安装 Visual Studio 2019，可以从visualstudio.microsoft.com/downloads/下载。
我们示例应用程序的源代码可以从github.com/PacktPublishing/Learning-Azure-DevOps---B16392/tree/master/Chapter%207下载。
介绍 Azure Artifacts
每个开发者很可能都在代码中使用过第三方或开源包，以增加额外的功能并加快应用程序开发过程。使用社区已使用并测试过的流行的预构建组件，将帮助你更轻松地完成工作。
在你的组织中，由不同团队构建的功能、脚本和代码经常被其他团队和不同的软件开发项目重用。这些不同的工件可以被移动到一个库或包中，以便其他人也能从中受益。
有多种方式可以构建和托管这些包。例如，你可以使用 NuGet 托管和管理 Microsoft 开发平台的包，或使用 npm 托管 JavaScript 包，Maven 托管 Java 包等等。Azure Artifacts 提供了便捷的功能，使你可以轻松地共享和重用包。在 Azure Artifacts 中，包被存储在供稿中。供稿是一个容器，允许你将包进行分组，并控制谁可以访问它们。
你可以将包存储在你自己或其他团队创建的源中，但它也内置支持上游源。通过上游源，你可以创建一个单一源，用于存储组织生产的包以及从远程源消费的包，如 NuGet、npm、Maven、Chocolatey、RubyGems 等。
强烈建议将 Azure Artifacts 用作发布内部包和远程源的主要来源。原因在于，它能够让你全面了解组织和不同团队使用的所有包。源能够知道所有使用上游资源保存的包的来源，即使原始源宕机或包被删除，包也会被保存在源中。包是有版本管理的，通常你可以通过指定你想在应用程序中使用的包版本来引用一个包。
许多包允许无需登录即可访问。然而，也有一些包需要我们通过用户名和密码组合或访问令牌进行身份验证。对于后者，访问令牌可以设置为在指定的时间后过期。
在下一部分，我们将讨论如何在 Azure DevOps 中创建一个工件源。
使用 Azure Artifacts 创建工件源
在这个演示中，我们将创建一个 Azure Artifacts 中的工件源。包存储在源中，这些源本质上是组织结构，用于将包分组并管理其权限。每种包类型（NuGet、npm、Maven、Python 和 Universal）都可以存储在一个源中。
在本次演示中，我们将再次使用我们的PartsUnlimited示例项目，并向项目中添加一个新的工件源。为此，请执行以下步骤：
-
打开一个浏览器并导航到
dev.azure.com/。 -
使用你的 Microsoft 帐户登录，并从左侧菜单选择Artifacts。然后，点击**+ 创建源**按钮。
-
在创建新源对话框中，添加以下值（确保上游源被禁用；我们在本章中不会使用远程源中的包）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.01_B16392.jpg
图 7.1 – 创建一个新源
-
点击创建按钮。
通过以上操作，我们已经创建了一个新的源，以便我们可以存储我们的包。在下一部分，我们将通过构建管道生成一个包。
通过构建管道生成包
现在我们已经创建了我们的源，接下来我们将创建一个构建流水线，在项目构建过程中自动创建一个包。在本例中，你可以使用本书 GitHub 代码库中提供的示例项目。这个示例项目包含了PartsUnlimited项目中的所有模型。我们将把所有模型添加到一个包中，并通过 Artifacts 进行分发。这样，你就可以在不同的项目之间轻松共享数据模型。
第一步是将 GitHub 代码库导入到 Azure DevOps 中的PartsUnlimited组织。
将示例项目添加到 PartsUnlimited 代码库
要将示例模型项目添加到 PartsUnlimited 代码库中，请执行以下步骤：
-
导航到 Azure DevOps 中的PartsUnlimited项目，并转到Repos > Files。
-
从PartsUnlimited下拉菜单中选择导入代码库：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.02_B16392.jpg
图 7.2 – 导入代码库
-
将源代码库的 URL 输入到Clone URL框中，并为你的新 GitHub 代码库添加一个名称：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.03_B16392.jpg
图 7.3 – 指定代码库的 URL
-
点击导入。
-
一旦项目被导入，代码库将如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.04_B16392.jpg
图 7.4 – Azure DevOps 中的代码库
现在我们已经将PartsUnlimited.Models项目导入到 Azure DevOps 代码库中，可以在构建流水线中使用它来创建 NuGet 包。
在接下来的部分中，我们将创建一个构建流水线，自动将我们的项目打包成一个 Artifact 包。
创建构建流水线
现在项目已经添加到代码库中，我们可以创建构建流水线。为此，请执行以下步骤：
-
再次导航到 Azure DevOps 并打开PartsUnlimited.Models项目。从左侧菜单中点击Pipelines。
-
从右上角菜单中点击新建流水线，然后在向导的第一个屏幕中选择使用经典编辑器。
-
在第二个屏幕上，设置如下截图所示的属性，然后点击继续：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.05_B16392.jpg
图 7.5 – 选择源
-
在向导的下一个屏幕中选择ASP.NET，然后点击应用。这样，构建流水线就会被创建。点击Agent job 1右侧的**+号，并搜索NuGet**。
-
将 NuGet 任务添加到流水线：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.06_B16392.jpg
图 7.6 – 添加 NuGet 任务
-
重新排列任务，并将 NuGet 任务拖动到Build Solution任务之后。删除Test Assemblies方法，因为该项目中没有测试：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.07_B16392.jpg
图 7.7 – 重新排序任务
-
对新添加的任务的设置进行以下更改：
–
NuGet pack–
pack–
**/*.csproj -
完成这些更改后，任务将如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.08_B16392.jpg
图 7.8 – 配置任务
-
接下来，让我们设置包的版本控制。推荐的包版本控制方法是使用
1–
0–
0–时区：UTC
-
从顶部菜单中选择Save & queue，然后选择Save and run。
构建管道现在将成功运行。在下一部分，我们将把在第一个演示中创建的PartsUnlimited.Models NuGet 包发布到我们的 feed。
从构建管道将包发布到 feed
现在我们已经构建了应用程序和包，并从构建管道中生成了包，我们可以将该包发布到我们在第一个演示中创建的 feed。
为此，我们需要在 feed 上设置所需的权限。构建将以其身份运行，该身份需要在 feed 上具有Contributor权限。一旦设置了这些权限，我们就可以扩展我们的管道，将包推送到 feed。
设置 feed 上的所需权限
要设置所需的权限，我们需要进入 feed 的设置：
-
使用您的 Microsoft 帐户登录，并从左侧菜单中选择Artifacts。
-
转到 feed 的设置，通过点击右上角菜单中的Settings按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.09_B16392.jpg
图 7.9 – 打开 feed 设置
-
然后，从顶部菜单中点击Permissions，点击**+ Add users/groups**：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.10_B16392.jpg
图 7.10 – Feed 权限设置
-
添加与项目同名的构建，在我的例子中是Parts.Unlimited Build Service身份：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.11_B16392.jpg
图 7.11 – 添加构建身份
-
点击Save。
现在，构建管道的身份已在 feed 上拥有所需的权限，我们可以在构建过程中将包推送到该 feed。
发布包
我们现在准备扩展构建管道，并将包从构建管道推送到 feed。为此，我们需要执行以下步骤：
-
导航到 Azure DevOps，打开PartsUnlimited.Models项目。在左侧菜单中点击Pipelines。
-
选择我们在上一步中创建的构建管道，然后点击右上角菜单中的Edit按钮。
-
再次点击Agent job 1旁边的**+**按钮，搜索 NuGet，并将任务添加到管道中。
-
将新添加的任务拖到我们在上一步中创建的 NuGet 任务下方。对任务的设置进行以下更改：
–
NuGet push–
$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg–目标 feed 位置：此组织/集合
–目标源：PacktLearnDevOps
-
在进行这些更改后，任务将如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.12_B16392.jpg
图 7.12 – 添加 NuGet 推送任务
-
从顶部菜单选择保存并排队，然后选择保存并运行。等待构建管道成功完成。
-
最后，让我们检查一下包是否成功发布。点击左侧菜单中的Artifacts。你会看到包已成功推送到源中：
图 7.13 – 推送的包
现在我们有了一个带有模型的包，我们可以在 Visual 项目中使用它。在接下来的部分，我们将创建一个应用程序并从 Azure DevOps 的源中消费该包。
从 Artifacts 源中消费包
现在，我们的PartsUnlimited.Models包已经推送到 Artifacts 中的源，我们可以从 Visual Studio 中消费这个包。在这一部分，我们将创建一个新的控制台应用程序，并从那里连接到源。
因此，我们需要执行以下步骤：
-
打开 Visual Studio 2019 并创建一个新的 .NET Core 控制台应用程序：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.14_B16392.jpg
图 7.14 – 创建新的控制台包
-
应用程序创建完成后，导航到 Azure DevOps，从左侧菜单选择Artifacts。
-
从顶部菜单选择连接到源：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.15_B16392.jpg
图 7.15 – 连接到源
-
在下一个屏幕中，从列表中选择Visual Studio。我们将使用这些设置在下一步中设置机器：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.16_B16392.jpg
图 7.16 – Visual Studio 机器设置
-
返回到 Visual Studio 中的控制台应用程序。然后，从顶部菜单选择工具 > NuGet 包管理器 > 管理解决方案的 NuGet 包：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.17_B16392.jpg
图 7.17 – NuGet 包安装器
-
要将源添加到项目中，点击设置图标：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.18_B16392.jpg
图 7.18 – NuGet 设置
-
点击
https://pkgs.dev.azure.com/PacktLearnDevOps/_packaging/PacktLearnDevOps/nuget/v3/index.json。添加这些值后的结果如下所示：
图 7.19 – 添加源的包源
-
点击更新，然后点击确定。
-
现在，我们可以在应用程序中消费这个源。在 NuGet 包管理器中，选择我们刚刚添加的包源。确保勾选包括预发布版本，因为这个包尚未发布：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.20_B16392.jpg
图 7.20 – 选择包源
-
选择包并将其安装到项目中。
-
现在，我们可以在代码中引用该包并使用模型类。添加
using语句，并通过以下代码替换Program.cs文件中的代码，创建一个新的CarItem：using System; using PartsUnlimited.Models; namespace AzureArtifacts { class Program { static void Main(string[] args) { Console.WriteLine("Hello World!"); CartItem caritem = new CartItem() { CartId = "1", Count = 10, DateCreated = DateTime.Now, Product = new Product() { Title = "Product1" }, ProductId = 21 }; } } }
在这个演示中，我们使用的是从 feed 自动构建和发布的包。在本章的下一部分也是最后一部分中，我们将探讨如何使用 WhiteSource Bolt 扫描包中的漏洞。
使用 WhiteSource Bolt 扫描包中的漏洞
WhiteSource Bolt 可直接从构建管道扫描包中的漏洞。它是一个开发者工具，用于扫描应用代码以及开源应用和包中的安全漏洞。它提供了可以通过 Azure DevOps 市场和 GitHub 安装的扩展。WhiteSource Bolt 可以免费下载，但此版本每天每个仓库的扫描次数限制为五次。
重要提示
关于 WhiteSource Bolt 的更多信息，您可以参考以下网站：bolt.whitesourcesoftware.com/。
在本节中，我们将安装扩展到我们的 Azure DevOps 项目中，并将其自带的任务实施到现有的构建管道中。让我们开始吧：
-
打开浏览器并访问
marketplace.visualstudio.com/。 -
在搜索框中搜索 WhiteSource Bolt 并选择 WhiteSource Bolt 扩展：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.21_B16392.jpg
图 7.21 – 安装 WhiteSource Bolt
-
通过选择组织并点击 安装 按钮，在您的 DevOps 组织中安装扩展：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.22_B16392.jpg
图 7.22 – 在您的组织中安装扩展
-
安装包后，返回到 Azure DevOps > Pipelines。您将看到 WhiteSource Bolt 已添加到菜单中。选择它：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.23_B16392.jpg
图 7.23 – WhiteSource Bolt 菜单项
-
在 设置 页面上，指定工作邮箱地址、公司名称和国家/地区。然后，点击 开始使用 按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.24_B16392.jpg
图 7.24 – WhiteSource Bolt 设置
-
我们现在可以在管道中使用 WhiteSource Bolt 任务了。选择我们在 创建构建管道 部分中创建的构建管道。现在，编辑管道。
-
再次向管道中添加一个新任务，就像我们在 创建构建管道 部分中所做的那样，搜索 WhiteSource Bolt，并将该任务添加到管道中：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.25_B16392.jpg
图 7.25 – 添加 WhiteSource Bolt 任务
-
将任务拖动到构建解决方案任务的下方，因为我们希望在将包打包并推送到 Artifact feed 之前扫描解决方案。效果如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.26_B16392.jpg
Figure 7.26 – 构建管道概述
-
您不必指定任何配置值；此任务将在没有它们的情况下运行。
-
从顶部菜单中，选择保存并排队，然后选择保存并运行。等到构建管道成功完成。
-
再次转到顶部菜单，选择WhiteSource Bolt Build Support。在那里，您将看到扫描的概述：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_7.27_B16392.jpg
Figure 7.27 – WhiteSource Bolt 漏洞报告
通过此操作，我们已安装了 WhiteSource Bolt 扩展，并在将 NuGet 包打包并推送到 Azure Artifacts 的 feed 之前扫描了我们的解决方案中的漏洞。
这章就到这里了。
总结
在本章中，我们更深入地了解了 Azure Artifacts。首先，我们设置了一个 feed，并使用PartsUnlimited项目中的模型类创建了一个新的 NuGet 包。然后，我们创建了一个构建管道，在构建过程中自动打包并将包推送到 feed 中。最后，我们使用 Azure 市场上的 WhiteSource Bolt 扩展来扫描包中的漏洞。
在下一章中，我们将重点介绍如何使用发布管道在 Azure DevOps 中部署应用程序。
进一步阅读
查看以下链接以获取本章涵盖的更多信息：
-
什么是 Azure Artifacts？：
docs.microsoft.com/zh-cn/azure/devops/artifacts/overview?view=azure-devops -
在 Azure DevOps Services 和 TFS 中开始使用 NuGet 包：
docs.microsoft.com/zh-cn/azure/devops/artifacts/get-started-nuget?view=azure-devops
第八章：
第九章：使用 Azure DevOps 部署应用程序
在前几章中，我们看到如何通过使用构建流水线自动化代码的开发过程。但软件生命周期中一个重要的部分是发布阶段。在本章中，我们将介绍发布流水线的概述；我们将学习如何使用 Azure DevOps 创建发布流水线，以及如何通过使用发布审批和多阶段流水线自动化和改进解决方案的部署。
本章将涵盖以下内容：
-
发布流水线概述
-
使用 Azure DevOps 创建发布流水线
-
在发布流水线上配置持续部署
-
创建多阶段发布流水线
-
使用审批和门控控制你的发布过程
-
使用环境和部署组
-
使用基于 YAML 的流水线进行发布
技术要求
要跟随本章内容，你需要有一个有效的 Azure DevOps 组织。本章中使用的组织是我们在第一章中创建的PartsUnlimited组织，Azure DevOps 概述。
发布流水线概述
发布流水线允许你实现软件生命周期中的持续交付阶段。通过发布流水线，你可以自动化测试过程，并将你的解决方案（提交的代码）交付到最终环境或直接交付到客户现场（持续交付和持续部署）。
通过持续交付，你将代码交付到某个环境进行测试或质量控制，而持续部署则是将代码发布到最终生产环境的阶段。
发布流水线可以手动触发（你决定何时部署代码），也可以根据事件触发，如主分支上的代码提交、阶段完成后（例如，生产测试阶段），或根据计划触发。
发布流水线通常连接到工件存储（应用程序的可部署组件和构建的输出）。工件存储包含一组构建的工件（不同版本的工件），而发布流水线则取这些工件并提供所需的基础设施和步骤来部署这些工件。
发布流水线（正如我们在第四章中所看到的，理解 Azure DevOps 流水线，针对构建流水线定义）由不同的阶段（可以独立运行的流水线部分）组成，每个阶段由作业和任务组成。
发布流水线的架构如下：
图 8.1 – 发布流水线架构
正如你在上面的图示中看到的，发布流水线从工件（成功完成构建的输出）开始，然后在各个阶段之间移动，执行作业和任务。
在 Azure DevOps 中，发布管道按以下步骤执行：
-
当触发部署请求时，Azure Pipelines 会检查是否需要预部署审批阶段，并最终将审批通知发送给团队中相关人员。
-
经批准后，部署作业会排队并等待代理程序。
-
能够运行此部署作业的代理程序将获取该作业。
-
代理程序会下载发布管道定义中指定的工件。
-
代理程序运行部署作业中定义的任务，并为每个步骤创建日志。
-
当某个阶段的部署完成后，Azure Pipelines 会执行后部署审批（如果有的话）。
-
然后部署进入下一个阶段。
在发布管道中，工件被部署到环境（你的最终应用将运行的地方），这些环境可以是以下几种：
-
你公司网络上的一台机器
-
云中的一台虚拟机
-
一个容器化环境，例如 Docker 或 Kubernetes
-
一种托管服务，例如 Azure 应用服务
-
无服务器环境，例如 Azure Functions
定义 Azure Pipelines 环境的一种方式是使用 YAML 文件，你可以在其中包含一个环境部分，指定你将部署工件的 Azure Pipelines 环境，或者使用经典的基于 UI 的编辑器
在接下来的部分，我们将详细了解如何使用 Azure DevOps UI 定义发布管道。
使用 Azure DevOps 创建发布管道
实现完整 CI/CD 流程的最终目标是自动化将软件部署到最终环境（例如，最终客户），为了实现这一目标，你需要创建一个发布管道。
发布管道将构建产物（构建过程的结果）部署到一个或多个最终环境。
要创建我们的第一个发布管道，我们将使用之前在 Azure DevOps 上部署的PartsUnlimited Web 应用项目：
-
要在 Azure DevOps 中创建发布管道，请点击左侧菜单中的管道，选择发布，然后点击新建发布管道:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.02_B16392.jpg
图 8.2 – 创建新发布管道
-
在右侧出现的选择模板列表中，你可以看到一组可用模板，用于创建适用于不同类型应用和平台的发布。对于我们的应用，选择Azure 应用服务部署，然后点击应用:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.03_B16392.jpg
图 8.3 – 发布管道模板选择
-
现在，为将包含发布任务的阶段提供一个名称。在这里，我将其命名为
Deploy to cloud:https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.04_B16392.jpg图 8.4 – 阶段名称
-
在阶段部分，点击1 个任务，1 个工作链接。在这里，你需要提供你的应用程序将要部署的 Azure Web 应用环境的设置，例如 Azure 订阅和应用服务实例（Web 应用），其中代码将被部署：
图 8.5 – 阶段设置
你现在已经定义了发布管道的阶段（单阶段）。在下一部分，我们将看到如何为发布管道指定工件。
定义发布管道的工件
工件是所有必须部署到最终环境中的项目（构建的输出），Azure Pipelines 可以部署来自不同工件源的工件：
-
要选择工件，在主发布管道屏幕上，点击添加工件：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.06_B16392.jpg
图 8.6 – 向发布管道添加工件
-
在添加工件面板中，源类型默认设置为构建（这意味着你正在部署构建管道的输出）。在这里，你需要选择你想作为源的构建管道（发布工件的构建管道的名称或 ID；这里我使用的是PartsUnlimitedE2E构建管道）和默认版本（默认版本将在创建新发布时部署。对于手动创建的发布，版本可以在发布创建时更改）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.07_B16392.jpg
图 8.7 – 添加工件
-
点击添加按钮保存工件配置，然后点击右上角的保存按钮保存你的发布管道：
图 8.8 – 保存发布管道
你的发布管道现在已经准备就绪。在下一部分，我们将看到如何创建 Azure DevOps 发布过程。
创建 Azure DevOps 发布
在定义了发布管道（阶段和工件）之后，我们需要创建一个发布。发布只是运行你的发布管道的一次执行：
-
要创建发布，在发布管道定义页面，点击右上角的创建发布按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.09_B16392.jpg
图 8.9 – 创建发布
-
在创建新发布页面，接受所有默认值（你需要有一个成功完成的构建，且已创建工件），然后点击创建：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.10_B16392.jpg
图 8.10 – 创建发布
-
一个新的发布已创建，你会看到一个绿色的进度条，表示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.11_B16392.jpg
图 8.11 – 发布已创建
-
现在，你可以点击发布名称（这里是Release-1），你将被重定向到发布过程的详细信息：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.12_B16392.jpg
图 8.12 – 发布详情
-
如果你点击阶段，你可以看到每个步骤的详细信息：
图 8.13 – 阶段详细信息
你已经完成了第一个发布管道。在这里，我们手动触发了它。在下一部分，我们将看到如何在管道中使用变量。
在发布管道中使用变量
在发布管道中，你还可以使用变量和变量组来指定可以在管道任务中使用的变量参数。要为发布管道指定变量，选择变量选项卡并指定变量的名称和值：
图 8.14 – 发布管道变量
然后，你可以通过使用$(VariableName)符号在管道任务中使用这些变量，如下图所示：
图 8.15 – 在发布管道任务中使用变量
如果你的管道中有会变化的参数，建议使用变量。在下一部分，我们将看到如何为持续部署配置触发器。
配置持续部署的发布管道触发器
为了自动化你的应用程序的持续部署，你需要在发布管道定义中配置触发器：
-
要做到这一点，点击管道工件部分的持续部署触发器图标：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.16_B16392.jpg
图 8.16 – 持续部署触发器
-
在持续部署触发器面板中，启用它以在每次成功完成构建后自动创建新版本，并选择一个分支过滤器（例如，构建管道的默认分支）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.17_B16392.jpg
图 8.17 – 持续部署触发器配置
-
现在，在阶段部分，选择部署前条件图标：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.18_B16392.jpg
图 8.18 – 部署前条件
-
在部署前条件面板中，检查此阶段的触发器是否设置为发布后（这意味着当从此管道创建新发布时，部署阶段将自动开始）：
图 8.19 – 部署前条件定义
在此面板中，你还可以定义其他参数，例如选择触发新部署的工件条件（仅当所有工件条件匹配时，才会将发布部署到此阶段）、设置部署的时间表、允许基于拉取请求的发布部署到此阶段、选择可以批准或拒绝部署到此阶段的用户（预部署审批）、定义部署前需要评估的门控，并定义在多个发布排队等待部署时的行为。
你现在已经创建了一个发布管道，它将你的工件通过 Azure DevOps 部署到云，并应用了持续部署触发器和预部署条件检查。
在下一节中，我们将看到如何通过使用多个阶段来改进我们的发布管道。
创建一个多阶段发布管道
多阶段发布管道在你想通过多个步骤（例如开发、预发布和生产）发布应用程序时非常有用。一个非常常见的实际场景是，例如，首先将应用程序部署到测试环境。当测试完成后，应用程序会移动到质量验收阶段，然后如果客户接受发布，应用程序会移动到生产环境。
在这里，我们将做相同的事情：从之前创建的单阶段管道开始，我们将创建一个新的发布管道，包含三个阶段，分别为DEV、QA和Production。每个阶段都是我们管道的部署目标：
-
在之前定义的管道中，作为第一步，我将部署到云阶段重命名为Production。这将是发布管道的最终阶段。
-
现在，点击克隆操作，将已定义的阶段克隆为一个新阶段：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.20_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.20_B16392.jpg)
图 8.20 – 克隆一个阶段
-
一个新的克隆阶段出现在之前创建的阶段后面。将此阶段的名称更改为
QA：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.21_B16392.jpg](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.21_B16392.jpg)
图 8.21 – 克隆的阶段（QA）
-
现在，我们需要重新组织阶段，因为QA阶段必须在Production阶段之前执行。要重新组织这些阶段，请选择QA阶段并选择预部署条件。在预部署条件面板中，将触发器设置为After release（而不是After stage）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.22_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.22_B16392.jpg)
图 8.22 – QA 阶段的预部署条件
-
如你所见，管道图现在发生了变化（你现在有QA和Production阶段并行执行）。现在，选择Production阶段的预部署条件属性；将触发器设置为After stage，并选择QA作为阶段：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.23_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.23_B16392.jpg)
图 8.23 – Production 阶段的预部署条件
-
现在，阶段已按我们想要的顺序排列（QA 发生在 Production 之前）。
-
此时，我们有两个阶段将应用部署到相同的环境（QA 是作为 Production 的克隆创建的）。从 Tasks 下拉列表中选择 QA 阶段，并将 App service name 更改为一个新实例：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.24_B16392.jpg
图 8.24 – QA 阶段详情
-
现在，我们需要重复相同的步骤来创建 DEV 阶段。从 QA 克隆它，设置其 Pre-deployment conditions 属性，将触发器设置为 After Release，并将 QA 的触发器更改为 After stage，选择 DEV 作为所选阶段。你的流水线现在将如下所示：
现在，你已经创建了一个包含不同阶段（Dev、QA 和 Production）的发布流水线，用于控制代码的部署步骤。
在下一部分，我们将看到如何在阶段之间移动时添加审批。
使用审批和门控来管理部署
如前所述配置，我们的发布流水线只有在前一个阶段成功完成后才会移动到下一个阶段。这对于从 DEV 到 QA 的过渡是可以的，因为在这个过渡中，我们的应用程序被部署到测试环境，但从 QA 到 Production 的过渡通常应该受到控制，因为应用程序发布到生产环境通常发生在审批之后。
创建审批
让我们按照以下步骤创建审批：
-
要创建审批步骤，从我们的流水线定义中，选择 Production 阶段的 Pre-deployment conditions 属性。然后，进入 Pre-deployment approvals 部分并启用它。接着，在 Approvers 部分，选择将负责审批的用户。请同时检查 The user requesting a release or deployment should not approve it 选项未被勾选：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.26_B16392.jpg
图 8.26 – 设置审批
-
点击 Save 保存你的流水线定义。
-
现在，创建一个新的发布以启动我们的流水线，并点击已创建发布的名称（这里叫做 Release-2）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.27_B16392.jpg
图 8.27 – 多阶段发布触发
-
发布流水线启动。DEV 和 QA 阶段已完成，而在 Production 阶段，出现 Pending approval 状态：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.28_B16392.jpg
图 8.28 – 待批准
-
发布流水线正在等待审批。你可以点击 Pending approval 图标，打开审批对话框。在这里，你可以插入评论，然后批准或拒绝发布：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.29_B16392.jpg
图 8.29 – 批准一个阶段
-
如果需要，你还可以将该阶段推迟到特定日期，或将批准任务重新分配给其他用户。
-
如果你点击批准，该阶段将被批准，发布管道完成：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.30_B16392.jpg
图 8.30 – 完成的多阶段管道
-
如果你现在点击由管道部署的 Azure 应用服务实例，你可以看到最终的代码（PartsUnlimited 网站）已部署到云端：
图 8.31 – 从发布管道部署的 Web 应用程序
使用网关检查条件
在之前讲解的场景中，我们了解了如何为发布管道配置手动批准过程。有时，你需要避免手动过程，而是设定一个策略，只有在某些检查成功执行后，管道才可以继续。这就是网关发挥作用的地方。
在 Azure Pipelines 中，网关允许你自动检查来自 Azure DevOps 或外部服务的特定条件，然后仅在满足这些条件时才启用发布过程。你可以使用网关来检查项目的工作项和问题状态，并仅在没有开放漏洞时启用发布。你还可以查询测试结果，检查在发布前是否执行了对构件的安全扫描，监控基础设施健康状况等。
作为示例，在这里我们希望为之前创建的发布管道配置一个网关，以便检查 Azure Boards 上的开放漏洞。我们将通过以下步骤来完成此操作：
重要提示
如果有开放漏洞，发布管道无法继续执行。
-
要检查我们项目中的开放漏洞，我们需要为工作项定义一个查询。从我们的 Azure DevOps 项目中，选择Boards，点击查询，然后选择新查询：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.32_B16392.jpg
图 8.32 – 为网关条件创建新查询
-
在这里，我定义了如下查询：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.33_B16392.jpg
图 8.33 – 查询定义
此查询检查我们项目中的活动漏洞。
-
通过为查询命名（例如，ActiveBugs）并指定一个文件夹（这里我选择了共享查询文件夹）来保存查询：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.34_B16392.jpg
图 8.34 – 保存查询定义
-
现在我们准备定义网关。从我们之前创建的多阶段发布管道中，选择生产阶段，点击螺栓图标，然后启用网关，如下截图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.35_B16392.jpg
图 8.35 – 启用网关
在这里，你还可以指定评估门控前的延迟（在添加的门控第一次被评估之前的时间。如果没有添加门控，则部署将在指定的持续时间后再继续），我们还可以指定部署门控（添加评估健康参数的门控）。这些门控会并行定期评估，如果门控成功，部署将继续；否则，部署将被拒绝。
-
要指定我们的门控，点击添加，然后选择查询工作项（这将执行一个工作项查询并检查结果）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_8.36_B16392.jpg
图 8.36 – 门控定义（查询工作项）
-
现在，选择
0（查询中匹配的工作项的最大数量），因为我们希望发布管道仅在没有活动错误时才完成：
图 8.37 – 指定门控条件
在这里，你还可以定义评估选项，如 0 表示当所有门控在同一评估周期内成功时，部署将继续；门控失败后的超时（门控的最大评估周期；如果门控在达到超时之前未成功，部署将被拒绝）。
我们的门控现在已经定义并启用了。你还可以定义其他类型的门控，甚至可以有调用 Azure Functions 来评估发布条件的门控（如果你想将发布检查与外部系统的特定条件集成，这会非常有用）。
使用部署组
部署组是一组每台机器上都安装了部署代理的机器。每个部署组代表一个物理环境，并定义了一个并行部署的目标机器逻辑组。
你可以在 Azure DevOps 中定义一个部署组，通过进入管道部分并选择部署组：
图 8.38 – 创建部署组
在这里，你可以添加已安装构建和发布代理的服务器。
每个创建的部署组都是部署池的一部分，并且此池也可以跨项目共享。部署组只能用于发布管道。
你可以通过进入发布管道编辑器，选择作业，并点击三点按钮来添加部署组作业。在这里，你可以看到添加部署组作业选项：
图 8.39 – 添加部署组作业
在写作时，YAML 管道尚不支持部署组作业。
YAML 发布管道与 Azure DevOps
Azure DevOps 最近新增的一个功能是通过使用 YAML 定义发布流水线的选项（之前这仅限于 CI 部分）。现在，通过使用多阶段流水线，你可以使用统一的 YAML 体验来配置 Azure DevOps 流水线，涵盖 CI、CD 和 CI/CD。
定义发布 YAML 流水线可以按照第四章中描述的方式进行，理解 Azure DevOps 流水线。然而，有一些概念需要理解，例如环境。
环境是流水线所针对的一组资源——例如，Azure Web Apps、虚拟机或 Kubernetes 集群。你可以使用环境来按范围对资源进行分组——例如，你可以创建一个名为development的环境，用于存放开发资源，创建一个名为production的环境，用于存放生产资源。可以通过进入Pipelines下的Environments部分来创建环境：
图 8.40 – 创建环境
以下是一个多阶段发布流水线的示例，用于将.NET Core 应用程序部署到 Azure Web Apps：
stages:
- stage: Build_Source_# Build Source Code for Dotnet Core Web App
jobs:
- job: Build
pool: 'Hosted VS2017'
variables:
buildConfiguration: 'Release'
continueOnError: false
steps:
- task: DotNetCoreCLI@2
inputs:
command: build
arguments: '--configuration $(buildConfiguration)'
- task: DotNetCoreCLI@2
inputs:
command: publish
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
modifyOutputPath: true
zipAfterPublish: true
- task: PublishBuildArtifacts@1
inputs:
path: $(Build.ArtifactStagingDirectory)
artifact: drop
- stage: Deploy_In_Dev # Deploy artifacts to the dev environment
jobs:
- deployment: azure_web_app_dev
pool: 'Hosted VS2017'
variables:
WebAppName: 'PartsUnlimited-dev'
environment: 'dev-environment'
strategy:
runOnce:
deploy:
steps:
- task: AzureRMWebAppDeployment@4
displayName: Azure App Service Deploy
inputs:
WebAppKind: webApp
ConnectedServiceName: 'pay-as-you-go'
WebAppName: $(WebAppName)
Package: $(System.WorkFolder)/**/*.zip
- stage: Deploy_In_QA # Deploy artifacts to the qa environment
jobs:
- deployment: azure_web_app_qa
pool: 'Hosted VS2017'
variables:
WebAppName: 'PartsUnlimited-qa'
environment: 'qa-environment'
strategy:
runOnce:
deploy:
steps:
- task: AzureRMWebAppDeployment@4
displayName: Azure App Service Deploy
inputs:
WebAppKind: webApp
ConnectedServiceName: 'pay-as-you-go'
WebAppName: $(WebAppName)
Package: $(System.WorkFolder)/**/*.zip
- stage: Deploy_In_Production # Deploy artifacts to the production environment
jobs:
- deployment: azure_web_app_prod
pool: 'Hosted VS2017'
variables:
WebAppName: 'PartsUnlimited'
environment: 'prod-environment'
strategy:
runOnce:
deploy:
steps:
- task: AzureRMWebAppDeployment@4
displayName: Azure App Service Deploy
inputs:
WebAppKind: webApp
ConnectedServiceName: 'pay-as-you-go'
WebAppName: $(WebAppName)
Package: $(System.WorkFolder)/**/*.zip
如前面的 YAML 文件所示，流水线定义了四个阶段：Build Source、Deploy in Dev、Deploy in QA和Deploy in Production。在每个阶段，应用程序都会在指定的环境中部署。
总结
在本章中，我们对如何在 Azure DevOps 中使用发布流水线进行了全面的概述。
我们为PartsUnlimited项目创建了一个基本的发布流水线，定义了工件，并通过添加持续部署条件创建了我们的第一个发布。
然后，我们通过使用多个阶段（DEV、QA和Production）来改进我们的流水线定义，在本章的最后，我们展示了如何定义审批和控制点，以更受控的方式管理代码的发布，并介绍了基于 YAML 的发布流水线的相关概念。
在下一章，我们将看到如何将 Azure DevOps 与 GitHub 集成。
第四部分：Azure DevOps 的高级功能
在本部分，我们将把 Azure DevOps 与 GitHub 集成，并涵盖一些实际的示例。
本节包含以下章节：
-
第九章，将 Azure DevOps 与 GitHub 集成
-
第十章，使用测试计划与 Azure DevOps
-
第十一章，Azure DevOps 的实际 CI/CD 场景
第九章：
第十章：将 Azure DevOps 与 GitHub 集成
GitHub 是全球最受欢迎的开发平台之一，被开源开发者和企业广泛使用来存储代码。在本章中，你将学习如何在继续使用 GitHub 作为软件开发中心的同时，利用 Azure DevOps 的能力。
我们将涵盖以下主题：
-
Azure DevOps 和 GitHub 集成概述
-
将 Azure Pipelines 与 GitHub 集成
-
将 Azure Boards 与 GitHub 集成
-
GitHub Actions 概述
技术要求
为了跟随本章内容，你需要拥有一个有效的 Azure DevOps 组织和一个 GitHub 账户。你可以在此注册 GitHub 账户：github.com/join。
让我们准备好本章的前提条件。本章要求你已经将Parts Unlimited GitHub 仓库克隆到你的 GitHub 账户中。你还需要一个 Azure DevOps 项目来跟随本章的示例。在继续到下一部分之前，请先完成以下步骤：
-
启动浏览器实例并访问
github.com/microsoft/PartsUnlimitedE2E。 -
点击 Fork，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.01_B16392.jpg
图 9.1 – GitHub 仓库：Parts Unlimited
-
如果你尚未登录，GitHub 会提示你登录到你的账户。选择你希望将仓库克隆到的账户。
-
完成此操作需要几分钟的时间。完成后，你应该能在你的账户中看到该仓库。
-
本章我们将使用这个仓库来测试 GitHub 集成。
-
现在，登录到 Azure DevOps (
dev.azure.com) 并创建一个新的空项目：
图 9.2 – 创建新项目
现在你已经准备好尝试本章中描述的示例。
Azure DevOps 和 GitHub 集成概述
GitHub 和 Azure DevOps 是互补的，它们为团队提供卓越的软件开发体验，使团队能够以更快的速度和更少的努力发布和交付软件。在许多场景中，GitHub 和 Azure DevOps 是竞争对手（例如，Azure Repos 与 GitHub 仓库），因此通常由你来选择适合自己需求的工具，并将它们集成在一起，构建一个完善的平台。
Azure DevOps 提供了多种 RBAC 级别、原生企业身份集成等功能，而 GitHub 则提供了跨身份的简单协作（在其企业版中包括 AD 集成）。
在持续集成/持续开发方面，Azure DevOps 相较于其竞争对手 GitHub Actions 处于领先地位，且已经成熟。因此，是否选择 Azure DevOps 和/或 GitHub 来处理你软件开发生命周期中的特定组件，取决于你的使用场景和需求。
GitHub 包含一个扩展市场，您可以在其中找到许多第三方应用程序，以将 GitHub 扩展到您使用的应用程序。Azure DevOps 集成可以通过 GitHub Marketplace 上的许多扩展来实现。让我们来看一些扩展。
GitHub 和 Azure DevOps 的集成通过 Azure Boards 和 Azure Pipelines 扩展来实现。让我们先看看在 GitHub Marketplace 中可以找到的 Azure DevOps 扩展：
-
启动浏览器并访问
github.com/marketplace。 -
在扩展市场中搜索
Azure。您将找到许多可以将 Azure 解决方案与您的 GitHub 仓库集成的扩展。 -
在这里，我们关心两个特定的扩展：Azure Boards 和 Azure Pipelines。稍后我们会详细讲解：
–Azure Boards：这个扩展允许您将 Azure Boards 工作项与 GitHub 对象（如提交、拉取请求和问题）关联：
图 9.3 – Azure Boards 扩展
–Azure Pipelines：这个扩展使您可以在 GitHub 仓库中存储和维护代码的同时，使用 Azure Pipelines 构建和发布软件：
图 9.4 – Azure Pipelines 扩展
您可以从 GitHub Marketplace 安装这些扩展，并从 GitHub 本身开始配置，但在本章中，我们将从 Azure DevOps 开始集成过程。GitHub 和 Azure DevOps 的集成也支持这两个产品的本地版本（GitHub 本地和 Azure DevOps Server）。
将 Azure Pipelines 与 GitHub 集成
将 Azure Pipelines 与 GitHub 集成使开发人员能够继续使用 GitHub 作为首选的源代码管理平台，同时利用 Azure Pipelines 的构建和发布功能。Azure Pipelines 为开源项目提供无限制的管道作业分钟数。
我们在本书前面详细介绍了 Azure Pipelines，所以在这一部分，我们将看看如何将 Azure Pipelines 配置和源代码存储在 GitHub 中，并利用 GitHub 和 Azure DevOps 构建 CI/CD 流程。
设置 Azure Pipelines 和 GitHub 集成
为了在 GitHub 上使用 Azure Pipelines，您必须授权 Azure Pipelines 访问您的 GitHub 仓库。让我们来看看如何进行授权：
-
登录您的 Azure DevOps 账户并选择我们在技术要求部分创建的项目。
-
点击Pipelines > 创建管道：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.05_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.05_B16392.jpg)
图 9.5 – 创建管道
-
选择GitHub作为您的代码源位置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.04_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.06_B16392.jpg)
图 9.6 – Azure Pipelines 的 GitHub 源
-
您需要从 Azure Pipelines 向您的 GitHub 账户授予权限：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.07_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.07_B16392.jpg)
图 9.7 – 授权 Azure Pipelines（OAuth）
-
成功完成后，你将在 Azure DevOps 中看到你的 GitHub 仓库列表。选择新创建的PartsUnlimitedE2E仓库：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.08_B16392.jpg
图 9.8 – Parts Unlimited 仓库
-
你现在会得到在 GitHub 帐户中安装 Azure Pipelines 应用程序的选项。你可以选择仅为特定仓库安装，或为所有仓库安装。做出选择后，点击批准并安装：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.09_B16392.jpg
图 9.9 – 安装 Azure Pipelines 扩展
-
由于Parts Unlimited是一个基于 ASP.NET 的应用程序，请选择ASP.NET作为你的管道配置模板：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.10_B16392.jpg
图 9.10 – Azure Pipelines 任务配置
-
Azure DevOps 将自动生成一个管道 YAML 文件。你可以根据需求查看并修改它。
vs2017-win2016继续：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.11_B16392.jpg图 9.11 – Azure Pipelines 任务 YAML
-
点击保存并运行以保存管道。
-
你需要向仓库提交一次更改，以存储管道 YAML 文件。你可以提交到主分支，或者创建一个新分支来进行此操作：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.12_B16392.jpg
图 9.12 – 运行 Azure 管道
-
点击保存并运行将创建管道并开始执行。构建任务完成可能需要几分钟：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.13_B16392.jpg
图 9.13 – 管道任务
-
在此过程中完成时，我们来看看你对 GitHub 仓库所做的更改。浏览到你的 GitHub 帐户并进入PartsUnlimitedE2E仓库。
-
你将看到一次提交以及一个新添加的
azure-pipelines.yml文件，它存储着管道的配置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.14_B16392.jpg图 9.14 – GitHub 中的管道 YAML
-
如果你点击前面截图中显示的小黄色圆点，你将看到 GitHub 仓库页面上 Azure 管道的状态。在管道任务成功完成后，你应该能看到它在 GitHub 帐户上的状态更新：
图 9.15 – GitHub 中的任务日志
这样，你就已经设置好了一个带有 GitHub 的 Azure 管道。
测试持续集成
在本节中，我们将尝试 GitHub 和 Azure Pipelines 的 CI 功能。我们将在 GitHub 中做出代码更改并提交拉取请求，这将自动触发 Azure Pipelines 任务。
让我们开始吧：
-
浏览到你的 GitHub 帐户并打开PartsUnlimited E2E仓库。
-
点击
Readme.MD并点击编辑：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.16_B16392.jpg图 9.16 – Readme.MD
-
更新文件，使其包含一些示例文本。选择创建新分支的选项并单击提出更改：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.17_B16392.jpg
图 9.17 – 提出更改
-
单击创建拉取请求，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.18_B16392.jpg
图 9.18 – 创建拉取请求
-
这将打开拉取请求页面。Azure Pipelines 作业将花费几分钟时间启动。一旦启动，您可以单击详细信息查看流水线作业的状态：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.19_B16392.jpg
图 9.19 – 拉取请求自动化检查
-
这就完成了对 GitHub 和 Azure Pipelines 持续集成功能的测试。正如我们所看到的，Azure Pipelines 与 GitHub 集成得非常好，并提供了全新的 DevOps 体验。您可以合并拉取请求来完成此过程。
添加构建状态徽章
Azure Pipelines 提供了可以在 GitHub 仓库文档中使用的标记文本，以提供项目流水线作业的状态。这可以帮助开发人员随时了解流水线的状态，无需访问 Azure DevOps。
让我们学习如何设置 Azure Pipelines 状态徽章：
-
登录 Azure DevOps 并浏览到您的项目 > 流水线 > PartsUnlimited E2E。
-
单击省略号（…），然后选择状态徽章：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.20_B16392.jpg
图 9.20 – 状态徽章
-
复制示例 markdown文本框的值。您还可以选择获取特定分支的 markdown。请将此 markdown 保存在临时位置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.21_B16392.jpg
图 9.21 – 状态徽章 URL
-
现在，在我们可以在 GitHub 中使用它之前，我们必须允许对项目徽章的匿名访问。
-
单击项目设置 > 流水线 > 设置。
-
关闭禁用匿名访问徽章设置。如果您发现该选项是灰色的，请首先在组织设置中关闭此选项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.22_B16392.jpg
图 9.22 – 状态徽章访问
-
现在，您可以在 GitHub 文档中使用此 markdown。建议您将其保留在您的仓库的 README 文件中，这样任何人都会首先看到它：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.23_B16392.jpg
图 9.23 – 状态徽章 markdown
-
提交更改后，您应该会看到 Azure Pipelines 徽章：
图 9.24 – 状态徽章展示
这样，您就完成了 Azure Pipelines 与 GitHub 的集成。在接下来的部分，我们将看看如何将 Azure Boards 与 GitHub 集成。
将 Azure Boards 与 GitHub 集成
Azure Boards 是规划和跟踪工作项的最佳平台。将 Azure Boards 与 GitHub 集成，您可以在继续使用 GitHub 作为源代码管理平台的同时，继续使用 Azure Boards 作为您的规划和管理平台。
通过将 Azure Boards 与 GitHub 集成，您可以将 Azure Boards 中的对象链接到 GitHub。以下是几个示例：
-
工作项和 Git 提交/问题/拉取请求链接意味着您可以将工作项链接到 GitHub 中相应的工作。
-
您可以直接在 GitHub 上更新工作项的状态。
-
总的来说，集成使我们可以轻松地跨两个平台跟踪和链接交付物。
现在，让我们设置 Azure Boards 集成。
设置 Azure Boards 和 GitHub 集成
Azure Boards 是 GitHub 市场中的另一个扩展。您可以从 Azure DevOps 和 GitHub 市场配置集成。
让我们通过以下步骤进行设置：
-
登录到 Azure DevOps，浏览到您的 Parts Unlimited 项目 > 项目设置 > Boards > GitHub 连接：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.25_B16392.jpg
图 9.25 – 将 GitHub 连接到 Boards
-
点击 连接您的 GitHub 帐户。您需要授权 Azure Boards 访问您的 GitHub 帐户。成功链接后，您需要选择要连接的 GitHub 组织。
-
Azure DevOps 会列出您的代码库。请为本项目选择PartsUnlimited E2E并点击保存：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.26_B16392.jpg
图 9.26 – 选择 GitHub 代码库
-
这将引导您回到 GitHub，安装 Azure Boards 应用程序。您可以选择为特定代码库或所有代码库安装该应用程序：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.27_B16392.jpg
图 9.27 – 批准 Azure Boards 扩展
-
安装 Azure Boards 后，您应该会看到 GitHub 连接列出，并带有绿色勾选标志，表示连接成功：
图 9.28 – GitHub 连接状态
完成后，您已经成功设置了 Azure Boards 和 GitHub 集成。
添加 Azure Boards 状态徽章
与 Azure Pipelines 状态徽章类似，Azure Boards 也提供状态徽章，显示 GitHub 仓库中工作项的统计信息。
在本节中，我们将通过以下步骤将 Azure Boards 的状态徽章添加到我们的 GitHub 仓库：
-
登录到 Azure DevOps，浏览到 Boards，并点击设置齿轮图标：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.29_B16392.jpg
图 9.29 – Azure Boards 工作项
-
在设置页面中，浏览到状态徽章并设置以下选项：
a) 勾选 允许匿名用户访问状态徽章 复选框。
b) 您可以选择只显示“进行中”列，或包含所有列。
您的屏幕应该如下所示：
图 9.30 – Azure Boards 状态访问
-
复制示例 markdown 字段并保存设置。您可以在 GitHub 文档中使用此 markdown。
-
一旦您将 markdown 添加到 GitHub README 文件中，它应该显示 工作项 状态，如下截图所示：
图 9.31 – Azure Boards 状态展示
接下来，我们将看看如何将 Azure Boards 对象链接到 GitHub 对象。
将 Azure Boards 工作项链接到 GitHub 对象
现在我们已经将 Azure Boards 与 GitHub 集成，让我们学习如何在这两个平台之间链接和跟踪项目。让我们开始吧：
-
在 Azure Boards 中，创建一个新的工作项。您可以使用我们之前完成的 Azure 看板状态徽章任务作为示例：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.32_B16392.jpg
图 9.32 – Azure Boards 工作项
-
您将看到，在 GitHub 中刷新后，您的状态徽章图标会立即更新，其中有一个项目处于 待办 状态。
-
由于此任务已完成，我们可以将其链接到相应的 GitHub 提交。打开新创建的任务并点击 添加链接：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.33_B16392.jpg
图 9.33 – 添加链接
-
点击 链接类型 下拉菜单，选择 GitHub 提交。提供您的 GitHub 提交 URL 并点击 确定。请注意，您还可以选择链接到 GitHub 问题或拉取请求：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.34_B16392.jpg
图 9.34 – 添加链接窗口
-
您现在会看到 GitHub 提交链接到工作项。将其 状态 更改为 已完成：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.35_B16392.jpg
图 9.35 – 已添加 GitHub 链接
-
通过这样做，您可以在 Azure Boards 中查看您的 GitHub 对象，并可以直接打开相应的提交链接到 GitHub：
图 9.36 – 已添加 GitHub 链接到 Azure Boards
接下来，我们将学习如何从 GitHub 更新工作项的状态。
从 GitHub 更新工作项
在本节中，我们将学习如何从 GitHub 本身更改 Azure Boards 中工作项的状态。这将帮助您将 GitHub 对象链接到 Azure Boards 的工作项，实现双向链接和跟踪系统。
让我们开始吧：
-
进入 Azure Boards > Boards > 新建项。创建一个您选择名称的测试工作项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.37_B16392.jpg
图 9.37 – 更新工作项
-
记下工作项的 ID（在此示例中为
347）。 -
现在，去您的 GitHub 仓库，对任何文件进行一些小的修改，并创建一个拉取请求。
-
在拉取请求信息框中，你可以通过使用
AB#347来引用 Azure Boards 任务，其中347是你的工作项 ID：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_9.38_B16392.jpg图 9.38 – 拉取请求信息框
-
一旦你完成拉取请求，你会看到提交信息现在已经超链接到 Azure Boards，并且该工作项在 Azure Boards 中的状态更新为
AB#<Work Item ID>。一旦你将工作项与 GitHub 链接，Azure Board 中的工作项也会更新，并附上指向相应 GitHub 对象的链接。 -
除了链接目标外，在本演示中，你还通过提交信息中的简单指令更新了工作项的状态。让我们来看一些你可以使用的示例消息：
图 9.40 – 示例消息
本节内容介绍了如何与 Azure Boards 和 GitHub 集成。在本节中，我们探讨了如何通过将 Azure Boards 和 GitHub 一起使用来更好地管理任务。在接下来的章节中，我们将介绍 GitHub Actions。
GitHub Actions 概述
GitHub Actions 是 GitHub 提供的 CI/CD 服务，用于构建和发布在 GitHub 仓库中开发的应用程序。本质上，GitHub Actions 类似于 Azure Pipelines，你可以设置构建和发布管道来自动化整个软件开发生命周期。
GitHub Actions 于 2019 年初推出，提供了一个内置于 GitHub 中的简单 DevOps 体验。GitHub Actions 包括企业级功能，如支持任何语言，并为各种操作系统和容器镜像提供内置的自托管代理。
它包含了社区构建的各种预构建工作流模板，可以帮助你更轻松地构建 DevOps 管道。
详细讨论 GitHub Actions 超出了本书的范围，但你可以参考 github.com/features/actions 上的 GitHub Actions 文档来入门。
总结
在本章中，我们探讨了如何将 GitHub 和 Azure DevOps 一起使用，为我们的软件团队构建一个集成的软件开发平台。为此，我们学习了如何从 GitHub 设置和管理 Azure DevOps 管道，以及构建和集成 CI/CD 解决方案。
我们还了解了在 GitHub 上进行软件开发时，如何更好地规划和跟踪我们的工作。在这一点上，你应该能够将 GitHub 和 Azure DevOps 一起使用，提升整体的生产力和 DevOps 体验。你还应该能够设置这两项服务之间的集成，并在日常 DevOps 工作中使用它。
在下一章中，我们将通过 Azure DevOps 的帮助，看看一些真实世界中的 CI/CD 示例。
第十章：
第十一章：使用 Azure DevOps 测试计划
在上一章中，我们讨论了如何将 Azure DevOps 与 GitHub 集成。
本章将介绍如何在 Azure DevOps 中使用测试计划。全面的测试应该应用于每个软件开发项目，因为它能够为应用程序提供质量保障和出色的用户体验。我们将首先简要介绍 Azure 测试计划。接着，我们将探讨如何在 Azure DevOps 中管理测试计划、套件和用例。然后，我们将运行并分析一个测试。之后，我们将讨论探索性测试，并安装 Test & Feedback 扩展。
本章将涵盖以下主题：
-
Azure 测试计划简介
-
探索性测试
-
安装和使用 Test & Feedback 扩展
-
计划性的手动测试
-
测试计划、测试套件和测试用例
-
管理测试计划、测试套件和测试用例
-
运行和分析手动测试计划
技术要求
要跟随本章的内容，你需要有一个活跃的 Azure DevOps 组织。本章中使用的组织是我们在第一章**，Azure DevOps 概览中创建的Parts Unlimited组织。你还需要安装 Visual Studio 2019，可以从visualstudio.microsoft.com/downloads/下载。
用于运行和分析手动测试计划的测试计划可以从github.com/PacktPublishing/Learning-Azure-DevOps---B16392/tree/master/Chapter%2010下载。
Azure 测试计划简介
手动测试和探索性测试可以是确保应用程序质量和用户体验的重要测试技术。在现代软件开发过程中，质量是所有团队成员的责任，包括开发人员、经理、业务分析师和产品负责人。
为了推动质量，Azure DevOps 测试计划提供了强大的工具，团队中的每个人都可以使用。通过将测试计划嵌入 Azure DevOps，测试可以贯穿整个开发生命周期。
Azure DevOps 测试计划支持计划性的手动测试、用户验收测试、探索性测试和利益相关者反馈。接下来的章节将更详细地介绍这些内容。
我们将在接下来的章节中详细介绍这些内容。在下一节中，我们将讨论探索性测试。
探索性测试
在探索性测试中，测试人员探索应用程序以识别和记录潜在的缺陷。它侧重于发现，并依赖于个别测试人员的指导，发现那些通过其他类型的测试难以发现的缺陷。这种测试通常被称为临时测试。
大多数质量测试技术采用结构化方法，通过事先创建测试用例（就像我们在之前的演示中所做的那样）。探索性测试正好与之相反，主要用于需要了解产品或应用程序的场景。测试人员可以从用户的角度审查产品的质量并快速提供反馈。这还确保您不会错过可能导致关键质量故障的情况。这些临时测试的结果随后也可以转化为测试计划。
微软发布了测试与反馈扩展，用于探索性测试。所有参与软件开发项目的相关人员，如开发人员、产品经理、经理、UX 或 UI 工程师、营销团队和早期采用者，都可以在浏览器中安装并使用该扩展。该扩展可用于提交缺陷或提供反馈，从而提升软件的质量。
在接下来的演示中，我们将演示如何安装测试与反馈扩展。
安装和使用测试与反馈扩展
测试与反馈扩展可以从 Visual Studio 市场安装，目前支持 Chrome 和 Firefox（版本 50.0 及更高版本）。Chrome 扩展也可以安装在 Microsoft Edge 浏览器中，该浏览器基于 Chromium。
重要说明
要查看详细的浏览器和功能支持情况，请参考以下文章：docs.microsoft.com/en-us/azure/devops/test/reference-qa?view=azure-devops#browser-support。
要安装测试与反馈扩展，请按照以下步骤操作：
-
访问 Visual Studio 市场：
marketplace.visualstudio.com/。 -
选择
测试与反馈。从列表中选择测试与反馈扩展：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.01_B16392.jpgFigure 10.1 – 选择测试与反馈扩展
-
这将打开扩展的详细页面，您可以在这里进行安装。点击屏幕顶部的安装按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.02_B16392.jpg
Figure 10.2 – 安装测试与反馈扩展
-
接下来，您将被重定向到支持安装此扩展的浏览器页面。点击您当前浏览器下方的安装按钮进行安装。您将被重定向到当前浏览器的扩展页面，在那里您可以进行安装。
-
安装扩展后，图标将添加到地址栏的右侧。点击连接按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.03_B16392.jpg
Figure 10.3 – 测试与反馈扩展配置
-
你需要在这里指定 Azure DevOps 服务器 URL，以连接到你的 Azure DevOps 实例。URL 以
https://dev.azure.com/开头，以项目名称结尾。提供 URL 后，点击下一步。连接到项目后，你可以选择团队。选择Parts.Unlimited Team：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.04_B16392.jpg图 10.4 – 连接到 Azure DevOps
-
点击保存。
现在扩展已经配置完成，我们可以开始使用它。你可以使用该扩展进行探索性测试或提供反馈：
-
我们将开始进行探索性测试会话。点击开始按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.05_B16392.jpg
图 10.5 – 开始探索性测试
-
这将激活菜单。一旦你打开了一个用于测试的 Web 应用，你可以找到存在 bug 的区域，截图、做笔记，或录制操作视频：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.06_B16392.jpg
图 10.6 – 扩展选项
-
一旦你完成了探索、收集并注册信息，你可以创建一个 bug、任务或测试用例。点击创建 bug：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.07_B16392.jpg
图 10.7 – 扩展选项
-
你可以提供一个标题，并将你发现的信息也包含其中：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.08_B16392.jpg
图 10.8 – 创建 bug
-
点击保存。
-
你还可以查看来自扩展的所有活动列表。在那里，你也能看到 bug ID，这样你就可以在 Azure DevOps 中追踪它：
图 10.9 – 操作概览
重要说明
若要了解如何在 Azure DevOps 中创建反馈项，请参考以下网站：docs.microsoft.com/en-us/azure/devops/test/request-stakeholder-feedback?view=azure-devops。若要使用Test & Feedback扩展响应这些反馈项，请访问 https://docs.microsoft.com/en-us/azure/devops/test/provide-stakeholder-feedback?view=azure-devops#provide。
在本次演示中，我们从 Visual Studio Marketplace 安装了Test & Feedback扩展，它可以用于探索性测试。
在下一部分，我们将探讨计划的手动测试。
计划的手动测试
多年来，手动测试与软件开发过程一同演变，变得更加敏捷。通过 Azure DevOps，手动测试被集成到支持的不同敏捷过程中，并且可以在 Azure DevOps 中进行配置。
重要说明
在第二章中，更详细地介绍了在 Azure DevOps 中支持并集成的不同敏捷过程，标题为使用 Azure DevOps Boards 管理项目。
软件开发团队可以直接从 Azure Boards 的看板开始手动测试。从看板上，你可以直接从卡片中监控测试的状态。这样，所有团队成员可以概览与工作项和故事相关的测试。团队还可以看到不同测试的状态。
在下图中，你可以看到在看板上显示的测试及其状态：
图 10.10 – 在工作中心显示的测试
如果需要更先进的测试功能，Azure 测试计划也可以满足所有测试管理需求。测试中心可以通过左侧菜单中的测试计划访问，其中提供了完整测试生命周期所需的所有功能。
在下图中，你可以看到如何通过左侧菜单访问测试中心，以及不同的菜单选项：
图 10.11 – Azure DevOps 中的测试中心
这些功能包括测试计划、测试套件、测试用例、测试编写、测试应用和测试跟踪。测试计划、测试套件和测试用例将在下一节中详细讲解。
测试计划、测试套件和测试用例
在 Azure DevOps 测试计划中，你可以为软件开发项目中定义的冲刺或里程碑创建和管理测试计划和测试套件。测试计划提供了三种主要的测试管理构件：测试计划、测试套件和测试用例。这些构件作为特殊类型的工作项存储在工作仓库中，并可以导出并与不同的团队成员或跨团队共享。这也支持测试构件与项目中定义的所有 DevOps 任务的集成。
这三种构件具备以下功能：
-
测试计划：测试计划将不同的测试套件、配置和单独的测试用例汇集在一起。通常，项目中的每个主要里程碑都应该有自己的测试计划。
-
测试套件：测试套件可以将不同的测试用例组织成单独的测试场景，归入单个测试计划中。这样可以更容易地查看哪些场景已完成。
-
测试用例：通过测试用例，你可以验证代码或应用部署的各个部分。它们可以被添加到测试计划和测试套件中。如果需要，它们也可以被添加到多个测试计划和套件中。这样，它们可以有效地重复使用，无需复制。测试用例旨在验证 Azure DevOps 中的工作项，如功能实现或错误修复。
在接下来的部分，我们将把这些理论付诸实践，看看如何在 Azure DevOps 中创建和管理测试计划。
管理测试计划、测试套件和测试用例
在本次演示中，我们将再次使用Parts Unlimited项目。该项目在 Azure DevOps 中也有一个测试计划，因此我们将首先查看它。接下来，我们需要遵循以下步骤：
-
打开一个网页浏览器并导航到
dev.azure.com/。 -
使用你的 Microsoft 账户登录，并选择Parts.Unlimited项目。然后，在左侧菜单中选择测试计划。这将让你导航到已经添加到项目中的测试计划。
-
从列表中选择Parts.Unlimited_TestPlan1以打开它。测试套件已被添加到该计划中。选择作为客户，我希望将我的信用卡信息安全地存储。这将打开已添加到该套件中的单个测试用例列表：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.12_B16392.jpg
图 10.12 – 打开测试套件项
-
然后，右键点击列表中的第一个项：验证用户是否被允许保存其信用卡信息。在菜单中选择编辑测试用例：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.13_B16392.jpg
图 10.13 – 编辑测试用例
-
在该测试用例的编辑界面上，有四个步骤。你还可以从这里将测试用例链接到提交、拉取请求、分支或工作项。我们将把这个测试用例添加到现有的工作项中。在相关工作下，选择**+ 添加链接**，然后点击现有项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.14_B16392.jpg
图 10.14 – 将工作项添加到测试用例
-
在
credit card中。选择信用卡购买功能以将测试用例链接到：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.15_B16392.jpg图 10.15 – 选择工作项
-
点击确定以链接工作项。现在，父特性已与测试用例和测试套件关联。任何人都可以在它们之间导航并查看其关系。
-
在测试用例窗口中，点击保存并关闭。
在某些情况下，测试用例应按特定顺序运行。为此，请点击顶部菜单中的定义，然后选择验证用户是否不允许保存无效的信用卡信息测试用例。接着将该测试用例拖动到列表中第一个测试用例的上方：
图 10.16 – 重新排序测试用例
现在你将看到测试用例的顺序已发生变化。
你还可以为每个测试用例分配不同的配置。例如，你可以为不同的环境分配配置，如不同版本的 Windows 或浏览器、移动设备等：
-
要分配配置，请右键点击测试用例并选择分配配置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.17_B16392.jpg
图 10.17 – 分配配置
-
在配置概览列表中，你会看到这个测试用例已经选择了一个配置，即 Windows 10。如果没有，选择它并点击保存。然后关闭列表：
图 10.18 – 可用和已选择的配置
重要提示
添加和管理测试计划配置超出了本书的范围。不过，如果你想了解更多信息，可以参考以下文章：docs.microsoft.com/en-us/azure/devops/test/test-different-configurations?view=azure-devops。
接下来，我们将创建一个新的测试套件。你可以创建三种不同类型的测试套件：静态，手动分配测试用例；基于需求，根据共同需求创建套件；以及基于查询，根据查询结果自动添加测试用例：
-
让我们添加一个新的基于需求的测试套件。为此，选择Parts.Unlimited_TestPlan1旁边的三个点 > 新建套件 > 基于需求的套件：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.19_B16392.jpg
图 10.19 – 创建基于需求的测试套件
-
在这里，你可以根据需求创建自己的查询来检索工作项。在这个演示中，我们将使用默认设置。点击运行查询，然后选择与运输相关的三个项目：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.20_B16392.jpg
图 10.20 – 选择与运输相关的工作项
-
点击创建套件为每个项目创建一个测试套件。
-
我们将向这个测试套件添加一些测试用例。你可以一次添加一个，也可以使用网格布局快速添加多个测试用例。我们将在这里使用网格布局。选择一个已添加的测试套件，点击新建测试用例按钮旁边的箭头，然后点击使用网格添加测试用例：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.21_B16392.jpg
图 10.21 – 使用网格添加测试用例
-
将以下测试用例添加到网格：
a) 第一个测试用例：
i) 标题：订单摘要显示预期交货日期
ii) 步骤操作：访问“我的订单”
iii) 步骤预期结果：显示预期交货日期
b) 第二个测试用例：
i) 标题：延迟订单被突出显示
ii) 步骤操作：访问延迟包裹的订单页面
iii) 步骤预期结果：延迟状态被突出显示
c) 第三个测试用例：
i) 标题：包裹交付步骤
ii) 步骤操作：访问进行中的包裹订单页面
iii) 步骤预期结果：显示交付步骤和状态
这将显示如下截图：
图 10.22 – 定义测试用例
-
点击左侧的 保存测试用例 按钮，然后点击屏幕右侧的 关闭网格 按钮。
在本演示中，我们已经管理了一些测试用例并创建了一个新的基于需求的测试套件。在接下来的部分，我们将运行并分析一个手动测试计划。
运行和分析手动测试计划
在本演示中，我们将运行并分析一个手动测试计划。为此，我们将再次使用已经添加到 Azure DevOps 中的 Parts.Unlimited 项目的测试计划并导入一个测试套件。该测试套件可以从属于本章的 GitHub 仓库中下载。你可以在章节开头的 技术要求 部分获取 GitHub URL：
-
再次在 Azure DevOps 中打开 Parts.Unlimited 项目的测试计划。
-
首先，我们需要添加一个新的静态测试套件。为此，选择
端到端测试旁边的三个点。 -
选择新创建的套件，并在顶部菜单中选择导入按钮以导入测试用例：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.23_B16392.jpg
图 10.23 – 导入测试用例
-
导入 GitHub 源代码中 第十章 文件夹中的测试计划。选择 CSV 文件并点击 导入 按钮：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.24_B16392.jpg
图 10.24 – 导入 CSV 文件
-
导入文件后，双击测试用例并导航到参数部分。然后添加一些可以用于测试的参数，类似于以下截图：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.25_B16392.jpg
图 10.25 – 参数值
-
点击顶部菜单中的 保存并关闭。现在我们已经准备好测试套件，可以开始测试了。点击顶部菜单中的 执行 选项卡，然后点击 测试用例，接着点击 运行，然后点击 使用选项运行：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.26_B16392.jpg
图 10.26 – 运行测试
-
保持 使用选项运行 窗口中的默认设置，然后点击 运行：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.27_B16392.jpg
图 10.27 – 使用选项运行
-
测试运行器现在会显示所有步骤：
图 10.28 – 测试运行器窗口
现在我们可以开始实际的测试：
-
在 Visual Studio 中打开 Parts.Unlimited 项目。我们之前已经克隆了仓库。如果需要再次克隆项目，请参考 第五章*，在构建管道中运行质量测试*。
-
通过按 F5 键运行应用程序，并等待直到 Parts Unlimited 网站启动。现在将浏览器窗口放到测试运行器窗口旁边，并开始测试：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.29_B16392.jpg
图 10.29 – 开始测试 Web 应用程序
-
根据测试运行器的说明操作。每完成一个步骤，点击每个步骤右侧的通过测试图标。
-
如果你发现 Bug 或问题，可以直接在步骤上添加评论，或者在顶部创建一个单独的 Bug：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.30_B16392.jpg
图 10.30 – 添加评论或 Bug
-
要完成测试，请点击测试运行器顶部菜单中的保存并关闭。
-
现在返回到 Azure DevOps。在左侧菜单中，点击测试计划 > 运行。
-
在最近的运行列表中，选择我们刚刚执行的运行：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_10.31_B16392.jpg
图 10.31 – 最近的测试运行
-
在这里，你可以查看测试的所有细节和结果：
图 10.32 – 测试结果
在本次演示中，我们创建了一个测试套件并导入了一个测试用例。然后我们运行了测试并测试了 Parts Unlimited 应用程序，并查看了 Azure DevOps 中的结果。
本章到此结束。
总结
在本章中，我们介绍了 Azure DevOps 测试计划。我们查看了不同的功能和能力，并管理了测试计划、测试套件和测试用例。然后，我们从 CSV 文件导入了一个测试用例，并测试了Parts Unlimited应用程序。接着，我们详细讲解了探索性测试，并使用 Test & Feedback 扩展来报告一个 Bug。
在下一章中，我们将重点介绍使用 Azure DevOps 的实际 CI/CD 场景。
进一步阅读
查看以下链接，获取更多有关本章内容的信息：
-
探索性和手动测试场景及能力：
docs.microsoft.com/en-us/azure/devops/test/overview?view=azure-devops -
创建手动测试用例：
docs.microsoft.com/en-us/azure/devops/test/create-test-cases?view=azure-devops -
使用 Test & Feedback 扩展提供反馈：
docs.microsoft.com/en-us/azure/devops/test/provide-stakeholder-feedback?view=azure-devops -
使用 Test & Feedback 扩展在连接模式下进行探索性测试：
docs.microsoft.com/en-us/azure/devops/test/connected-mode-exploratory-testing?view=azure-devops
第十一章：
第十二章：使用 Azure DevOps 进行实际的 CI/CD 场景
在本章中，我们将展示一些示例项目，其中持续集成和持续交付（CI/CD）过程通过使用 Azure DevOps 来处理。我们将以示例应用程序为基础，使用 Azure DevOps 设置 CI/CD 管道，以便管理软件开发、部署和升级生命周期。
本章将涵盖以下主题：
-
为基于.NET 的应用程序设置 CI/CD 管道
-
为基于容器的基础设施设置 CI/CD 管道
-
Azure 架构中心为 DevOps 提供支持
技术要求
要跟随本章学习，您需要有一个有效的 Azure DevOps 组织和一个 Azure 订阅。
您可以在dev.azure.com注册一个测试版 Azure DevOps 组织。如果您还没有 Azure 订阅，可以在azure.microsoft.com/en-in/free/获得一个试用版。
本章的代码可以在github.com/PacktPublishing/Learning-Azure-DevOps---B16392/tree/master/Chapter11找到。
为基于.NET 的应用程序设置 CI/CD 管道
典型的基于.NET 的应用程序包括使用 Microsoft 的.NET Framework 开发的应用程序，并在后端使用 SQL 数据库。应用程序可能有多个层次，例如前端、后端（也称为中间层或 API 层）和数据层（SQL Server）。
Azure Pipelines，作为 Azure DevOps 的一部分，提供了一个全面的解决方案来构建、部署和管理基于.NET 的基础设施部署。在本节中，我们将查看为示例基于.NET 的应用程序配置 CI/CD 的步骤。
我们将为应用程序创建两个环境，分别命名为暂存和生产，并设置 CI/CD 管道。
示例应用程序简介
我们将使用一个简单的ToDo应用程序来进行这次演示。它是一个基于 Web 的应用程序，后端使用 SQL 数据库。
它是使用 Microsoft ASP.NET 构建的，针对的是.NET Framework 版本 4.62。您可以在这里访问源代码：github.com/Azure-Samples/dotnet-sqldb-tutorial/tree/master/DotNetAppSqlDb。
建议您在开始构建 CI/CD 管道之前，快速浏览一下应用程序代码，以便熟悉它。
准备所需的 Azure 基础设施
在本节中，我们将创建所需的 Azure 基础设施来托管应用程序。我们将创建以下资源：
-
Contoso-ToDo-Stagingb)
Contoso-ToDo-Production -
应用程序组件：我们将为暂存环境和生产环境创建以下资源：
a) 使用 Azure App Service 来托管 Web 应用程序
b) 使用 Azure SQL 数据库来托管 SQL 数据库
在 Azure 中创建资源组
资源组是一个容器，用于在 Azure 云中存储资源。通常，资源组包括您希望作为一组管理的资源，或者生命周期相似的资源。我们将创建两个资源组：一个用于生产，另一个用于预发布。让我们在 Azure 中创建这些资源组：
-
使用您的 Azure 凭证登录到 Azure 门户，
portal.azure.com。 -
图 11.1 – Azure 门户中的资源组
-
在资源组页面上点击 创建。
-
选择您的订阅，并输入资源组名称为
Contoso-ToDo-Staging。 -
选择一个离您位置较近的区域：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.02_B16392.jpg
图 11.2 – 资源组创建
-
点击 查看 + 创建，然后点击 创建 以开始部署。
-
重复步骤，为生产环境创建另一个资源组，命名为
Contoso-ToDo-Prod。
您现在已经创建了资源组来托管 Azure 资源。
创建 Azure 应用服务
Azure 应用服务是 Microsoft Azure 提供的 平台即服务（PaaS）Web 托管服务。您可以使用应用服务托管几乎任何语言构建的基于 Web 的应用程序。作为 PaaS 服务，应用服务允许您只需推送代码即可使应用程序上线，而无需担心底层的硬件、操作系统和平台组件。
在本示例中，我们将使用 Azure 应用服务来托管 ToDo 应用：
-
在 Azure 门户中，点击 + 创建资源，然后点击 Web 应用：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.03_B16392.jpg
图 11.3 – 门户中的 Azure Web 应用
-
在
contosotodostagingXX上，其中XX是您的首字母。d) 发布：选择代码。
e) 运行时堆栈：选择 ASP.NET V4.7。
f) 操作系统：选择 Windows。
g) 区域：选择一个离您位置较近的区域：
图 11.4 – 创建 Azure 应用服务
-
在 应用服务计划 下，选择以下选项：
a) Windows 计划：输入一个新的应用服务计划名称
b) SKU 和大小：您可以选择任何 SKU；建议使用 S0 或 Basic，以避免由于测试目的而产生过高的 Azure 成本。在生产环境中，您应根据应用程序的资源需求选择适合的大小：
图 11.5 – 应用服务 SKU
-
点击 查看 + 创建，然后点击 创建 以开始部署。
完成后，您将收到一个通知，显示状态为完成。
-
重复此任务中的步骤，为生产环境创建另一个 Azure 应用服务。
在此任务中，我们为托管 ToDo Web 应用程序创建了一个 Azure 应用服务。
创建 Azure SQL 数据库
我们的示例 ToDo 应用使用 Microsoft SQL Server 存储所有的应用数据。在此任务中，我们将创建一个新的 Azure SQL 数据库，供 ToDo 应用存储所有持久化数据：
-
在 Azure 门户中，点击 + 创建资源，然后选择 SQL 数据库：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.06_B16392.jpg
图 11.6 – Azure 中的 SQL 数据库
-
在 SQL 服务器
contosotodo-staging-db上。d)
contosotodo-staging-dbserver。ii) 提供你选择的用户名和密码。
iii) 位置：用于部署 Web 应用的 Azure 区域。
e) 想使用 SQL 弹性池吗？：否。
f) 计算 + 存储：将 SKU 更改为 S0 或 基础 以保持 Azure 成本在本测试项目期间较低。实际上，你需要根据应用需求选择合适的计算和存储组合：
图 11.7 – 在 Azure 中创建 SQL 数据库
-
点击 下一步：网络 >。
-
对于 网络 配置，选择 公共端点 作为 连接方式，并选择 是 以允许 Azure 服务和资源访问此服务器。请注意，这仅用于本测试项目的部署；在生产环境中，建议仅允许来自特定应用服务器的访问。一旦选择，点击 查看 + 创建：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.08_B16392.jpg
图 11.8 – 在 Azure 中审核 SQL 数据库创建
-
点击 创建 以开始部署。完成后，你将在通知菜单中收到通知。
-
导航到新创建的 Azure SQL 数据库并复制连接字符串。这将在接下来的部分中使用。
-
重复这些步骤为生产环境创建另一个 Azure SQL 数据库。
在这个任务中，我们已经为我们的应用创建了 Azure SQL 数据库。
设置 Azure DevOps 项目
现在我们的 Azure 基础设施已准备好，接下来我们将设置一个 Azure DevOps 组织来构建 CI/CD 流水线。我们将使用 Azure Repos 作为我们的源代码管理系统：
-
使用你的 Azure DevOps 账号登录
dev.azure.com。 -
在你的 DevOps 租户中创建一个名为
Contoso ToDo的新项目：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.09_B16392.jpg图 11.9 – 创建 DevOps 项目
-
我们将从导入 Azure Repos 中的应用代码开始。点击 Repos。
-
在 导入仓库 下点击 导入：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.10_B16392.jpg
图 11.10 – 导入一个仓库
-
对于仓库 URL，输入
github.com/Azure-Samples/dotnet-sqldb-tutorial/，然后点击 导入：
图 11.11 – 从 GitHub 导入仓库
导入成功后，我们将看到项目文件现已在 Azure Repos 中可用。您可以浏览代码文件，查看 DotNetAppSQLDb 中包含的应用程序源文件：
图 11.12 – Azure 仓库中的文件
我们现在将为应用程序设置构建管道。
为应用程序设置 CI
现在我们的应用程序代码已上传至 Azure Repos，接下来我们将创建一个构建管道，该管道将构建应用程序包，以便部署到 Azure 应用服务：
-
在 Azure DevOps 中，浏览到管道并点击创建管道：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.13_B16392.jpg
图 11.13 – 创建管道
-
点击使用经典编辑器，通过 GUI 创建管道（这一步是可选的；如前面章节所述，您可以选择使用 YAML 文件配置管道）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.14_B16392.jpg
图 11.14 – 选择经典编辑器
-
选择您的 Azure 仓库和主分支，然后点击继续进入下一步：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.15_B16392.jpg
图 11.15 – 选择仓库
-
选择ASP.NET作为管道模板：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.16_B16392.jpg
图 11.16 – 选择管道模板
-
查看管道配置。对于这个项目，默认配置已经能够完成工作。检查无误后，点击保存并排队：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.17_B16392.jpg
图 11.17 – 管道构建任务
-
在运行管道向导中，您可以添加评论并点击保存并运行以开始执行。
-
一旦作业开始执行，您可以通过点击作业名称来查看状态：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.18_B16392.jpg
图 11.18 – 管道构建状态
-
现在，让我们在管道上启用 CI，以便在提交到主分支时自动启动构建。编辑管道并浏览到触发器，启用 CI。如果您不是使用主分支作为主要分支，您可以选择按分支进行过滤或切换到其他分支：
图 11.19 – 启用持续集成
在这项任务中，我们创建了一个构建管道，并成功构建了我们的示例待办事项应用程序。在接下来的任务中，我们将执行部署。
为应用程序设置持续交付
现在我们的应用程序已准备好进行部署，我们将创建一个发布管道，将应用程序部署到 Azure。在这个管道中，我们将定义要将应用程序部署到哪些 Azure 资源，并添加额外的部署控制。
设置服务连接
Azure DevOps 需要访问 Azure 订阅，以便能够部署和更新 Azure 资源。Azure DevOps 中的服务连接允许你将 Azure DevOps 项目连接到外部服务。让我们为 Azure Pipelines 创建一个服务连接：
-
登录到 Azure DevOps 并浏览至 项目设置 | 服务连接。
-
点击 创建服务连接。
-
在连接列表中，选择 Azure 资源管理器：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.20_B16392.jpg
Figure 11.20 – ARM 服务连接
-
对于服务连接身份验证方法，选择 服务主体（自动）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.21_B16392.jpg
Figure 11.21 – ARM 服务连接服务主体
-
Azure DevOps 现在将要求你进行 Azure 身份验证。请使用至少拥有订阅所有者权限和全局管理员权限的帐户登录到 Azure Active Directory (AD) 租户。你可以选择将服务连接的作用域限制为某个资源组，或者允许整个订阅。选择你的 Azure 订阅并为其命名：
Figure 11.22 – 创建服务连接服务主体
该服务连接现在可以在 Azure Pipelines 中使用。
创建发布流水线
发布流水线包括所有步骤和工作流，用于将应用程序部署到不同的环境中，例如开发、暂存、质量保证和生产。我们从为 ToDo 应用创建一个发布流水线开始：
-
登录到 Azure DevOps 并启动你的
Contoso ToDo项目。 -
浏览至 Pipeline | Releases。
-
Figure 11.23 – 新发布流水线
-
这将打开一个页面以选择模板。由于我们计划将 ToDo 应用部署到 App Service，请选择 Azure App Service 部署：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.24_B16392.jpg
Figure 11.24 – Azure App Service 部署任务
-
在 阶段名称 输入
Staging Environment。你可以选择给出任何其他有意义的名称，最好能描述你环境中的场景：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.25_B16392.jpgFigure 11.25 – Staging 阶段
-
现在你可以关闭 阶段 窗格。你的流水线应该如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.26_B16392.jpg
Figure 11.26 – 流水线快照
-
为了部署应用程序，首先我们需要从构建流水线的输出中获取应用程序包。在 Artifacts 下，点击 + 添加：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.27_B16392.jpg
Figure 11.27 – 发布流水线中的工件
-
选择构建作为源类型，并选择在上一任务中创建的构建管道。你可以选择配置默认要部署的版本：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.28_B16392.jpg
图 11.28 – 发布管道中的工件源
-
点击持续部署触发器按钮并启用持续部署。启用持续部署后，每当有新的构建版本可用时，都会触发发布（通常是在运行包含 CI 的构建管道之后）。如果启用拉取请求触发器，每次有新的构建版本时，都会创建一个发布，即使是有拉取请求的情况下。这对于纯开发管道可能是一个有用的场景：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.29_B16392.jpg
图 11.29 – 启用持续部署
-
在阶段中，点击开发环境中的1 个任务，1 个工作：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.30_B16392.jpg
图 11.30 – 管道阶段
-
在任务视图中，选择你之前部署的 Azure 订阅服务连接和应用服务：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.31_B16392.jpg
图 11.31 – 应用服务部署任务
-
点击部署 Azure 应用服务并检查应用服务的部署信息。
-
点击**+添加另一个任务来应用SQL 迁移脚本以使数据库准备就绪。搜索 SQL 并选择Azure SQL 数据库部署**。
-
在Azure SQL 任务中，修改以下设置：
a) 显示名称：应用数据库迁移脚本。
b) 选择你的 Azure 订阅并提供在创建 Azure SQL 数据库时捕获的数据库连接详情。
c) 部署类型：内联 SQL 脚本
d) 内联 SQL 脚本：提供以下脚本代码。这将会在 SQL 数据库中创建所需的表。请注意，这是一个用于创建所需架构的示例 SQL 脚本（也可以在
github.com/PacktPublishing/Learning-Azure-DevOps---B16392/tree/master/Chapter11中找到）；在生产环境中，您可以选择使用 Azure Pipelines 中的 SQL Server 数据工具项目来完成此操作。请参阅此文档了解更多关于 SQL 的 Azure DevOps 的内容：devblogs.microsoft.com/azure-sql/devops-for-azure-sql/：/****** Object: Table [dbo].[__MigrationHistory] Script Date: 8/24/2020 12:35:05 PM ******/ SET ANSI_NULLS ON SET QUOTED_IDENTIFIER ON IF NOT EXISTS ( SELECT [name] FROM sys.tables WHERE [name] = '__MigrationHistory' ) BEGIN CREATE TABLE [dbo].__MigrationHistory NOT NULL, [ContextKey] nvarchar NOT NULL, [Model] varbinary NOT NULL, [ProductVersion] nvarchar NOT NULL, CONSTRAINT [PK_dbo.__MigrationHistory] PRIMARY KEY CLUSTERED ( [MigrationId] ASC, [ContextKey] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] END /****** Object: Table [dbo].[Todoes] Script Date: 8/24/2020 12:35:05 PM ******/ SET ANSI_NULLS ON SET QUOTED_IDENTIFIER ON IF NOT EXISTS ( SELECT [name] FROM sys.tables WHERE [name] = 'Todoes' ) BEGIN CREATE TABLE [dbo].Todoes NOT NULL, [Description] nvarchar NULL, [CreatedDate] [datetime] NOT NULL, CONSTRAINT [PK_dbo.Todoes] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] END -
点击保存并点击**+**添加另一个任务。现在我们需要添加另一个任务，更新 Azure 应用服务连接设置中的数据库连接字符串。
-
在任务菜单中搜索Azure 应用服务设置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.32_B16392.jpg
图 11.32 – Azure 应用服务设置任务
-
在Azure App Service 设置任务中，选择 Azure 订阅和用于暂存环境的应用服务连接详情。
-
在连接设置中，提供以下格式的数据库连接字符串。在保存之前，请更新您的数据库连接详情。由于这是一个测试实验室，我们直接在管道任务中存储了安全信息。然而，在生产环境中，请使用变量和参数来存储任何连接字符串或其他信息。请参考此文档了解如何在 Azure 管道中安全地使用变量和参数：
docs.microsoft.com/bs-cyrl-ba/azure/devops/pipelines/security/inputs?view=azure-devops：[ { 'name': 'MyDbConnection', 'value': 'Server=tcp:contosotodostagingdb.database.windows.NET,1433;Initial Catalog=ContoSoToDoStageDB;Persist Security Info=False;User ID=azadmin;Password=<YourPassword>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;', 'type': 'SQLAzure', 'slotSetting': false } ] -
一旦所有任务更新完成，点击保存。在提示时，可以将管道保存在根文件夹中。任务的顺序应如下：
a) 应用数据库迁移脚本
b) 应用 Azure App Service 设置
c) 部署 Azure App Service：
图 11.33 – 保存发布管道
-
在管道中，点击**+ 添加**以添加另一个用于生产的阶段。您可以选择相同的 Azure App Service 部署，也可以克隆开发环境阶段。您可以在定位生产应用服务和 SQL 数据库实例时配置生产阶段。您的管道现在应如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.34_B16392.jpg
图 11.34 – 发布管道
-
通常，您不希望自动部署到生产环境。让我们修改流程，以便在生产部署之前进行手动审批。点击预部署条件：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.35_B16392.jpg
图 11.35 – 发布管道触发控制
-
启用预部署审批，并选择至少一个用户进行审批，才能在部署到生产环境之前进行批准。
-
您可以添加一个额外的阶段，如测试用例、性能基准等，并准备好整体流程。完成检查管道后，点击保存。
现在，部署应用程序的 Azure 发布管道已准备就绪。让我们创建一个发布，并查看我们是否能够通过 CI/CD 管道将应用程序启动并运行。
创建发布
让我们通过手动创建一个发布来测试发布管道：
-
在 Azure DevOps 中，浏览到发布并点击创建发布：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.36_B16392.jpg
图 11.36 – 创建发布
-
审核发布详情并点击创建：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.37_B16392.jpg
图 11.37 – 审核发布创建
-
点击创建将开始执行发布；您可以通过点击阶段上的日志来查看进度：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.38_B16392.jpg
Figure 11.38 – 发布状态
一旦开发环境部署完成，你应该尝试启动应用服务，并查看ToDo应用程序是否正常工作：
Figure 11.39 – ToDo 应用
-
你可以尝试添加待办事项并测试应用程序。一旦你准备好批准生产部署，点击批准开始生产部署：
Figure 11.40 – 批准生产部署
你现在已经完成了发布，应用程序已经准备好使用。
尝试端到端 CI/CD 流程
现在你已经完成了端到端 CI/CD 流水线的设置，继续尝试以下操作，体验整个流程：
-
在 Azure Repos 中，修改主页的视图。前往 Repos | DotNetAppSQLDB | Views | Todos | index.cshtml，并将标签从Create new修改为Create New ToDo Item：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.41_B16392.jpg
Figure 11.41 – 修改应用程序代码
-
在新分支中提交更改，并完成拉取请求。你应该批准并完成拉取请求。
这应该会启动自动构建流水线执行，并通过自动发布执行进行后续操作。
最终，你应该在不需要任何手动步骤的情况下更新你的应用程序，唯一需要执行的任务是配置好的生产审批任务。
恭喜，你现在已经完成了端到端 CI/CD 流水线的设置和测试！在下一节中，我们将为 Kubernetes 基础的应用程序设置类似的流水线。
为基于容器的应用程序设置 CI/CD 流水线
在本例中，我们将采用一个基于容器的应用程序，并构建一个端到端的 CI/CD 流水线。为了演示，我们将使用一个基于 Python 和 Redis 的示例应用程序。
在本例中，我们将在整个解决方案架构中使用各种 Azure 资源。包括以下内容：
-
Azure DevOps：CI/CD 流水线
-
Azure Kubernetes 服务（AKS）：用于托管容器
-
Azure 容器注册表（ACR）：容器镜像存储和管理
示例应用介绍
在本节中，我们将使用一个名为Azure 投票应用的示例应用。它是一个标准的基于多容器的应用，使用以下组件：
-
Azure 投票应用后端：将在 Redis 上运行。
-
Azure 投票应用前端：使用 Python 构建的 Web 应用程序。
你可以在这里查看应用程序代码：github.com/Azure-Samples/azure-voting-app-redis。
设置所需的基础设施
为了能够构建管道，首先需要设置所需的基础设施，包括 AKS 集群和 Azure 容器注册表。我们将为预发布和生产环境创建独立的资源作为标准最佳实践；然而，通过使用标签和 Kubernetes 命名空间的组合，也可以使用单一环境来同时处理生产和开发环境。
在本节中，我们将使用 Azure 命令行界面（CLI）来执行所有基础设施部署任务。
创建 Azure 资源组
我们从创建一个 Azure 资源组开始，用于组织开发和生产环境的所有资源：
-
使用你的 Azure 凭据登录 Azure Cloud Shell（
shell.azure.com）。 -
如果这是你第一次登录 Azure Cloud Shell，它会提示你创建一个 Azure 存储账户。选择你的订阅并点击创建存储。
-
在 shell 类型选择中选择Bash。
-
运行以下命令以列出所有订阅：
az account list -
如果需要为资源提供指定订阅，请运行以下命令：
az account set --subscription 'Your Subscription Name' -
运行以下命令创建名为
Contoso-Voting-Stage的资源。你可以选择上传一个自己选择区域的位置：az group create -l westus -n Contoso-Voting-Stage -
重复资源组创建命令，创建另一个名为
Contoso-Voting-Prod的资源组，用于生产环境。
你现在已经完成了所需的资源组创建。在接下来的步骤中，你将创建一个 Azure Kubernetes 集群。
创建 Azure Kubernetes 服务
AKS 是微软 Azure 提供的托管 Kubernetes 服务。在 Kubernetes 集群中有两种类型的主机——主节点（也称为控制平面）和节点。在 AKS 中，终端用户并不直接使用主节点。微软会创建并管理主节点，并将其隐藏在终端用户之外。作为用户，你只需在自己的订阅中部署 AKS 节点（Kubernetes 节点），而 Kubernetes 配置和微软托管的 Kubernetes 主节点的连接则在后台进行。使用 AKS 时，你只需为节点的基础设施费用付费；主节点由微软免费提供。
我们将使用 AKS 来托管我们的容器。
我们从创建一个 AKS 集群开始：
-
使用你的 Azure 凭据登录 Cloud Shell。
-
运行以下命令以创建一个具有默认配置和最新版本的 AKS 集群：
az aks create: The syntax for creating an AKS cluster. b) `--resource-group & --name`: The resource group's name and AKS cluster name. c) `--node-count`: The number of AKS nodes you're creating. d) `--enable-addons`: This specifies add-ons, such as monitoring and HTTP routing. e) `--generate-ssh-keys`: This is a flag that lets `az cli` create SSH keys to be used for agent nodes. -
AKS 集群可能需要最多 10 分钟才能准备好。你可以通过运行以下命令来查看状态：
az aks list -
一旦你的集群准备就绪，你可以通过运行以下命令在 Cloud Shell 会话中获取 Kubernetes 认证配置：
az aks get-credentials --resource-group Contoso-Voting-Stage --name Contoso-Stage-AKS -
现在你可以尝试运行
kubectl命令与 Kubernetes 进行交互。运行以下命令以获取所有 Kubernetes 节点的列表：kubectl get nodes
现在您的 Azure Kubernetes 集群已经准备好；请重复该过程为生产环境创建另一个 AKS 集群。
创建 Azure 容器注册表
ACR 是一个由 Microsoft Azure 托管和管理的私有 Docker 容器注册表。ACR 完全兼容 Docker，并且工作方式与 Docker 相同，唯一的区别是它由微软管理、托管并提供安全保障。我们将使用 ACR 来存储我们的容器镜像。
让我们为该项目创建一个容器注册表：
-
登录 Azure Cloud Shell 并运行以下命令来创建容器注册表：
az acr create --resource-group Contoso-Voting-Stage --name ContosoStageACR --sku Basic -
一旦您的容器注册表准备好，您可以通过运行以下命令获取其状态和详细信息：
az acr list
集成 ACR 与 AKS
AKS 需要有权限访问 ACR 中的容器镜像才能运行应用。让我们启用 AKS 与 ACR 进行交互的权限。
运行以下命令将 AKS 与我们的 ACR 集成：
az aks update -n Contoso-Stage-AKS -g Contoso-Voting-Stage --attach-acr ContosoStageACR
现在我们的基础设施已经准备好，我们将开始为应用设置代码仓库。
设置 Azure Repos 用于投票应用
在本节中，我们将创建一个新的 Azure DevOps 项目并导入 Azure Repos 中的投票应用源代码：
-
登录 Azure DevOps 并创建一个名为
Contoso Voting App或您选择的其他名称的新项目。 -
导航到 Azure Repos 并点击导入 Git 仓库。请从以下链接导入 Azure 投票应用仓库：
github.com/Azure-Samples/azure-voting-app-redis：
图 11.42 – 导入仓库
现在我们的仓库已经准备好，接下来让我们从构建管道开始。
设置 CI 管道
构建管道将负责构建容器镜像并将其推送到 ACR。让我们开始吧：
-
登录 Azure DevOps 并打开Contoso Voting App 项目。
-
导航到管道并点击创建管道。
-
点击使用经典编辑器通过 UI 创建管道。
-
选择您在上一部分中创建的源 Azure 仓库作为管道的源。
-
对于模板，选择Docker 容器作为模板类型：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.43_B16392.jpg
图 11.43 – Docker 容器管道模板
-
在
root/azure-vote/Dockerfile仓库中。f) 勾选包含最新标签：
图 11.44 – 推送镜像
-
在推送镜像任务中，重新选择 Azure 订阅和 ACR，并确保任务为推送镜像。请确保勾选包含最新标签。
-
完成后，审查两个任务并点击保存并运行以开始管道作业执行。
-
审查作业日志以查看有关镜像构建和推送到 ACR 的详细信息。
-
完成后，导航到 Azure 门户并打开您之前创建的容器注册表。
-
导航到仓库；您应该能看到一个新镜像在那里被创建。让我们查看该镜像，找出我们在应用程序部署配置中需要更新的镜像名称：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.45_B16392.jpg
图 11.45 – ACR 中的容器镜像
-
记下镜像拉取连接字符串。我们将在下一个练习中使用它：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.46_B16392.jpg
图 11.46 – ACR 中的镜像语法
-
我们的管道现在已准备好并测试完成，所以让我们返回并在管道触发器配置中启用 CI：
图 11.47 – 启用 CI
现在我们的 CI 管道已经准备好，让我们从部署管道开始。
设置 CD 管道
在本节中，我们将设置部署管道，该管道将把应用程序代码部署到 AKS，并在需要时进行更新。Azure Pipelines 提供与托管在本地和云中的 Kubernetes 集群的本地集成。
更新 Kubernetes 部署清单文件
在 Kubernetes 的世界里，应用程序部署是通过编写 JSON 或 YAML 格式的清单文件来管理的。此示例应用程序的部署文件已经包含在 Azure 仓库中。您可以通过查看 Azure Repos 根目录中的azure-vote-all-in-one-redis.yaml文件来检查部署配置。
默认情况下，部署清单已配置为使用微软提供的容器镜像。我们需要更新它，开始使用我们自己的自定义镜像。让我们开始吧：
-
导航到
azure-vote-all-in-one-redis.yaml文件。 -
在文件编辑器的右上角点击编辑。
-
查找部署清单中的以下部分。这会将容器引擎重定向为使用微软提供的 Docker 镜像：
image: microsoft/azure-vote-front:v1 -
用您自己的容器注册表和镜像名称替换该值。它应该像下面给出的示例一样。您应该指定最新的标签，以确保始终使用最新的镜像：
image: contosostageacr.azurecr.io/contosovotingapp:latest -
提交更改以保存部署清单文件。
现在，您的应用程序清单已经准备好进行部署。
设置发布管道
发布管道将在 Kubernetes 集群中应用部署清单，并执行镜像更新任务。让我们构建一个管道来自动化部署：
-
登录到Azure DevOps | 管道 | 发布。
-
创建一个新的发布管道。选择Deploy to a Kubernetes cluster模板：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.48_B16392.jpg
图 11.48 – Deploy to a Kubernetes cluster 模板
-
将阶段名称更新为
Development Environment。 -
让我们从添加工件开始。在工件中点击添加。
-
在Artifact中，选择 Azure 仓库并选择我们导入的仓库。点击添加：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.49_B16392.jpg
图 11.49 – 向管道中添加工件
-
在
Deploy to Kubernetes中。b)
azure-vote-all-in-one-redis.yaml）。浏览到您的默认目录并选择部署 YAML 文件。如果需要，我们可以定义其他选项，例如 Kubernetes 秘密和配置映射。验证所有配置有效后，点击保存：图 11.51 – 选择部署 YAML
e) 查看任务配置并点击保存以保存到目前为止的进度：
图 11.52 – 任务配置
-
现在，我们将在管道中添加另一个步骤，以便在部署后更新 AKS 中的镜像。这将确保每次发布时，Kubernetes 都会拉取最新的镜像。点击**+号，向管道中添加另一个kubectl**任务。
-
配置任务，使其使用相同的 Kubernetes 连接。在参数中使用
image deployments/azure-vote-front azure-vote-front=youracrname.azurecr.io/contosovotingapp:latest。在生产部署中，您可能不希望在管道中使用最新标签，而是应引用使用构建管道生成的版本标签。这样可以帮助您管理特定版本的部署，并且在需要时可以轻松回滚。 -
一旦准备就绪，保存管道并创建一个发布，以测试部署管道。
-
查看发布日志以了解部署步骤和流程。
-
一旦成功完成，返回编辑管道并启用持续部署：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.53_B16392.jpg
图 11.53 – 启用持续部署
至此，我们的构建和发布配置已完成，具备了完整的 CI/CD 自动化。接下来查看 AKS 集群，确保我们的应用已正确部署并且可以访问（使用我们刚刚发布的版本）：
-
使用 Azure shell 连接到您的 AKS 集群。
-
运行
kubectl get pods和kubectl get services：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.54_B16392.jpg图 11.54 – kubectl 结果
-
记下
azure-vote-front应用的公共 IP。您可以尝试访问该公共 IP，以检查应用是否按预期运行：
图 11.55 – 投票应用已启动
接下来，我们将为这个应用模拟一次端到端的 CI/CD 体验。
模拟端到端的 CI/CD 体验
在前面的部分中，我们设置了 CI/CD 管道。让我们尝试操作它，体验整体流程。首先，从Azure 投票应用更新应用标题为Contoso 投票应用：
-
浏览到Azure Repos | 文件 | azure-vote | azure-vote | config_file.cfg并点击编辑。
-
将标题的值从Azure 投票应用更改为Contoso 投票应用：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_11.56_B16392.jpg
图 11.56 – 更新应用名称
-
通过拉取请求流程提交更改。
-
一旦拉取请求完成，构建流水线将会触发，构建 Docker 镜像并推送到 ACR。
-
一旦构建流水线完成，它将触发发布流水线以启动另一个发布。最终，你应该能看到你的 Web 应用已更新标题。
本文到此结束，关于在 AKS 上托管的基于容器的基础设施的 CI/CD 流水线设置。
DevOps 的 Azure 架构中心
Azure 架构中心是一个集中式平台，提供关于在 Azure 上使用已建立的模式和实践来构建解决方案的指导。关于 DevOps，有多个示例架构可供参考。
你可以在这里访问 Azure 架构中心：docs.microsoft.com/en-us/azure/architecture/。
请参考以下链接，了解更多关于在各种基础设施和应用场景中规划适当 DevOps 架构的内容：
-
Azure DevOps：
docs.microsoft.com/en-us/azure/architecture/example-scenario/apps/devops-dotnet-webapp -
容器的 DevOps：
docs.microsoft.com/en-us/azure/architecture/example-scenario/apps/devops-with-aks -
使用 AKS 和 Azure DevOps 构建微服务：
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/microservices-with-aks -
AKS 的安全 DevOps：
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/secure-devops-for-kubernetes -
用于聊天机器人 Azure DevOps CI/CD 流水线：
docs.microsoft.com/en-us/azure/architecture/example-scenario/apps/devops-cicd-chatbot -
Azure 虚拟机的 CI/CD：
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/cicd-for-azure-vms -
Azure Web 应用的 CI/CD：
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/azure-devops-continuous-integration-and-continuous-deployment-for-azure-web-apps -
容器的 CI/CD：
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/cicd-for-containers -
在 AKS 上使用 Jenkins 和 Kubernetes 进行容器 CI/CD:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/container-cicd-using-jenkins-and-kubernetes-on-azure-container-service -
Azure 中的 DevSecOps:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/devsecops-in-azure -
用于测试 IaaS 解决方案的 DevTest 部署:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/dev-test-iaas -
用于测试 PaaS 解决方案的 DevTest 部署:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/dev-test-paas -
用于测试微服务解决方案的 DevTest 部署:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/dev-test-microservice -
DevTest 镜像工厂:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/dev-test-image-factory -
使用 Jenkins 和 Terraform 在 Azure 上进行不可变基础架构 CI/CD 的虚拟架构概述:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/immutable-infrastructure-cicd-using-jenkins-and-terraform-on-azure-virtual-architecture-overview -
在混合环境中的 DevOps:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/java-cicd-using-jenkins-and-azure-web-apps -
使用 Jenkins 和 Azure Web 应用进行 Java CI/CD:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/java-cicd-using-jenkins-and-azure-web-apps -
在 Azure 上运行 Jenkins 服务器:
docs.microsoft.com/en-us/azure/architecture/example-scenario/apps/jenkins -
用于开发测试的 SharePoint Farm:
docs.microsoft.com/en-us/azure/architecture/solution-ideas/articles/sharepoint-farm-devtest -
使用低成本无服务器的 Azure 服务实时共享位置：
docs.microsoft.com/en-us/azure/architecture/example-scenario/signalr/
总结
在本章中，我们分析了一个基于 .NET 和 SQL 的应用程序，并使用 Azure DevOps 为其设置了 CI/CD 管道。我们还探讨了如何通过审批工作流管理生产和预发布环境。
同样，我们还分析了一个基于容器的应用程序，并演示了如何使用 ACR 和 AKS 设置端到端的 CI/CD 管道。
最后，我们讨论了 Azure 架构中心，在规划 DevOps 架构时可以参考此资源。
这是最后一章，我们希望你喜欢阅读这本书！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
