原文：
annas-archive.org/md5/b9af5174af71449b8d6f11a56dee9821译者：飞龙
前言
DevOps 在近年来已经成为一个热门词汇。DevOps 是一种结合了文化理念、实践和工具的模式，能够提高组织以高速度和高质量交付应用程序和服务的能力。Azure DevOps 是微软提供的软件即服务（SaaS）平台，提供一整套工具，用于通过应用 DevOps 技术开发和部署软件。本书首先概述了 Azure DevOps 平台，然后深入探讨了各种工具和功能，如项目管理的看板、源代码管理的代码库、构建和发布管道、测试计划、工件等。
阅读本书后，您将对 Azure DevOps 能够为您提供的提升开发生命周期的工具和功能有一个完整清晰的认识。
本书适合谁阅读
本书面向希望将 DevOps 技术应用到项目中，并使用 Azure DevOps 来管理整个应用开发过程的解决方案开发人员/架构师和项目经理。
本书涵盖的内容
第一章，Azure DevOps 概述，为您提供了 Azure DevOps 的完整概述，包括看板、代码库、管道、测试计划和工件等工具集。
第二章，使用 Azure DevOps 看板管理项目，详细解释了 Azure DevOps 的项目管理功能，并展示了如何使用看板和工作项、如何创建冲刺、如何管理待办事项以及如何跟踪所有活动。
第三章，使用 Azure DevOps 进行源代码管理，解释了如何使用 Azure DevOps Repos 功能和 Git 进行源代码控制。它展示了如何创建代码库、如何处理提交、推送和拉取、如何处理分支等内容。
第四章，理解 Azure DevOps 管道，展示了如何为代码创建构建管道，并使用 Azure Pipelines 最佳地处理持续集成。
第五章，在构建管道中运行质量测试，解释了如何在构建管道中创建和执行代码质量测试。
第六章，托管您自己的 Azure 管道代理，展示了如何创建自己的构建代理并将其用于构建管道中。
第七章，在 Azure DevOps 中使用工件，解释了如何使用工件（软件包源）创建和共享软件包，并将完全集成的软件包管理功能添加到您的持续集成/持续交付管道中。
第八章，使用 Azure DevOps 部署应用程序，解释了如何使用发布管道处理代码的持续部署，并展示如何在将代码发布到生产环境之前使用阶段和审批。
第九章，将 Azure DevOps 与 GitHub 集成，向你展示如何将 Azure DevOps 工具与 GitHub 集成，并在你的持续集成/持续交付过程中使用这两个应用程序。
第十章，在 Azure DevOps 中使用测试计划，展示了如何在 Azure DevOps 中使用测试计划管理项目的测试生命周期。
第十一章，使用 Azure DevOps 的真实世界 CI/CD 场景，向你展示了如何使用 Azure DevOps 处理真实世界中的持续集成/持续交付场景。
为了充分利用本书
要跟随本书中描述的主题，你需要拥有有效的 Azure DevOps 订阅。你可以通过以下链接激活免费账户：
azure.microsoft.com/en-us/services/devops/
如果你正在使用本书的数字版，我们建议你亲自输入代码或通过 GitHub 仓库访问代码（链接将在下一节提供）。这样做可以帮助你避免复制粘贴代码时可能出现的错误。
下载示例代码文件
你可以从 GitHub 下载本书的示例代码文件：github.com/PacktPublishing/Learning-Azure-DevOps—B16392。如果代码有更新，将会在现有的 GitHub 仓库中更新。
我们还提供了来自我们丰富书籍和视频目录的其他代码包，您可以在github.com/PacktPublishing/查看！
下载彩色图片
我们还提供了一个 PDF 文件，其中包含本书中使用的截图/图表的彩色图片。你可以在这里下载：www.packtpub.com/sites/default/files/downloads/9781800563513_ColorImages.pdf。
使用的约定
本书中使用了多种文本约定。
文本中的代码：表示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 用户名。比如：“你可以下载名为node-v6.12.3-x64.msi的文件，并使用交互式安装程序安装它。”
一段代码块设置如下：
using System;
using PartsUnlimited.Models;
namespace AzureArtifacts
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine('Hello World!');
CartItem caritem = new CartItem()
当我们希望引起你对某个代码块中特定部分的注意时，相关的行或项目会用粗体显示：
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Install-Module AzureRM -AllowClobber
任何命令行输入或输出均按以下格式编写：
docker run \
-e VSTS_ACCOUNT=<name> \
-e VSTS_TOKEN=<pat> \
-it mcr.microsoft.com/azure-pipelines/vsts-agent
粗体：表示新术语、重要词汇或你在屏幕上看到的词汇。例如，菜单或对话框中的词汇会以这种方式显示。这里有个例子：‘使用你的微软账户登录，在左侧菜单中选择Artifacts’。
提示或重要说明
如此显示。
联系我们
我们欢迎读者的反馈。
一般反馈：如果你对本书的任何部分有疑问，请在邮件主题中注明书名，并通过 customercare@packtpub.com 与我们联系。
勘误：虽然我们已尽力确保内容的准确性，但错误仍有可能发生。如果你在本书中发现错误，我们将非常感激你向我们报告。请访问 www.packtpub.com/support/errata，选择你的书籍，点击“勘误提交表单”链接并填写相关信息。
盗版：如果你在互联网上发现任何非法复制我们的作品的形式，我们将非常感激你提供相关地址或网站名称。请通过 copyright@packt.com 与我们联系，并附上该材料的链接。
如果你有兴趣成为作者：如果你在某个领域拥有专业知识并且有兴趣写作或为书籍做贡献，请访问 authors.packtpub.com。
评价
请留下评价。阅读并使用本书后，为什么不在购买网站上留下评价呢？潜在读者可以参考你的公正意见来做购买决定，我们在 Packt 可以了解你对我们产品的看法，作者也可以看到你对他们书籍的反馈。谢谢！
欲了解更多关于 Packt 的信息，请访问 packt.com。
第一部分：DevOps 原则与 Azure DevOps 项目管理
本节将涵盖 DevOps 原则、Azure DevOps 关键概念以及项目管理内容。
本节包含以下章节：
-
第一章，Azure DevOps 概述
-
第二章，使用 Azure DevOps Boards 管理项目
第一章：Azure DevOps 概述
本章介绍了本书的第一个主题：DevOps原则和Azure DevOps项目管理。在本章中，我们将从介绍 DevOps 开始，并概述不同的 DevOps 原则。接下来，我们将介绍 Azure DevOps 的关键概念及其提供的不同服务。最后，我们将介绍本书将使用的场景。
本章将覆盖以下主题：
-
介绍 DevOps
-
理解 DevOps 原则
-
介绍 Azure DevOps 关键概念
-
探索 Azure DevOps 服务
-
介绍场景
让我们开始吧！
介绍 DevOps
长时间以来，开发和运维一直被分割成相互独立的模块，双方各自有着不同的关注点和责任。开发人员编写代码并确保其在开发系统上正常运行，而系统管理员则负责在组织的 IT 基础设施中进行实际的部署和集成。
由于这两个独立模块之间的沟通有限，两支团队大多是分开工作的。然而，他们又非常依赖对方，因为不同团队之间缺乏跨平台的知识。
这一方法与大多数项目中使用的瀑布模型非常契合。瀑布模型基于软件开发生命周期（SDLC），它有明确的流程来创建软件。瀑布模型将项目交付物分解为线性顺序的阶段，每个阶段依赖于前一个阶段的交付物。这个事件序列可能如下所示：
图 1.1 – 瀑布模型
瀑布模型非常适合以下情况下的项目：
-
在开发生命周期的早期，客户和开发人员就要达成一致，确定交付内容，并在项目开发过程中尽量避免修改。
-
对于与外部系统的集成，通常需要多个软件组件并行设计。在这种情况下，尽早完成设计文档是理想的做法。
-
各个团队成员通常也会同时参与其他项目。例如，业务分析师可以收集需求并创建设计，而开发人员则在处理另一个项目。
-
当无法将需求阶段分解时，客户无法充分参与到较小的交付物中。
然而，客户在看到可工作的软件之前，可能并不完全知道他们的需求。这可能导致需求的变更，从而引发重新设计、重新实现和重新验证。这会显著增加项目的成本。
因此，敏捷和 DevOps 于 2009 年被引入，并慢慢地在软件开发界占据主导地位。它们取代了大多数项目中使用的瀑布模型。DevOps 是敏捷和持续交付方法的自然延伸，代表了开发和运维。它是一种将开发、IT 运维和质量保证融合为一个连续过程的实践。
以下图表展示了 DevOps 的不同组成部分：
图 1.2 – DevOps 方法论
这是一种基于团队的迭代式开发方法，所有利益相关者，如开发人员、管理员、测试人员以及客户代表，都属于同一个团队。应用程序以功能组件的形式交付，而不是在项目开始时创建时间表和任务，项目被划分为较小的阶段，称为冲刺。每个冲刺的持续时间在前期定义，并在每个冲刺开始时规划好交付物的清单。所有这些交付物都是与客户一起定义的，并由客户按照业务价值进行优先级排序。在每个冲刺结束时，完成的工作将通过日常构建和冲刺结束时的演示进行团队评审和评估。
这带来了以下优势：
-
通过在整个项目过程中与项目团队直接合作，客户将体验到更强的归属感。
-
客户有机会在项目的早期阶段查看交付的工作，并可以对此做出适当的决策和调整。
-
开发更加注重业务和价值。这是与客户更紧密合作并更好地理解其需求的结果。
-
敏捷工作方式使我们能够迅速创建产品的基础版本，并在后续迭代中进行构建。
在简要介绍完 DevOps 后，我们将探讨不同的 DevOps 原则。
理解 DevOps 原则
关于 DevOps 有很多不同的定义。它们大多数擅长解释在交付软件和 IT 项目中寻找合适流程的不同方面。在接下来的章节中，我们将重点介绍我们认为在采用 DevOps 工作方式时至关重要的六个 DevOps 原则。
原则 1 – 以客户为中心的行动
如今，软件开发项目需要具有短周期和反馈循环，并将最终用户和真实客户融入团队。为了充分满足客户的需求，所有与构建软件和产品相关的活动必须涉及这些客户。DevOps 团队和组织必须持续投资于产品和服务，以便让客户获得最大的成果，同时保持尽可能精简，以便在策略不再有效时持续创新并进行调整。
原则 2 – 以终为始
组织需要更像产品公司一样运作。他们应该更多地关注构建可以销售给真实客户的可用产品。这种工程思维需要被所有员工共享，才能实现这些产品。这意味着他们应该放弃那种每个部门只关注特定角色并承担独立责任的做法。
原则 3 – 端到端责任
在大多数传统软件开发项目中，开发的软件和服务会交给运维部门，由他们在初始开发过程后进行部署和维护。通过采用 DevOps 工作方式，DevOps 团队将对他们交付的项目承担完全的责任和义务。这意味着，一旦产品由团队交付并需要维护，它仍然由团队负责。团队还将为该产品提供支持，直到它达到生命周期的终点。这大大增加了团队的责任感，并提高了开发产品的质量。
原则 4 – 跨职能自治团队
与垂直和完全负责的团队合作的组织，需要让这些团队在整个生命周期中完全独立工作。为了使这些团队能够完全独立工作，需要具备广泛且均衡的技能组合。团队成员需要具备 T 型技能，而不是只擅长自己角色的老派 IT 专家。每个团队成员应该具备的技能包括开发、需求分析、测试和管理技能等。
原则 5 – 持续改进
端到端责任的另一个部分是，对于组织来说，持续适应变化非常重要。可能会有许多变化的情况，比如发布了新技术、客户需求变化等。持续改进是 DevOps 中的一个重要关注点，旨在优化速度和成本，减少浪费，简化交付，并持续改进构建和发布的软件和服务。一个重要的活动是将实验融入这些循环中，这将使团队能够从失败中学习，这对于持续改进至关重要。
原则 6 – 自动化一切
要完全采纳并在组织内部嵌入持续改进文化，大多数组织需要消除大量浪费和技术债务。为了实现高循环率并尽早处理来自客户和最终用户的即时反馈，自动化一切变得至关重要。这意味着，不仅软件开发过程应使用持续交付自动化（包括持续开发和集成），而且整个基础设施环境也需要自动化。基础设施还需要为新的工作方式做好准备。从这个角度来看，自动化就是推动团队更新向客户交付服务方式的同义词。
在本节中，我们介绍了采纳或迁移到 DevOps 工作方式时非常重要的六个原则。在接下来的几个章节中，我们将讨论 Azure DevOps 作为支持团队以 DevOps 方式工作的工具所提供的功能。
引入 Azure DevOps 关键概念
Azure DevOps 为 DevOps 团队提供了多种服务，使他们能够规划、工作、协作开发代码，并构建和部署软件和服务。大多数 DevOps 团队依赖于多种工具，并为应用生命周期的每个阶段构建自定义工具链。
以下图表展示了定义在应用生命周期中的各个阶段：
图 1.3 – 应用生命周期阶段
在接下来的章节中，我们将详细解释这些阶段以及相应的 Microsoft 工具和产品。
规划
在规划阶段，团队可以使用看板和待办事项列表在 Azure Boards 中定义、跟踪并安排需要完成的工作。他们也可以使用 GitHub 进行此操作。在 GitHub 中，可以通过建议一个新想法或表示需要追踪一个 bug 来创建一个 issue。这些问题可以进行组织并分配给团队。
开发
开发阶段由 Visual Studio Code 和 Visual Studio 支持。Visual Studio Code 是一个跨平台编辑器，而 Visual Studio 是仅限 Windows 和 Mac 的 IDE。你可以使用 Azure DevOps 进行自动化测试，并使用 Azure Pipelines 创建自动构建来编译源代码。代码可以通过 Azure DevOps 或 GitHub 在团队之间共享。
交付
交付阶段是关于将应用程序和服务部署到目标环境的过程。你可以使用 Azure Pipelines 自动将代码部署到任何 Azure 服务或本地环境。你可以使用 Azure Resource Manager 模板或 Terraform 来为你的应用程序或基础设施组件创建环境。你还可以将 Jenkins 和 Spinnaker 集成到 Azure DevOps Pipelines 中。
运维
在这一阶段，你会为监控你的应用程序和服务实现全栈监控。你还可以使用不同的自动化工具来管理你的云环境，如 Azure Automation、Chef 等。保持你的应用程序和服务的安全也是这一阶段的一部分。因此，你可以使用诸如 Azure 策略和 Azure 安全中心等功能和服务。
为了支持分析、设计、构建、部署和维护软件及基础设施产品和服务的完整生命周期，Azure DevOps 提供了集成的功能，可以通过任何网络浏览器访问。
Azure DevOps 提供了一套解决方案和工具的组合，可用于在每个应用程序生命周期阶段创建独特且定制的工作流。这些解决方案将在接下来的章节中描述。
持续集成和持续交付（CI/CD）
你可以通过 CI/CD（以及持续部署）在 Azure DevOps 中自动化每个 DevOps 流程。CI 用于项目的开发阶段，指的是以完全自动化的方式构建和测试代码。每当你提交更改到主分支时，变更将会被验证，并自动打包成构建工件。使用 CD 时，交付阶段也会自动化。每当构建工件可用时，工件会自动部署到所需的环境中。当开发团队同时使用持续集成和持续部署时，代码始终可以随时准备好进行生产部署。团队部署一个可工作的应用程序到生产环境中所需做的唯一事情，就是触发从开发到部署的过渡。这将使自动化构建工件变得可用进行部署。这一触发过程可以简单到按下一个按钮。
使用 Azure DevOps，你还可以实现持续部署。将其添加到你的开发生命周期中意味着你可以自动化整个过程，从代码提交到生产部署。开发和交付阶段之间的触发过程是完全自动化的。因此，当代码更改经过验证并通过开发阶段进行的所有测试后，变更将自动发布到生产环境。这意味着客户会在新版本和相应的改进一经发布时就能立刻收到。
敏捷开发支持
Azure DevOps 支持采用敏捷开发方法的团队，提供计划、跟踪和报告功能。这将导致更短的发布周期和软件开发过程的完全可见性。你可以使用 Azure Boards（将在本章的下一部分详细介绍）来管理待办事项并定义、分配和跟踪工作项。你还可以使用高级分析和报告功能，创建自定义仪表板来跟踪进度。
版本控制
版本控制系统，也称为源代码控制系统，是多开发者项目的基本工具。它允许开发者在代码上进行协作并跟踪更改。所有代码文件的历史也会保存在版本控制系统中。这使得在出现错误或 bug 时，能够轻松回退到代码文件的其他版本。
Azure DevOps 支持两种不同类型的源代码管理：Git（分布式）和团队基础版本控制（TFVS）。使用 Git 时，每个开发者在其开发机器上都有一份源代码库的副本。所有的分支和历史信息都包含在源代码库中。每个开发者直接与自己本地的代码库副本进行工作，所有的更改通过一个单独的步骤在本地和源代码库之间共享。可以在本地文件系统上提交更改，并且可以在没有网络连接的情况下执行版本控制操作。开发者可以在开发机器上轻松创建分支，之后可以将其合并、发布或单独处理。使用 TFVC 时，开发者的本地开发机器上只有每个文件的一个版本。所有其他的文件以及历史数据都仅保存在服务器上。分支也在服务器上创建。
基础设施即代码
团队还可以在 Azure DevOps 中管理基础设施。项目中使用的基础设施组件，如网络、虚拟机和负载均衡器，可以使用与源代码相同的版本控制功能和能力进行管理。
与持续交付一起使用时，基础设施即代码（IaC）模型每次部署时都会生成相同的环境。如果没有 IaC，团队需要手动配置和维护所有单独部署环境的设置，这是一项耗时且容易出错的任务。最可能的结果是，随着时间推移，每个环境都会成为一个独一无二的配置，这种配置不再能被自动重现。环境之间的不一致性将在部署阶段导致问题。
配置管理
配置管理指的是与项目相关的所有项和工件，以及它们之间的关系。这些项会被存储、检索、唯一标识并修改。这包括源代码、文件和二进制文件等项。配置管理系统是唯一真正的配置项来源。
使用 Azure DevOps，团队可以管理整个系统中的资源配置，推出配置更新、强制执行所需的状态，并自动解决意外的变更和问题。Azure 提供了多种 DevOps 工具和功能来进行配置管理，例如 Chef、Puppet、Ansible 和 Azure Automation。
监控
你可以使用 Azure Monitor 来进行全栈持续监控。你的基础设施和应用程序的健康状况可以集成到 Grafana、Kibana 和 Azure 门户中的现有仪表盘中。你还可以监控应用程序的可用性、性能和使用情况，无论它们是托管在本地还是在 Azure 中。Azure Monitor 支持大多数流行的编程语言和框架，如 .NET、Java 和 Node.js，并与 Azure DevOps 中的 DevOps 流程和工具集成。
探索 Azure DevOps 服务
在本节中，我们将介绍 Azure DevOps 提供的不同服务。这些服务可以在整个生命周期中支持团队实现客户的业务价值。
Azure Boards
Azure Boards 可以用于使用可用的敏捷规划工具计划、跟踪和讨论跨团队的工作。通过 Azure Boards，团队可以管理他们的软件项目。它还提供了一套独特的功能，包括对 Scrum 和 Kanban 的原生支持。你还可以创建可定制的仪表盘，并提供集成的报告和与 Microsoft Teams 和 Slack 的集成。
你可以使用 Azure Boards 创建并跟踪与项目相关的用户故事、待办事项、任务、特性和缺陷。
以下屏幕截图展示了一个 Azure Board 的示例：
图 1.4 – Azure Boards
Azure Repos
Azure Repos 提供对私有 Git 仓库托管和团队基础服务器控制（TFSC）的支持。它提供了一套版本控制工具，可以用于管理每个开发项目的源代码，无论项目大小。当你编辑代码时，你要求源代码管理系统创建文件的快照。这个快照会被永久保存，以便以后在需要时可以调用。
如今，Git 是开发人员中使用最广泛的版本控制系统。Azure Repos 提供标准的 Git，使得开发人员可以使用他们选择的工具和客户端，例如 Git for Windows、Mac、第三方 Git 服务，以及像 Visual Studio 和 Visual Studio Code 这样的工具。
以下屏幕截图展示了你可以推送到 Azure 仓库的提交示例：
图 1.5 – Azure Repos
Azure Pipelines
你可以使用 Azure Pipelines 自动构建、测试和部署代码，使其可以供其他用户使用，并将其部署到不同的目标，如开发、测试、验收和生产（DTAP）环境。它结合了 CI/CD，自动构建和部署你的代码。
在您可以使用 Azure Pipelines 之前，应该将代码放入版本控制系统中，例如 Azure Repos。Azure Pipelines 可以与多种版本控制系统集成，如 Azure Repos、Git、TFVS、GitHub、GitHub Enterprise、Subversion 和 Bitbucket Cloud。您还可以将 Pipelines 与大多数应用程序类型一起使用，如 Java、JavaScript、Node.js、Python、.NET、C++、Go、PHP 和 XCode。应用程序可以部署到多个目标环境，包括容器注册表、虚拟机、Azure 服务或任何本地或云端目标。
以下截图展示了一个 Azure Pipeline 运行的示例：
图 1.6 – Azure Pipelines
Azure 测试计划
使用 Azure 测试计划，团队可以通过 Azure DevOps 中的计划测试和探索性测试服务提高代码质量。Azure 测试计划提供了计划手动测试、探索性测试、用户验收测试和收集利益相关者反馈的功能。通过手动测试，测试人员和测试主管将测试组织到测试计划和测试套件中。团队可以直接从看板或工作中心开始测试。通过用户验收测试，可以验证为满足客户需求所交付的价值。通常由指定的测试人员执行。探索性测试包括由整个开发团队执行的测试，开发人员、产品负责人和测试人员都会参与。软件测试通过探索软件系统进行，而不使用测试计划或测试套件。利益相关者反馈收集通常由市场或销售团队在开发团队外部完成。开发人员可以从 Azure DevOps 请求对其用户故事和功能的反馈，利益相关者可以直接回复反馈项。
以下截图展示了一个 Azure 测试计划的示例：
图 1.7 – Azure 测试计划
Azure Artifacts
使用 Azure Artifacts，您可以从私有和公共源与 Azure DevOps 中的团队创建和共享 NuGet、npm、Python 和 Maven 包。这些包可以在源代码中使用，并可以在 CI/CD 管道中使用。通过 Azure Artifacts，您可以创建多个源，使用它们来组织和控制对包的访问。
以下截图展示了 Azure Artifacts 中一个源的示例：
图 1.8 – Azure Artifacts
扩展市场
您可以从 Visual Studio Marketplace 下载 Azure DevOps 的扩展。这些扩展是简单的插件，可以用来定制和扩展您团队在 Azure DevOps 中的使用体验。它们可以通过扩展工作项的规划和跟踪、代码测试和跟踪、管道构建和发布流程，以及团队成员之间的协作来提供帮助。这些扩展由微软和社区创建。
以下截图展示了可以从市场下载的一些扩展：
图 1.9 – 扩展市场
我们在前面章节中介绍的服务将在本书接下来的章节中得到更深入的讲解。在下一节中，我们将介绍本书将使用的场景。
介绍场景
本书中，我们将使用两种不同的场景进行演示。我们将使用可以通过 DevOps 生成器在您的 Azure DevOps 环境中生成和安装的示例项目。对于本书，我们将安装 Tailwind Traders 和 Parts Unlimited。Tailwind Traders 是一个示例零售公司，展示了智能应用体验的未来，而 Parts Unlimited 是一个示例电子商务网站。
创建启动项目
为了创建场景项目，我们将使用 Azure DevOps 演示生成器，它将为我们生成示例项目。这些项目可以免费使用。在生成项目之前，您需要从市场安装两个不同的 Azure DevOps 扩展，它们都被 Tailwind Traders 项目所使用。以下是这些扩展：
-
ARM 输出：此扩展读取 ARM 部署的输出值并将其设置为 Azure Pipelines 变量。您可以从
marketplace.visualstudio.com/items?itemName=keesschollaart.arm-outputs下载并安装此扩展。 -
团队项目健康：此扩展使用户能够可视化构建的整体健康状况，从而提供类似于 Codify Build Light 的视觉提示。您可以从
marketplace.visualstudio.com/items?itemName=ms-devlabs.TeamProjectHealth下载此扩展。
安装完成后，您可以在 Azure DevOps 组织中生成示例项目：
-
首先，访问以下网站：
azuredevopsdemogenerator.azurewebsites.net/。 -
点击登录按钮。如果您还没有 Azure 账户，可以点击免费开始按钮注册试用账户：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_1.10_B16392.jpg
图 1.10 – Azure DevOps 演示生成器
-
将项目命名为
Tailwind Traders，选择一个组织，并通过点击选择模板按钮来选择一个模板。从列表中选择Tailwind Traders并点击选择模板。 -
填写完这些信息后，页面应如下所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_1.11_B16392.jpg
图 1.11 – 创建新项目
-
点击创建项目按钮。
-
创建项目后，导航到
dev.azure.com/。 -
使用您的凭据登录，并选择您创建项目的组织。选择Tailwind Traders项目查看是否有任何内容生成。
-
重复这些步骤，在您的 DevOps 环境中创建Parts Unlimited项目。
小贴士
有关 Tailwind Traders 示例项目的更多信息，请参阅以下网站：
github.com/Microsoft/TailwindTraders。有关 Parts Unlimited 示例的更多信息，请参阅microsoft.github.io/PartsUnlimited/。
小结
本章中，我们介绍了 DevOps 的一些基础知识，并涵盖了六个不同的 DevOps 原则。接着，我们介绍了 Azure DevOps 的关键概念，以及 Azure DevOps 提供的不同解决方案，以支持团队在应用生命周期的各个阶段。之后，我们查看了 Azure DevOps 提供的不同功能，并介绍并创建了将在本书接下来的章节中使用的两个场景。
在下一章中，我们将介绍如何使用 Azure Boards 管理项目。
深入阅读
请查看以下链接，了解更多本章涵盖的主题：
-
Azure 自动化文档：
docs.microsoft.com/en-us/azure/automation/ -
Azure DevOps 演示生成器：
docs.microsoft.com/en-us/azure/devops/demo-gen/use-demo-generator-v2?view=azure-devops&viewFallbackFrom=vsts -
Azure 的 Tailwind Traders 参考应用概述：
www.youtube.com/watch?v=EP-PME-1tq0
第二章：
第二章：使用 Azure DevOps Boards 管理项目
在上一章中，我们介绍了 DevOps，并讲解了六个原则。我们还简要介绍了 Azure DevOps 的关键概念和不同的服务。最后，我们介绍了本书将贯穿使用的场景。
在本章中，我们将更详细地讲解Azure Boards。我们将从 Azure DevOps 中可用的不同流程和过程模板开始。接着，我们将在 Azure DevOps 中创建一个新组织。我们在上一章中导入了一个名为 Tailwind Traders 的示例项目和组织。我们将在本章其余部分中使用这个示例。我们将使用 Tailwind Traders 项目创建一个新项目，并学习如何使用 Azure Boards 创建和管理不同的项目活动。
本章将涵盖以下内容：
-
理解过程和过程模板
-
创建一个组织
-
创建一个项目
-
创建和管理项目活动
技术要求
要跟随本章内容，你需要有一个有效的 Azure DevOps 组织。本章中我们将使用的组织是在第一章中创建的，名为Azure DevOps 概述。
理解过程和过程模板
使用 Azure Boards，你可以管理软件项目的工作。团队需要支持他们的工具，这些工具必须具有可扩展性和灵活性。这包括对 Scrum 和看板（Kanban）的原生支持，以及可定制的仪表板、集成报告能力和工具。
在项目开始时，团队必须决定使用哪种过程和过程模板来支持所采用的项目模型。过程和模板定义了 Azure Boards 中使用的工作项跟踪系统的基本构件。
Azure DevOps 支持以下流程：
- 基本：这是团队可以选择的最简单的模型。它使用史诗、问题和任务来跟踪工作。创建新基础项目时，这些工件会被创建，具体如下：
图 2.1 – 基本过程
- 敏捷：当你的团队使用敏捷计划过程时，选择敏捷。你可以跟踪不同类型的工作项，例如特性、用户故事和任务。这些工件是在使用敏捷流程创建新项目时生成的。开发和测试活动在这里是分开追踪的，敏捷使用看板（Kanban）来跟踪用户故事和缺陷。你也可以在任务看板上跟踪它们：
图 2.2 – 敏捷过程
- Scrum：当你的团队实践 Scrum 方法论时，选择 Scrum 流程。这将创建产品待办项（PBIs）、任务、缺陷以及更多的工件供团队使用。你可以使用看板跟踪工件，或者将 PBIs 和缺陷拆解为任务，在任务板上进行管理。Scrum 流程如下面的图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.03_B16392.jpg
图 2.3 – Scrum 流程
- CMMI：当你的团队遵循一个更正式的项目方法，需要一个框架来进行过程改进，并且需要可审计的决策记录时，能力成熟度模型集成（CMMI）流程更为适用。使用此流程模板，你可以跟踪需求、变更请求、风险和审查：
图 2.4 – CMMI 流程
现在我们已经介绍了有关 Azure DevOps 中不同流程和流程模板的一些基本信息，接下来将讲解如何创建一个新组织。
创建组织
在 Azure DevOps 中，组织用于连接相关项目组。你可以在这里规划和跟踪工作，并在开发应用时与他人协作。从组织级别，你还可以与其他服务集成，根据权限设置相应的权限，并设置持续集成和部署。
在上一章中，我们介绍了本书中使用的场景。Tailwind Traders 是一个示范零售公司，展示了智能应用体验的未来。通过使用 DevOps 生成器创建项目，组织和项目被自动创建。
然而，也有一些情况你可能需要手动创建组织，例如当你第一次在一个组织中使用 Azure DevOps 时，或者当基于权限要求创建一个独立的组织时。因此，我们也将涵盖这个步骤。请按以下步骤操作：
-
打开一个网页浏览器，访问
dev.azure.com/。 -
使用你的 Microsoft 账户登录，然后从左侧菜单点击新建组织：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.05_B16392.jpg
图 2.5 – 创建新组织
-
在向导中，给组织命名，例如
PacktLearnDevOps，并选择你希望托管项目的位置：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.06_B16392.jpg图 2.6 – 命名项目
-
点击继续。
到此，组织已创建。在下一节中，我们将学习如何将新项目添加到该组织。
创建项目
创建新组织后，Azure DevOps 会自动为你提供创建新项目的功能。请按以下步骤操作：
-
一旦您创建了新组织，创建项目的向导将自动显示。在这里，您可以指定项目的名称。在我的例子中，我将其命名为
LearnDevOps。 -
您还可以选择将您的项目设置为公开，让互联网的所有人都能查看，或者私密。如果选择后者，您需要手动授予用户访问权限。我们将在本演示中选择私密：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.07_B16392.jpg
图 2.7 – 创建新项目
-
点击 + 创建项目 来创建新项目。它将被添加到我们在前一步创建的组织中。
-
还有另一种创建新项目的方法。您也可以在不创建组织的情况下单独创建项目。在很多情况下，您可能希望向现有组织中添加一个新项目。为此，请点击左侧菜单中的组织名称。您将被重定向到组织的概览页面。在那里，点击右上角的 + 新建项目：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.08_B16392.jpg
图 2.8 – 向现有组织添加新项目
-
从这里开始，将显示用于创建新项目的相同向导。
我们已经介绍了如何创建一个新的组织并向其中添加项目。在本章的其余部分，我们将保持这个组织和项目不变，并使用我们在第一章**、Azure DevOps 概述中导入的 Tailwind Traders 项目。
在接下来的章节中，我们将介绍如何创建和管理不同的项目活动。
创建和管理项目活动
Azure DevOps 提供了不同的项目功能，团队可以利用这些功能来管理他们的软件开发项目，例如工作项、待办事项、冲刺、看板和查询。以下章节将介绍这些功能。
工作项
团队使用工作项来跟踪团队的所有工作。在这里，您将描述软件开发项目所需的内容。您可以跟踪功能和需求、代码缺陷或错误，以及其他所有项。可用的工作项取决于在创建项目时选择的流程。
工作项有三种不同的状态：新建、激活和关闭。在开发过程中，团队可以相应地更新这些项，以便每个人都能完整了解与项目相关的工作。
现在，让我们创建一个新的工作项。
创建新的工作项
从现在开始，我们将使用在前一章中生成的Tailwind Traders示例项目。我们将在这个项目中创建一个新的工作项。为此，请执行以下步骤：
-
打开一个网页浏览器并导航至
dev.azure.com/。 -
使用您的凭据登录。
-
导航到创建了 Tailwind Traders 项目的组织，并选择该项目，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.09_B16392.jpg
图 2.9 – 在 Azure DevOps 中选择 Tailwind Traders 项目
-
接下来，从左侧菜单选择 看板，然后选择 工作项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.10_B16392.jpg
图 2.10 – 导航到工作项
-
在下一个屏幕上，你将看到所有在创建 Tailwind Traders 项目时自动生成的工作项概览：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.11_B16392.jpg
图 2.11 – 所有示例工作项的概览
-
要创建一个新的工作项，请从顶部菜单点击 + 新建工作项。在那里，你将看到根据项目类型选择的不同工作项类型。对于 Tailwind Traders，使用的是敏捷类型（有关更多细节，请参见本章开头的 理解流程和流程模板 部分）：
图 2.12 – 工作项类型
现在，让我们创建一个新的用户故事。为此，从列表中点击 用户故事。然后，按照以下步骤操作：
-
一个新窗口将打开，你可以在其中为用户故事指定相关的值。请添加以下内容：
a) 标题：作为用户，我想编辑我的用户资料。
b) 分配：在这里，你可以将工作项分配给特定的人员。
c) 添加标签：你还可以向这个工作项添加标签。以后可以用这些标签进行搜索。我添加了一个名为 Profile Improvements 的标签。
d) 状态：因为这是一个新创建的项目，状态自动设置为 新建。
e) 迭代：在这里，你可以指定将此用户故事添加到哪个冲刺中。你也可以稍后从待办事项中进行此操作。我已将其添加到第 2 次迭代。
f) 描述：作为用户，我想编辑我的用户资料。这是一个富文本编辑器，你也可以根据需要格式化描述。
g) 讨论：在这里，你可以添加与此工作项相关的附加评论。你可以使用 “#” 后接“工作项名称”来链接到另一个工作项，使用 “!” 后接“拉取请求名称”来链接特定的拉取请求，或者使用 “@” 后接“人员名称”来提及某个人。
h) 优先级：在这里，你可以为你的用户故事设置优先级。这里的优先级仅是一个数字，用来表示工作项的重要性，而不是它的处理优先级。你可以通过拖动用户故事上下调整优先级。
i) 分类：你也可以对这个项目进行分类。生成器为 Tailwind Traders 项目创建了两个不同的类别。在这里，你可以选择 业务 或 架构。在这种情况下，该项目更偏向业务相关。
j) 开发：在这里，你可以将项目与特定的分支、构建、拉取请求等关联。
k) 故事点：使用故事点，你可以估算完成一个用户故事所需的工作量，可以使用任何数字单位进行度量。此字段中的值基于团队的工作速度：
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.13_B16392.jpg)
图 2.13 – 将项目与特定的开发流程关联
-
相关工作：你还可以将项目与其他项目或 GitHub 问题关联，如父子关系、已测试、重复项等：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.14_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.14_B16392.jpg)
图 2.14 – 将项目与相关工作关联
-
填写完这些字段后，点击屏幕右上角的保存按钮：
图 2.15 – 保存你的工作项
我们现在已经成功创建了一个新的工作项。我强烈建议你创建一些不同的工作项，比如缺陷、功能、任务等。这样，你将熟悉每种工作项表单的不同类型。
重要提示
有关如何创建不同工作项的更多信息，请参见以下网站：docs.microsoft.com/en-us/azure/devops/boards/work-items/about-work-items?view=azure-devops&tabs=agile-process。有关工作项表单中使用的不同字段的更多信息，请参阅此网站：docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/work-item-field?view=azure-devops。
在接下来的章节中，我们将更详细地了解待办事项和迭代。
待办事项
产品待办事项是团队计划交付内容的路线图。通过将用户故事、需求或待办事项添加到其中，你可以概览需要为项目开发的所有功能。
从待办事项中，工作项可以轻松地重新排序、优先级排序并添加到迭代中。
让我们来看一下待办事项是如何工作的：
-
在 Azure DevOps 中，再次打开Tailwind Traders项目。
-
接下来，从左侧菜单选择看板，然后选择待办事项。接着，选择Tailwind Traders 团队待办事项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.16_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.16_B16392.jpg)
图 2.16 – 导航至项目的待办事项
-
在这里，你将看到该项目的所有不同用户故事，包括我们在前一个演示中创建的那个。从右上角，你可以选择与项目模板一起提供的不同类型的工作项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.17_B16392.jpg
](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.17_B16392.jpg)
图 2.17 – 不同类型的工作项
-
目前，我们将继续使用用户故事视图。你也可以在这里重新排序和优先排序工作项。让我们通过将新创建的用户故事在列表中的第 2 和第 3 项之间拖动来重新优先排序它：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.18_B16392.jpg
-
从待办事项中，你还可以将工作项添加到不同的迭代中。在创建工作项时，我们将这个用户故事添加到迭代 2 中。从这里，如果我们想的话，也可以将此项拖动到其他迭代中：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.19_B16392.jpg
图 2.19 – 将用户故事拖到另一个迭代
-
你还可以更改视图，查看与这些用户故事相关的更多工作项。通过点击屏幕左侧显示的视图选项，你可以启用不同的视图。启用父项，该视图显示史诗和特性：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.20_B16392.jpg
图 2.20 – 显示父项
-
通过拖动不同类型的工作项，你还可以轻松创建不同类型的父子关系。例如，你可以将新创建的用户故事拖动到会员注册特性上，并在它们之间创建关系：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.21_B16392.jpg
图 2.21 – 创建父子关系
在本节中，我们介绍了待办事项和如何优先排序用户故事，以及如何将它们添加到迭代中。你还可以根据不同的工作项创建具有父子关系的视图。
在下一节中，我们将更详细地了解看板。
看板
查看不同工作项的另一种方式是使用看板。每个项目都带有一个预配置的看板，可以用来管理和可视化工作的流动。
这个看板有不同的列，代表不同的工作阶段。在这里，你可以全面了解所有需要完成的工作以及工作项的当前状态。
让我们更详细地了解 Azure DevOps 中的看板：
-
在左侧菜单中，选择看板，然后选择看板。在这里，你将看到不同工作项的概览，这些工作项已被添加到看板上的卡片中，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.22_B16392.jpg
图 2.22 – Tailwind Traders 看板概览
工作项根据项的状态进行显示。在新建列中，显示团队尚未承诺的项目。接下来，是当前正在由团队进行处理的项目，这些项目显示在进行中列。
还有一些工作项处于解决中状态，这意味着开发部分已经完成，但仍需进行测试。通过测试并符合完成定义的项目会被移到已关闭列。
-
在这里，你还可以将项目拖动到不同的列中，查看待办事项中的项目，并通过点击项目右上角的三个点（…）来对其进行更改，具体如下：
图 2.23 – 与看板互动
到这里，我们已经提供了一个关于看板的概述。在接下来的部分，我们将更详细地讨论迭代。
迭代
根据所选的项目模板，迭代的名称可能不同。在我们的 Tailwind Traders 项目中，使用的是敏捷项目模板。这将名称更改为迭代。然而，Azure DevOps 将这些视为与迭代相同的内容。
迭代或迭代用于将工作分割成特定数量的（通常是）周。这是基于团队可以处理的速度，也就是团队完成用户故事的速率。
让我们更详细地看一下 Azure DevOps 中的迭代视图：
-
从左侧菜单中，在看板下选择迭代。默认情况下，会显示待办事项视图。在这里，你将再次看到用户故事的概览，只不过这次是当前迭代的，具体如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.24_B16392.jpg
图 2.24 – 当前迭代的概览
你还可以将用户故事拖动到另一个迭代中，并在需要时重新排序它们。
-
通过点击顶部菜单中的任务板，你将看到与看板中工作项相似的不同视图。此时，当前迭代中的项目以待办任务级别显示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.25_B16392.jpg
图 2.25 – 看板中的迭代
-
在这里，你可以将项目拖动到不同的列中，必要时创建新的工作项，并筛选不同的迭代：
图 2.26 – 与迭代中的工作项互动
迭代看板主要在团队日常站会上使用。项目会根据团队的进展拖动到不同的列中。团队还会简要讨论这些项目，并在需要时请求帮助执行或创建它们。在迭代结束时，大多数项目将被移至已关闭列。
在这个演示中，我们查看了如何在 Azure 看板中管理和创建项目活动。在本章的最后一节中，我们将讨论 Azure DevOps 中的查询。
查询
你可以根据 Azure DevOps 中提供的筛选条件来过滤工作项。这样，你可以轻松查看所有处于特定类型、状态或具有特定标签的工作项。这可以在项目内部进行，也可以跨不同的项目进行。
要创建不同的查询并搜索工作项，请执行以下步骤：
-
从左侧菜单中，在Boards下选择Queries。然后，从顶部菜单中选择**+ 新建查询**：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.27_B16392.jpg
图 2.27 – 创建新查询
-
接下来，让我们创建一个查询，搜索具有Profile Improvements标签的用户故事。在查询屏幕上，选择下图所示的选项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.28_B16392.jpg
图 2.28 – 创建查询
-
然后，点击运行查询。结果将显示我们在本节第一步中创建的工作项：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_2.29_B16392.jpg
图 2.29 – 搜索结果
重要提示
这是一个可以创建的搜索查询的基本示例。如需更深入的信息，您可以参考docs.microsoft.com/en-us/azure/devops/project/search/overview?view=azure-devops。
这样，我们已经涵盖了如何运行查询以筛选工作项的基础知识。本章到此结束。
总结
在本章中，我们深入探讨了 Azure Boards。我们首先查看了根据组织采用的方法论可以选择的不同项目模板。根据该项目模板，创建了不同的工作项，这些工作项可用于项目规划。这些工作项可以添加到待办事项列表中，并可以创建关联关系，以便从逻辑上查看项目项。它们也可以添加到冲刺中。
在下一章中，我们将重点讲解 Azure DevOps 中的源代码管理。
进一步阅读
查看以下链接，获取有关本章所涵盖主题的更多信息：
-
什么是 Azure Boards？：
docs.microsoft.com/en-us/azure/devops/boards/get-started/what-is-azure-boards?view=azure-devops&tabs=agile-process -
选择一个流程：
docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process -
使用用户故事、问题、错误、功能和史诗跟踪工作：
docs.microsoft.com/en-us/azure/devops/boards/work-items/about-work-items?view=azure-devops&tabs=agile-process -
创建您的产品待办事项列表：
docs.microsoft.com/en-us/azure/devops/boards/backlogs/create-your-backlog?view=azure-devops&tabs=agile-process -
工作流状态和状态类别如何在待办事项和看板中使用：
docs.microsoft.com/en-us/azure/devops/boards/work-items/workflow-and-state-categories?view=azure-devops&tabs=agile-process
第二部分：源代码与构建
本节将介绍 Azure 构建以及如何在 Azure DevOps 中管理源代码。
本节包含以下章节：
-
第三章，使用 Azure DevOps 进行源代码管理
-
第四章，理解 Azure DevOps 管道
-
第五章，在构建管道中运行质量测试
-
第六章，托管你自己的 Azure Pipeline 代理
第三章：
第三章：使用 Azure DevOps 进行源代码管理
源代码管理 (SCM) 是每个专业从事软件开发的公司以及每个想要安全存储和管理代码的开发者不可或缺的一部分。
在团队合作时，绝对有必要拥有一个安全的中央仓库来存储所有代码。同时，还必须有一个系统来保证代码在开发者之间的安全共享，并且每一次修改都能够经过检查并合并，不会产生冲突。
在本章中，我们将学习 Azure DevOps 如何帮助你专业且安全地管理源代码。本章将涵盖以下内容：
-
理解源代码管理
-
分支策略概述
-
使用 Azure DevOps 和 Repos 处理源代码管理
-
如何处理提交、推送和分支
-
使用拉取请求
-
处理拉取请求
-
如何标记特定的代码发布
到本章结束时，你将了解所有可以应用 SCM 技术到你团队的概念，并且使用 Azure DevOps。
技术要求
要跟随本章内容，你需要在开发机器上安装一个有效的 Azure DevOps 组织和 Visual Studio 或 Visual Studio Code。
理解 SCM
源代码管理（或版本控制）是一种用于跟踪和管理源代码变化的软件实践。这是一个极为重要的实践，因为它可以确保不同开发人员之间维护同一份代码源，并有助于在单一软件项目中进行协作（即不同开发者在同一代码库上工作）。
SCM 是任何 DevOps 流程中的核心实践。要采用源代码管理策略，你应该做以下操作：
-
选择一个源代码管理系统来采用（例如，在服务器上安装 Git 或使用基于云的 SCM，如 Azure DevOps Repos 或 GitHub）
-
将你的代码库存储在由源代码管理系统管理的仓库中
-
通过获取中央仓库中存储的最新代码版本（拉取），将仓库克隆到本地进行开发
-
提交并推送你发布的代码到中央仓库
-
使用不同的仓库副本进行并行开发（分支）
以下是一个 SCM 流程的示意图：
图 3.1 – 源代码管理流程
Git 无疑是市场上最受欢迎的 SCM 系统之一。Git 由 Linus Torvalds 于 2005 年创建，用于帮助 Linux 内核的开发。Git 是免费的、开源的，并且完全基于文件，因此除了 Git 引擎本身，不需要额外的软件来处理 SCM。
Git 的工作流程可以总结如下（并可以使用之前的图示表示）：
-
你在 Git 托管系统中为你的项目创建一个仓库。
-
将仓库复制（或克隆）到你的本地开发机器上。
-
你在本地仓库中创建一个新文件，然后将更改保存在本地（暂存并提交）。
-
你将更改推送到远程仓库（push）。
-
你从远程仓库拉取更改到本地仓库（以便将代码与远程仓库同步，如果其他开发者做了修改的话）。
-
你将更改与本地仓库合并。
在使用 Git 作为 SCM 系统时，你需要记住一些关键概念：
-
快照是 Git 用来跟踪代码历史的方式。快照本质上记录了在某一时刻所有文件的样子。你决定何时以及对哪些文件进行快照。
-
提交是创建快照的行为。在一个项目中，你会创建不同的提交。一个提交包含三组信息：
– 详细描述文件如何从之前的版本发生变化
– 指向父提交的引用（之前发生的提交）
– 一个哈希代码名称
-
仓库是所有必要文件及其历史记录的集合。仓库可以位于本地计算机或远程服务器上。
-
克隆是从远程服务器复制仓库的操作。
-
拉取是从远程仓库下载本地没有的提交的过程。
-
推送是将本地更改添加到远程仓库的过程。
-
master。
Git 流程由以下操作组成：
图 3.2 – Git 流程
让我们来看一下 Git 中如何发生提交流。要在 Git 上创建一个提交，你需要对文件进行一些更改，然后使用 git add 命令将这些文件放入暂存环境。之后，使用 git commit 命令创建一个新的提交。这个流程可以表示如下：
图 3.3 – Git 提交
作为示例，这里是一些你可以使用的 Git 命令来激活前述 SCM 流程：
-
克隆远程仓库到本地：
git clone https://github.com/user/yourRemoteRepo.git -
继续进行项目开发。
-
将工作保存在本地：
git add . git commit -m "my commit message" -
检查远程服务器是否有更新：
git pull -
将工作保存到远程服务器：
git push
使用分支时，请遵循以下步骤：
-
创建一个新分支并切换到该分支：
git checkout -b "branch1" -
开发新功能。
-
将工作保存在本地：
git add . git commit -m "update from branch1" -
将工作保存到远程服务器：
git push -
切换到你想要合并工作的分支：
git checkout master -
将
branch1合并到master分支并将其保存到远程服务器：git merge branch1 git push
一旦你掌握了这些命令，你就可以开始使用 Git。在接下来的部分中，我们将概述分支和你可以使用的分支策略。
探索分支策略
分支是存储在 SCM 系统中的代码版本。在使用 Git 的 SCM 系统时，选择最适合你团队的分支策略至关重要，因为它有助于你保持可靠的代码库和快速交付。
在使用 SCM 时，如果你没有使用分支管理，你将始终只有一个版本的代码（master分支），并且你总是向这个分支提交代码：
图 3.4 – 单一工作流
这种“单一工作流”方式不推荐使用，因为它无法保证master分支的稳定性，特别是当多个开发人员在同一代码上工作时。
有许多不同的分支工作流（策略），你可以为团队选择采用，通常我建议从简单的策略开始。在 Git 中，你可以采用三种主要的分支策略：
-
GitHub 流
-
GitLab Flow
-
Git Flow
在接下来的章节中，我们将探讨这些策略的每一个。
GitHub 流
GitHub Flow 是最广泛使用的分支策略之一，并且相对容易采用。
根据此工作流程，你从master分支开始（该分支始终包含可部署的代码）。当你开始开发新功能时，你会创建一个新的分支，并定期向此分支提交代码。当开发工作完成时，你会创建一个 pull 请求，将该子分支与master分支合并：
图 3.5 – GitHub Flow
这个工作流简单易于采用，适用于你需要在生产环境中维护单一版本的代码。唯一的缺点是你需要仔细检查提交到master分支的内容。如果你需要在生产环境中维护多个版本的应用程序，通常不推荐使用这种方式。
GitLab 流
GitLab Flow 是另一种流行的分支策略，广泛应用，尤其是在你需要支持多个环境（例如生产、预发布、开发等）时，特别适用于 SCM 流程。以下图示表示该工作流：
图 3.6 – GitLab Flow
根据此工作流程，你应该至少有三个分支：
-
主分支：这是每个人的本地版本代码。
-
预发布：这是用于测试目的的分支，master分支会被分叉到这里。
-
生产：这是已发布的生产代码（预发布已经合并到这里）。
如果你想保持稳定的生产发布，并分别在新功能上工作（这些功能可以移至测试环境进行测试），然后在测试完成后将该环境合并到生产发布中，这种工作流非常有用。
Git Flow
Git Flow 是一种用于有定期发布周期的工作流。以下图示表示该工作流：
图 3.7 – Git Flow
根据此工作流程，你有一个master分支和一个develop分支，它们始终处于活动状态，另外一些分支并非总是处于活动状态（可以删除）。master分支包含已发布的代码，而develop分支包含你正在开发的代码。
每次向你的代码库添加新功能时，你会从develop分支创建一个feature分支，然后当实现完成时，将feature分支合并到develop。在这里，你永远不会合并到master分支。
当你需要发布一组功能时，你会从develop分支创建一个发布分支。release分支中的代码必须经过测试（可能包含合并的 bug 修复），当你准备好发布代码时，你将release分支合并到master分支，然后再合并到develop分支。
如果在生产中出现严重 bug，此流程建议你可以从master分支创建一个fix分支，修复 bug，然后直接将此分支合并回master。如果存在release分支，你也可以将其合并到release分支，否则合并到develop分支。如果你将代码合并到release分支，当你将release分支合并回develop分支时，develop分支将包含修复。
处理 Azure DevOps 中的源代码控制
Azure DevOps 支持以下源代码管理类型：
-
Git：这是一个分布式版本控制系统，在创建新项目时是 Azure DevOps 的默认版本控制提供程序。
-
Team Foundation Version Control (TFVC)：这是一个集中式版本控制系统，在这里开发者本地只有一个文件版本，数据存储在服务器上，并且分支是在服务器上创建的（基于路径）。
使用 Azure DevOps 的第一步是在你的组织内创建一个新项目。当你使用 Azure DevOps 创建新项目时，系统会提示你选择要使用的版本控制系统（如下截图中的红框所示）：
图 3.8 – 创建新项目
点击确定按钮，新项目将在你的 Azure DevOps 组织中创建。
项目创建完成后，你可以通过进入 Azure DevOps 左侧导航栏中的仓库中心来管理你的存储库（见下面的截图）。这里是你的文件存储位置，你可以开始创建存储库并管理分支、拉取请求等等：
图 3.9 – 仓库
从仓库开始，每个开发者都可以在本地克隆存储库，并直接从 Visual Studio 或 Visual Studio Code 进行工作，同时连接到 Azure DevOps，以便推送代码修改、拉取和创建分支、进行提交，并发起拉取请求。
当你从头开始启动一个新项目时，Azure DevOps 会为你创建一个空的存储库。你可以手动将代码加载到这个存储库中（通过上传），或者你可以从远程存储库（例如 GitHub）克隆到 Azure DevOps。
在一个项目中，你可以创建不同的仓库，每个仓库都有自己的权限、分支和提交记录。要创建新仓库，只需选择 Repos 中心并点击 New repository，如下一张截图所示：
图 3.10 – 新仓库
仓库可以从 Azure DevOps 中轻松重命名或删除。
在本节中，我们学习了如何在 Azure DevOps 中创建新项目以及如何为你的项目创建代码仓库。
在接下来的章节中，我们将学习如何使用 Azure DevOps 管理完整的源代码管理流程，从克隆远程仓库到提交代码。
克隆远程仓库
为了展示如何在 Azure DevOps 中使用代码仓库，我将从一个包含我 Web 应用源代码的 Git 仓库项目开始。下图显示了托管在 master 分支上的远程代码：
图 3.11 – 主分支
每个必须使用此代码的开发人员都需要在本地克隆该仓库。你可以点击 Clone 按钮，如下图所示：
图 3.12 – 克隆仓库
从这里，你将看到一个显示克隆仓库 URL 的窗口。你可以使用 git clone <Repository URL> 命令来克隆这个仓库，或者通过在 Visual Studio 或 Visual Studio Code 中选择下方截图中显示的选项来直接克隆：
图 3.13 – 克隆选项
在这里，我正在将项目克隆到 Visual Studio Code。Azure DevOps 会提示我选择一个文件夹来保存该项目（开发机器上的本地文件夹），然后打开 Visual Studio Code 并开始克隆远程仓库：
图 3.14 – 在 Visual Studio Code 中克隆
在 Visual Studio Code 中，你也可以通过打开命令面板（Ctrl + Shift + P），选择 Git:Clone 命令，然后将仓库 URL 粘贴到提示窗口中来克隆仓库：
图 3.15 – Git:Clone 命令
一旦克隆过程完成，你将会在选定的文件夹中拥有远程仓库 master 分支的本地副本：
图 3.16 – 远程仓库的本地副本
为了更高效地使用 Visual Studio Code 与 Azure DevOps 上的远程仓库工作，我建议你安装一个名为 Azure Repos 的扩展（来自 Visual Studio Code 市场）：
图 3.17 – Azure Repos 扩展
一旦 Azure Repos 安装完成，如果你进入命令面板并搜索 teams，你将看到一组新的可用命令来与 Azure DevOps 进行交互，如下所示：
图 3.18 – Azure Repos 命令
在本章的后续部分，我们将使用其中的一些命令。
在下一节中，我们将学习如何将 GitHub 仓库导入到 Azure DevOps。
将 GitHub 仓库导入到 Azure DevOps
使用 Azure DevOps，你还可以在 Repos 中导入 GitHub 仓库。如果你选择了一个在 Azure DevOps 项目中创建的空仓库，你将可以看到导入仓库的选项，如以下截图所示：
图 1.19 – 导入一个仓库
在这里，你可以选择要导入的 GitHub 仓库（通过输入源类型和 GitHub 仓库的克隆 URL）：
图 1.20 – 导入 Git 仓库
当你点击 导入 按钮时，远程 GitHub 仓库的导入过程将开始，你将看到显示进度的图像：
图 3.21 – 正在处理导入仓库请求
一旦导入过程完成，你将在 Azure Repos 中获得代码。请记住，当从 GitHub 导入仓库时，历史记录和修订信息也会被导入到 Azure DevOps 中，以实现完整的可追溯性：
图 3.22 – 导入的仓库历史
使用提交、推送和分支
一旦你将远程仓库克隆到本地 Git 仓库，你就可以开始编码（创建新文件或修改现有文件）。
每次你创建或修改一个文件时，Git 会记录本地仓库中的更改。你会看到 Visual Studio Code 的源代码控制图标开始提示文件已被修改。例如，在下面的截图中，我向项目中的一个文件添加了评论。保存文件后，Git 引擎会提示我有一个未提交的文件：
图 3.23 – 未提交文件警告
如果你点击左侧栏中的 源代码控制 图标，你将看到未提交的文件。在这里，你可以选择你想提交的更改并将其暂存。每次提交都是在本地进行的。你可以通过点击 + 图标来暂存修改，然后通过点击顶部工具栏中的 提交 按钮来提交所有暂存的文件。每次提交都必须有一条信息，解释这次提交的原因：
图 3.24 – 提交信息
现在，文件已经本地提交到你的本地 master 分支（虽然不推荐这样做，稍后会解释）。要将这些修改同步到 Azure DevOps 中的线上仓库，你可以点击 Visual Studio Code 底部栏上的 Synchronize Changes 按钮（这会以红色高亮显示，表明你有需要推送到线上的修改），如下图所示：
图 3.25 – 需要推送到线上修改
另外，你可以从命令栏选择 Git : push 命令，如下所示：
图 3.26 – Git:Push 命令
现在，所有代码修改都已经推送到 master 分支。如果你进入 Azure DevOps 的 Repos 中心并选择 Commits 菜单，你将看到所选分支的每一次提交历史：
图 3.27 – 提交历史
这样，我们直接在 master 分支上工作。这不是实际开发团队中常用的工作方式，因为如果每个开发者都直接提交到 master 分支，就无法保证该分支始终稳定。最好的做法是使用之前提到的 GitHub Flow。因此，你应该创建一个新分支，在这个新分支上工作，只有在工作完成后，才创建一个 pull 请求将分支合并到 master 分支。
你可以在 Azure DevOps 中或直接在 Visual Studio Code 中创建新分支。创建新分支的步骤如下：
-
从 Azure DevOps 中选择 Branches，然后点击 New branch：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_3.28_B16392.jpg
图 3.28 – 新分支
-
然后，提供一个分支名称。你需要选择新分支将从哪个分支创建，如下图所示：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_3.29_B16392.jpg
图 3.29 – 创建分支
要直接从 Visual Studio Code 创建新分支，只需点击底部栏上的分支名称，然后选择 Create new branch…：
图 3.30 – 在 Visual Studio Code 中创建新分支…选项
-
现在，选择新分支的名称（这里称为
development）：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_3.31_B16392.jpg图 1.31 – 分配分支名称
这样，分支将被创建在本地仓库中，Visual Studio Code 将自动开始在该分支上工作：
图 3.32 – 在新分支上工作
-
现在，您可以在此新分支上继续进行代码开发（可能是为了开发一组新的功能），并进行提交，而不会影响
master分支（它将继续保持代码库的实际发布版本）。例如，在这里，我已向
MedicineController.cs文件添加了一个新的修改。我可以在本地对development分支进行暂存和提交此修改：图 3.33 – 暂存更改
-
然后，我可以将这些修改推送到 Azure DevOps 上的远程仓库。当在线推送时，如果这是第一次创建 development 分支，您将收到如下消息：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_3.34_B16392.jpg
图 3.34 – 自动分支创建和发布
-
完成后，development 分支将在远程仓库中创建，并且您的代码将被推送到线上：https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/az-dop-expl/img/Figure_3.35_B16392.jpg
图 3.35 – 在远程仓库上创建的分支
-
如果您在 Azure DevOps 中的 Repos 中进入 Commits 部分，您将看到提交历史记录。通过选择特定的提交，您可以查看所做的文件更改（通过将之前的版本与该提交后的当前版本进行比较）：
图 3.36 – 提交的详细信息
这个操作也可以通过 Visual Studio Code 中的 Team:View History 命令直接完成：
图 3.37 – 来自 Visual Studio Code 的 Team:View History 命令
分支可以被删除（手动删除或在拉取请求后自动删除）、从意外删除中恢复，还可以被锁定（使其进入只读状态，或防止此分支上的新提交影响当前合并）。要锁定特定分支，只需在 Azure DevOps 中选择该分支，然后从菜单中选择 Lock 选项：
图 3.38 – 锁定分支
要解锁已锁定的分支，只需选择 Unlock 操作。需要注意的是，锁定分支并不妨碍克隆或拉取此分支到本地。
通过策略保护分支
在与不同的开发人员协作并使用分支时，保护仓库中关键的分支（例如 master 分支）非常重要，可以通过规则确保这些分支始终保持健康状态。
对于这个范围，Azure DevOps 允许您为关键分支指定一组策略。
Azure DevOps 中的分支策略允许您执行以下操作：
-
限制特定分支的贡献者
-
指定谁可以创建分支
-
为分支指定一组命名约定
-
自动为分支中的每个代码更改包括代码审阅者
-
强制使用拉取请求
-
在提交代码到分支之前启动构建管道
要为特定分支指定分支策略，请转到 Azure DevOps 中的分支部分，选择您的分支，然后选择分支策略菜单：
图 3.39 – 分支策略
在这里，您可以设置一组选项来控制所选分支。我们将在以下部分详细查看这些选项。
要求最少审阅者数量
该选项允许您指定可以批准代码修改的审阅者数量。如果任何审阅者拒绝代码更改，则修改不会被批准，且代码更改会被丢弃。如果选择允许即使一些审阅者选择等待或拒绝也可以完成，那么拉取请求可以完成。请求者可以批准自己的更改选项允许拉取请求的创建者批准自己的代码更改：
图 3.40 – 要求最少审阅者数量选项
检查关联的工作项
该选项允许您要求将工作项与特定拉取请求关联，以便实现活动和任务的完整可追溯性。如果您使用的是项目规划功能（如本书中的第二章《使用 Azure DevOps Boards 管理项目》所示），这将非常有用：
图 3.41 – 检查关联的工作项选项
检查评论解决情况
该选项允许您指定一条规则，要求所有评论必须解决，才能执行拉取请求：
图 3.42 – 检查评论解决选项
限制合并类型
该选项允许您在完成拉取请求时强制执行分支策略。可用的选项如下：
-
基本合并（无快速转发）：此选项合并源分支的提交历史，并在目标分支中创建一个合并提交。开发过程中发生的完整非线性提交历史将被保留。
-
Squash 合并：通过压缩源分支的提交（线性历史），在目标分支中创建一个单一提交。
-
master分支。拉取请求中的每个提交都将单独合并到目标分支中（线性历史）。 -
使用合并提交的变基：通过将源分支的提交替换为目标分支中的提交，然后创建合并提交，从而创建半线性历史。
所有这些选项可以在以下屏幕截图中查看：
图 3.43 – 限制合并类型选项
构建验证
本节允许您为构建代码指定一组规则，在拉取请求完成之前（有助于及早发现问题）。点击 添加构建策略 后，将出现一个新面板：
图 3.44 – 添加构建策略
在这里，您可以指定要应用的构建管道定义，以及它是否必须在分支更新时自动触发，或者手动触发。我们将在 第四章*，理解 Azure DevOps Pipelines* 中详细讨论构建管道。
需要额外服务的批准
该选项允许您连接外部服务（通过 Azure DevOps 拉取请求 API），以便参与拉取请求流程：
图 3.45 – 添加状态策略
自动包含代码审查者
此策略允许您将特定用户或组包含在代码审查过程中：
图 3.46 – 添加自动审查者
跨仓库策略
不必为每个您手动创建的分支定义一个策略，Azure DevOps 允许您定义跨仓库策略（这些策略将自动应用于您为项目创建的所有分支）。
要定义一个适用于您将创建的每个仓库的策略，您需要进入 项目设置，然后选择 跨仓库策略，如下面的截图所示：
图 3.47 – 跨仓库策略
在这里，您可以添加一个分支保护策略并选择以下选项之一：
-
master分支的每个仓库）。 -
保护当前和未来匹配指定模式的分支。在这里，您可以定义一个过滤分支的模式，策略将应用于所有符合该模式的分支。
举个例子，如果您想定义一个策略，该策略将自动应用于您为项目创建的所有分支，请按以下步骤操作：
图 3.48 – 添加分支保护
如您所见，在这里，我们选择了 *** key 作为模式来识别我们项目中的所有分支。
使用拉取请求
拉取请求 允许您通知团队成员，表明一个新实现已完成并必须与指定的分支合并。通过使用拉取请求，团队成员可以审查您的代码（逐步查看文件并查看特定提交所做的修改），对小问题提供审查评论，并批准或拒绝这些修改。这是使用 Azure DevOps 进行源代码管理时推荐的做法。
你可以通过选择 Repos 中心的 拉取请求 菜单，查看 Azure DevOps 中特定仓库的所有传入拉取请求，如下图所示：
图 3.49 – 拉取请求视图
你还可以筛选此列表，仅查看你的拉取请求，或仅查看 Active、Completed 或 Abandoned 状态的拉取请求。
拉取请求可以通过以下几种方式创建：
-
手动从 Azure DevOps 拉取请求页面创建
-
从与分支关联的工作项（开发标签）
-
当你向功能分支推送更新时
-
从 Visual Studio Code 或 Visual Studio 直接启动
-
从 Azure DevOps Services CLI 启动
在接下来的章节中，我们将学习如何在这些情况下启动拉取请求。
从 Azure DevOps 拉取请求页面创建拉取请求
你可以直接从 Azure DevOps 拉取请求菜单（位于 Repos 中心）创建一个新的拉取请求。在这里，只需点击 新建拉取请求 按钮：
图 3.50 – 新建拉取请求
你现在可以输入关于你希望创建的拉取请求的详细信息（我们将在本章后面讨论这一部分）。
从工作项创建拉取请求
在你团队的工作项 待办事项 视图中，你可以选择一个与分支关联的工作项（一个与分支提交关联的工作项），进入所选工作项的 开发 区域，并创建一个 创建拉取请求 操作：
图 3.51 – 从工作项创建拉取请求
在推送分支后创建拉取请求
当你将代码提交到 Azure DevOps 的 development（次级）分支时，系统会自动提示你创建一个拉取请求（你可以通过转到 文件 或 拉取请求 菜单，在 Repos 中心查看此提示）。如你所知，我之前将新代码提交到了名为 development 的分支。现在，如果我们进入 文件 | 历史记录 部分，我们会看到创建新拉取请求的提示：
图 3.52 – 在分支上提交后创建拉取请求
从 Visual Studio Code 或 Visual Studio 创建拉取请求
你可以直接从 Visual Studio Code 或 Visual Studio 启动拉取请求，只要你的项目已经加载。
要从 Visual Studio Code 启动拉取请求，请从命令面板中启动 Team:Create pull request 命令（Ctrl + Shift + P）：
图 3.53 – 从 Visual Studio Code 创建拉取请求
这将提示你打开 Azure DevOps。确认后，拉取请求窗口将会打开。
在 Visual Studio 中，选择 Team Explorer 面板。从这里，你可以点击 Pull Requests 来开始一个拉取请求：
图 3.54 – 从 Visual Studio 创建拉取请求
处理拉取请求
我们描述的处理拉取请求的所有不同方法汇聚到一个唯一的点：在 Azure DevOps 中，Pull requests 窗口会打开，你需要填写你的拉取请求活动的详细信息。举个例子，这是我们在 development 分支上进行上次提交后开始的拉取请求：
图 3.55 – 新建拉取请求窗口
在这里，你可以立即看到拉取请求将一个分支合并到另一个分支（在我的例子中，development 将被合并到 master）。你需要提供这个拉取请求的标题和描述（清晰地描述你在合并过程中所做的更改和实现），并附上链接以及添加将负责审查此拉取请求的团队成员（用户或组）。你还可以包括工作项（如果你之前已完成与工作项相关的提交，系统会自动包含这个选项）。
在 Files 部分，你可以看到此拉取请求将在目标分支中做什么（每个文件）。举个例子，这就是我的拉取请求展示的内容：
图 3.56 – 拉取请求中的代码修改视图
在左边，你可以看到在 master 分支中提交的文件，而在右边，你可以看到合并阶段后的同一文件（显示了每个修改的详细信息）。
如果你指定了一些审阅者，他们将看到代码修改的详细信息，这意味着他们可以添加评论并与开发人员进行互动。
要创建拉取请求流程，只需点击 Create 按钮。
一旦拉取请求创建完成，你可以通过点击拉取请求窗口右上角的 Complete 按钮来完成拉取请求（你可以在可选的批准阶段之后以及通过分支规则后进行此操作）：
图 3.57 – 完成拉取请求
在这里，你可以执行以下操作：
-
完成 拉取请求。
-
标记为草稿：这就像是“进行中的工作”。如果拉取请求被标记为草稿，所需的审阅者不会自动添加，投票也不被允许，如果启用了构建策略，它们不会自动执行。
-
放弃：拉取请求将被关闭，你的代码不会被合并。
当你点击 Complete 时，你会被提示填写 Complete pull request 窗口，内容如下：
图 3.58 – 完成拉取请求
在这里，你可以插入合并操作的标题和描述，选择应用的合并类型，并选择完成后操作（如果关联的工作项应该在合并后标记为已完成，以及合并操作后是否必须删除源分支）。
关于要应用的合并操作类型，你可以从以下选项中选择：
-
合并（无快进）：保留所有提交的非线性历史
-
Squash 提交：仅在目标上保留一个提交的线性历史
-
变基和快进：将源提交变基到目标，并进行快进合并
-
半线性合并：将源提交变基到目标，并创建一个双父合并
Azure DevOps 为你提供了一个漂亮的动画图表，以显示合并的最终结果。要完成拉取请求，点击完成合并。如果发生任何合并冲突，你需要先解决它们。这样，合并阶段就开始了：
图 3.59 – 完成拉取请求。
如果目标分支（这里是master分支）上有自动构建策略，构建管道会被执行，然后完成合并操作：
图 3.60 – 拉取请求已完成
在下一部分中，我们将学习如何在分支上使用标签，以便立即识别代码库中的代码状态。
标记发布
Git 标签是指向 Git 历史中特定点的引用。标签在 Azure DevOps 中用于标记特定的发布（或分支），并用一个标识符共享给团队内部，以便识别，例如，你的代码库的“版本”。
作为例子，在前面的章节中，我们使用 master 分支将 development 分支合并到 master 分支，master 分支包含我们最新的代码发布，现在我们准备好在内部共享它。
要在分支上使用标签，在 Azure DevOps 中的Repos中心，进入标签菜单：
图 3.61 – 标签
从这里，你可以通过进入标签并点击新建标签来为此次发布创建标签。
在这里，你将被提示插入一个标签名称（一个不能包含空格的标识符），为此标签提供描述，并选择标签将应用于的分支：
图 3.62 – 创建标签
当你点击创建时，标签将应用到你的分支上：
图 3.63 – 标签应用于分支
总结
在本章中，我们学习了如何使用 Azure DevOps 处理源代码管理，以及在团队开发代码时它为何如此重要。
我们了解了源代码管理和 Git 的基本概念，合并代码时可能应用的策略，如何使用 Azure DevOps 来应用 SCM，以及如何通过 Azure DevOps 和开发工具（如 Visual Studio Code 和 Visual Studio）来处理仓库、提交、分支和拉取请求。我们还学习了如何应用更好的策略来控制源代码发布，以便改进 SCM 生命周期，如何保护分支，以及如何为分支使用标签。
在下一章，我们将学习如何使用 Azure DevOps 创建构建管道，以实施 CI/CD 实践。
第四章：
第四章：了解 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 流程有很多好处。主要好处如下：
-
提高代码质量和早期发现漏洞：通过采用自动化测试，您可以在早期发现漏洞和问题，并进行修复。
-
完整的可追溯性：整个构建、测试和部署过程都被跟踪，并且可以稍后进行分析。这确保您可以检查特定构建中的哪些更改被包含，并了解这些更改对最终测试或发布的影响。
-
更快的测试和发布阶段：自动化每次新提交（或发布前）的代码库构建和测试。
在下一节中，我们将概述 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 Container Registry 或 Kubernetes。
要使用 Azure Pipelines，您需要以下内容：
-
在 Azure DevOps 中的组织，您可以创建公开或私有项目
-
存储在版本控制系统中的源代码（如 Azure DevOps Repos 或 GitHub）
Azure Pipelines 使用以下架构：
图 4.2 – Azure Pipelines 架构
当您的代码提交到仓库中的特定分支时，构建管道引擎启动，构建和测试任务执行，如果一切顺利完成，您的应用程序将被构建，您将得到最终输出（工件）。您还可以创建一个发布管道，将构建的输出发布到目标环境（预发布或生产）。
要开始使用 Azure Pipelines，您需要创建一个管道。Azure DevOps 中的管道可以通过以下两种方式创建：
-
使用经典界面：这允许您从可能的任务列表中可视化选择一些任务，您只需填写这些任务的参数。
-
使用名为 YAML 的脚本语言：可以通过在仓库中创建一个 YAML 文件，定义所有需要的步骤来定义管道。
使用经典界面初始阶段可能更简单，但请记住，许多功能仅在 YAML 管道中可用。YAML 管道定义是一个文件，这个文件可以像仓库中的其他文件一样进行版本控制和管理。您可以轻松地在项目之间迁移管道定义（这在经典界面中是不可能的）。
Azure Pipelines 可以表示为如下所示（感谢 Microsoft 提供）：
图 4.3 – Azure Pipelines 的表示
一个管道从触发器开始（手动触发、仓库中的推送、拉取请求或计划任务）。管道通常由一个或多个阶段组成（管道中的逻辑分离，例如构建、测试、部署等；它们可以并行运行），每个阶段包含一个或多个作业（一组步骤，这些步骤也可以并行运行）。每个管道至少包含一个阶段，除非您明确创建了多个阶段。每个作业在代理上运行（执行作业的服务或软件）。每个步骤由任务组成，任务对代码执行某些操作（按顺序执行）。管道的最终输出是一个工件（构建发布的文件或包的集合）。
创建管道时，您需要定义一组作业和任务，以自动化您的构建（或多阶段构建）。您可以获得对测试集成、发布门、自动报告等的原生支持。
当在管道中定义多个作业时，这些作业是并行执行的。包含多个作业的管道被称为扇出场景：
图 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 平台上以管理员用户身份运行，在 Linux 平台上以无密码的 sudo 用户身份运行。
-
对于公共项目，你可以获得 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）。你需要在代理机器上运行这个包（config.cmd）（可以是 Azure 虚拟机或你的本地服务器，它将作为你构建的代理程序）：
图 4.11 – 代理软件包
安装程序会询问你以下内容：
-
你的 Azure DevOps 组织的 URL (
dev.azure.com/{your-organization}) -
要使用的个人访问令牌（之前创建的）
在运行代理程序时（无论是交互式还是作为服务），如果你希望自动化构建，推荐以服务的方式运行它。
在插入这些参数后，安装程序会注册代理程序：
图 4.12 – 代理注册
要注册代理程序，你需要插入代理池、代理名称和工作文件夹（你可以保持默认值不变）。
最后，你需要决定你的代理程序是必须以交互式方式执行，还是作为服务运行。正如我们之前提到的，推荐以服务的方式运行代理程序，但在很多情况下，交互式选项会很有帮助，因为它可以为你提供一个控制台，你可以在其中查看状态和运行中的 UI 测试。
在这两种情况下，请注意你为运行代理程序选择的用户帐户。默认帐户是内建的网络服务用户，但这个用户通常没有本地文件夹所需的所有权限。使用管理员帐户可以帮助你解决很多问题。
如果安装成功，你应该能在代理机器上看到一个正在运行的服务，并且在 Azure DevOps 的代理池中弹出一个新代理：
4.13 – 新代理已创建
如果你选择了代理程序，然后进入功能部分，你将能够看到它的所有功能（操作系统版本、操作系统架构、计算机名称、安装的软件等）：
图 4.14 – 代理功能
代理的能力可以由代理软件自动发现，也可以通过你（用户自定义的能力）添加，如果你点击添加新能力操作。能力用于管道引擎，根据管道所需的能力（需求）将特定的构建重定向到正确的代理。
当代理在线时，它已准备好接受你的代码构建，该构建应该排队等待。
请记住，你也可以在同一台机器上安装多个代理（例如，如果你希望执行核心管道或并行处理作业），但仅在代理不会共享资源的情况下推荐这种方案。
何时使用 Microsoft 托管代理或自托管代理
当你有一个标准的代码库并且不需要特定的软件或环境配置来构建代码时，Microsoft 托管的代理通常很有用。如果你处于这种情况，推荐使用 Microsoft 托管的代理，因为你不必担心创建环境。例如，如果你需要构建一个 Azure Function 项目，通常情况下，你不需要在构建代理上安装自定义软件，Microsoft 托管的代理可以完美工作。
当你需要特定的环境配置，或者需要在代理上安装特定的软件或工具，或者需要更多的构建计算能力时，自托管代理是最佳选择。自托管代理也是当你需要在每次构建运行之间保持环境一致时的首选。当你需要更好地控制代理或希望将构建部署到本地环境（外部无法访问）时，自托管代理通常是正确的选择。它也通常能帮你节省成本。
现在我们已经讨论了可以用于构建管道的可能构建代理，在接下来的部分中，我们将概述 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
复杂对象定义
作为如何在 YAML 中定义复杂对象的示例，以下是用于表示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 企业服务器、Subversion、TFVC、Bitbucket Cloud 或 其他 Git）以及构建管道将连接的分支：
图 4.17 – 经典编辑器管道定义
然后，您需要选择正在构建的应用程序类型的模板。您有一组预定义的模板可供选择（稍后可以自定义），但您也可以从空模板开始：
图 4.18 – 管道模板选择
如果预定义的模板符合您的需求，您可以开始使用它们；否则，建议通过选择您需要的操作来创建自定义管道。
在这里，我的应用程序存储在 Azure DevOps 项目存储库中，是一个 ASP.NET Web 应用程序（名为PartsUnlimited的电子商务网站项目；您可以在以下 URL 找到公共存储库：github.com/Microsoft/PartsUnlimited），因此我选择了 ASP.NET 模板。
当选择时，这是将自动为您创建的管道模板：
图 4.19 – 从模板创建的管道
让我们详细检查管道的每个部分。
管道（这里称为PartsUnlimited-demo-pipeline）在 Microsoft 托管的代理（Azure 管道代理池）上运行，基于vs2017-win2016模板（Windows Server 2016 与 Visual Studio 2017），如下截图所示：
图 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/en-us/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
作为创建多阶段流水线的示例，假设我们有一个流水线，它使用 .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/en-us/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 函数项目的存储库。正如您所见，Azure Pipelines 已识别出我的项目，并为管道提供了一组可用模板（但您也可以从空白模板或存储库任何分支中的 YAML 文件开始）。在这里，我将选择
azure-pipelines.yml) 在您的 GitHub 存储库内：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 – 状态徽章定义
-
从这里，您可以复制
Readme.md文件到您的 GitHub 存储库中：
图 4.52 – 构建状态徽章 markdown
每当用户访问您的存储库时，他们将能够通过图形徽章看到最新构建的状态：
图 4.53 – 构建管道状态徽章
接下来，让我们看看如何并行执行作业。
在 Azure Pipeline 中并行执行作业
在 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 创建 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 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 容器实例中创建构建代理，并如何使用容器的作业。
在下一章，我们将学习如何在构建流水线中执行代码库的质量测试。
扫一扫
88
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
