十八、Azure DevOps 的 CI/CD

持续集成(CI)和持续交付(CD)是两个深深植根于敏捷项目生命周期定义中的概念。 在敏捷方法中，DevOps 的工作主要花在减少 CD 周期上，以便可以定期向用户交付更小的 sprint 和更小的变更集。 反过来，变更越小，风险就越小，对用户来说就越容易采用。 为了最小化交付周期的长度，自动化的交付管道是至关重要的。 使用 Azure DevOps 提供的工具集，开发人员可以为构建、测试和部署创建完全自动化的模板。 在本章中，我们将为 Xamarin 建立与 Azure 部署管道一致的构建和发布管道。

在这一章中，我们将主要讨论如何使用 Azure DevOps 提供的工具集实现适当的应用生命周期和自动交付管道。 我们将简要介绍一下使用 Azure DevOps 的 CI/CD，以及如何使用 Git 和 GitFlow 作为分支策略来实现 CI/CD。 然后，我们将继续讨论使用自动化工具交付应用的质量保证。 最后，我们将使用发布模板发布应用包的 web 后端和我们的移动应用。 下面的主题将指导你了解这些 DevOps 概念:

• 引入 CI / CD
• 与 GitFlow CI / CD
• 分支机构的质量保证(QA
• 创建和使用发布模板

在本章结束时，您将能够使用 Azure DevOps 提供的固有工具集为您的 web 和移动应用建立一个适当的交付管道。

引入 CI/CD

让我们从 CI 和 CD 管道开始这一章。 在本节中，我们将重点关注正确设置开发和交付管道的基本概念。

在前面的章节中，我们设置了各种构建定义，以创建可以用作部署构件的应用二进制文件和包。 在准备这些工件时，我们实现了可以包含在自动化构建定义中的自动化测试。 每次团队成员引入版本控制变更时，自动化代码构建和测试的过程通常被称为 CI。 CI，加上一个成熟的版本控制系统和一个定义良好的分支策略，是鼓励开发人员在提交时更加大胆和敏捷的主要因素，有助于提高发布的节奏。

另一方面，CD 是构建、测试和配置应用的(通常)自动化过程，最后将应用的特定版本部署到登台环境中。 通常使用多个测试或登台环境，并自动创建基础设施和部署，直到生产阶段。 在一个健康的 CD 管道中，连续环境集的成功是通过集成、负载和用户验收测试等运行时间越来越长的活动来度量的。 CI 启动 CD 过程，管道在成功完成前一轮测试后对每个后续环境进行分级。

在 CD 中，发布定义由一系列环境组成。 环境是一个逻辑容器，它表示希望将应用部署在何处。 在物理上，环境可以指服务器集群、云基础设施上的资源组或移动应用分发环。 每个环境(有时被称为阶段)都有其目的，开发管道中的一部分涉众被分配为该特定环境的所有者:

图 18.1 -应用开发生命周期

每个环境的 web 服务和移动应用的配置可能因特定环境的目的而不同。 尽管如此，重要的是要记住，环境应该在 CI/CD 管道中的任何一点上托管相同的应用发布版本和二进制文件。 通过这种方式，我们可以确保，一旦应用被提升到更高的环境(即更接近生产环境)，它将像在前一个阶段那样工作。

正如您所看到的，在 DevOps 术语中，部署并不总是意味着发布或生产。 作为 CD 的一部分，开发团队的提交会触发各种部署管道。 如果提交的代码经过单元测试和集成构建的验证，那么这些分支的工件将被部署到登台环境中。 在登台环境中，执行冒烟测试和验收测试。 如果在各个阶段通过这些测试验证了应用的完整性和新特性，则可以在整个生产环境中推出新版本。

在 Azure DevOps 术语中，正如您从前面的示例中看到的，CI 是使用 Git 和 Azure DevOps Build 模板实现的。 另一方面，CD 由版本定义处理，使用与触发的 CI 构建一起准备的构建工件。

重要提示

实际上，CI/CD 管道可以准备使用 TFVC 和相关的分支策略; 然而，Git 及其相关的分支策略(如 GitFlow)提供了更灵活和敏捷的设置。

使用 Azure DevOps，环境之间的转换(即，升级过程)可以通过部署前和部署后的门户来控制。 可以设置这些门以要求开发管道中特定涉众的批准(例如，环境所有者)。 除了人工审批，远程服务还可以用于 gate 审批。 例如，可以将应用模块的发布与另一个依赖模块同步，或者将部署阶段延迟到执行某些测试。

这里提供的示例只是一种可能的设计，版本控制实现、分支策略以及相关的发布管道设置应该根据开发团队的需求和业务需求来设计和执行。

在我们的示例应用中，为了创建管道，我们将分别使用 Git 和 GitFlow 作为我们的版本控制和分支策略。 对于发布管道，我们将创建一个开发版本，它将与每个提交/合并一起自动部署到开发分支(即下一个版本)，而 QA、UAT 和生产环境将从发布分支(即当前版本)部署。

CI/CD with GitFlow

说明 CI/CD 最简单的方法是通过策略和过程，从 GitFlow 开始。 这里，我们处理的是两个独立的存储库，即 web 和应用，每个存储库都有自己的生命周期。

换句话说，虽然不建议这样做，但我们的 web 应用(即服务基础设施)和应用(即移动平台发布)可能有不同步的发布和版本; 因此，创建向后兼容的模块并与开发团队成员交流版本是很重要的。

下面的小节将演示一个默认的开发周期，并解释开发人员通常需要做些什么来保持应用的质量，而不影响发布的节奏。

发展

应用或 web 模块的开发从创建一个特性分支开始(例如feature/12345)。 特性分支可以在多个开发人员之间共享，也可以由单个开发人员处理。 如果特性分支由多个开发人员处理，则可以按照类似的约定user/<user identifier>/<feature id>(例如user/cbilgin/12345)创建用户分支。 一旦每个开发人员完成了他们的实现，一个 pull 请求就可以在主特性分支上执行。

决定特性分支运行状况的一个重要因素是开发分支和特性分支之间的提交差异。 理想情况下，特性分支应该总是领先于开发分支，而不管在特性分支工作时在开发分支上完成的 pull 请求的数量。 为了实现这一点，应该定期根据当前的开发树重新调整特性分支，检索来自其他特性的最新提交。

开发人员可以通过在本地运行 web 应用和在理想的模拟器/模拟器上运行移动应用来测试在特性分支上完成的工作。 虽然 iOS 和 UWP 模拟器可以使用 localhost 前缀，因为本地机器网络是由模拟器共享的，Android 模拟器使用他们自己的 NAT 表，其中 localhost 指的是移动设备，而不是主机。 为了访问主机上的托管 web 服务，您应该使用10.0.2.2IP 接口。 下表显示了不同的 IP 地址，以及如何在 Android 模拟器中使用它们:

图 18.2 - Android 模拟器 NAT

如果应用和 web 服务是在具有各自发布周期的独立存储库上处理的，那么本地 web 服务器实例应该在开发(或主)分支上使用最新的提交，确保开发是使用最新的服务基础设施完成的。

一旦特性准备好集成到下一个版本中，开发人员就负责创建一个带有此特性分支所代表的相关工作项的拉请求。

Pull request/merge

在理想的设置中，特性分支合并到开发分支的唯一方式应该是通过拉请求。 拉请求也用于执行快速的健全检查和代码审查。

由开发人员交付的代码的质量可以通过目标分支(即开发分支)的分支策略来验证。 在本例中，对于开发分支，我们将使用四个策略:

• 附加到 pull 请求的工作项(特性和/或用户故事或 bug):任务和用户故事通常附加到特性分支中的提交。 特性、用户描述和/或错误工作项(这些是任务的父工作项)必须附加到拉请求，这样，一旦创建了发布管道，这些工作项就可以从发布构建中确定。
• Review by two team members:为了鼓励同行评审过程，至少有两名团队成员负责评审 pull request。 这些团队成员之一通常是团队领导，他是针对开发或发布分支的任何 pull 请求的强制审查者。 每个审阅者负责对代码更改进行注释，然后由 pull 请求的所有者更正这些更改。
• 团队领导的审查(包括最低数):架构师或团队领导通常是的人最终的代码质量负责引入开发或发布分支,所以他/她是一个强制性的评论家把请求。

• Branch evaluation build: For the mobile project, the branch evaluation build can be a build of the Android project (since Android builds can be executed on a Windows build agent, as opposed to the iOS builds having to be executed on a Mac agent). This build should execute the unit tests and run static code analysis using a platform such as SonarQube or NDepend.

  重要提示

  在这样的设置中，明智的做法是允许团队领导或其他负责的涉众在紧急情况下对政策拥有凌驾于其之上的权力，绕过评估构建(很少)和审查需求(更常见)。

使用 Azure DevOps，为了设置策略并强制开发人员创建 pull 请求，目标分支(即开发分支)应该配置以下分支策略:

图 18.3 -分支策略

目标分支上的任何策略需求都应该在更新分支时强制使用 pull 请求。

一旦策略验证令人满意(即满足所有必需的策略)，代码就可以合并到开发分支。 Azure DevOps 允许在完成期间选择合并策略。 这个合并策略应该与分支策略和设计一致。 在我们的示例中，我们将使用 Rebase; 然而，其他三个合并选项中的任何一个都可以使用:

图 18.4 -合并类型

一旦 pull 请求合并到开发分支中，CI 阶段就可以开始了，这将在下一节中讨论。

CI 期

启用了 ci 的分支上的任何更新都会触发构建来构建应用和/或 web 服务包。 例如，对于移动应用开发管道，可以使用开发阶段配置(例如 DevDroid 和 DeviOS 配置)触发目标移动平台的多个构建。 这些构建可以将应用包作为构建构件准备，并将它们与下一个应用版本和小修订一起发布。

CI 构建的触发器可以在构建属性中设置:

图 18.5 -构建触发器

除了触发分支之外，还可以设置路径过滤器，以便根据引入到应用代码基的更改触发不同的 CI 构建并准备工件。

此外，CI 构建应该执行任何可用的单元测试，以及可以在构建代理上运行的简单集成测试，这些结果可以连同代码覆盖一起发布到管道中。 使用当前工件版本注释的另一轮静态代码分析可以在静态分析平台(例如，SonarQube 服务器)上执行和发布。 这将有助于将源代码增量与此应用版本中可能出现的问题关联起来。

当 CI 构建成功完成时，根据触发器设置，可以创建一个发布管道，将准备好的工件部署到目标环境(在本例中就是开发环境):

图 18.6 -释放阶段工件触发

这个示例部署了由 CI 构建准备的微服务包，并将它们部署到开发环境中。 环境通过Azure 资源管理器(ARM)部署来更新，以目标资源组。 通常的做法是在没有任何预先批准的情况下设置开发环境的发布版本，这样集成到开发分支中的任何代码都会自动部署到开发环境中。

Azure DevOps 提供了两个任务来发布构建管道构件，创建的构件可以用作发布管道的触发器或辅助构件:

图 18.7 -工件任务

工件发布的一般经验法则是为构建使用 staging 目录:

图 18.8 -发布管道工件任务

在工件发布任务之前，对于 web 应用，. net 发布任务可以与相同的输出目录一起使用。 对于 Xamarin 包，可以创建一个复制任务，将应用包复制到 staging 目录。

来自合并的特性分支的工件已经可以部署到一个特定的环境中进行验证，或者可以将它们包含在一个发布范围中，作为发布的一部分进行验证。

发布分支

一旦验证了开发分支，并且当前特性集与预定的发布范围相匹配，就会创建一个发布分支(例如，release/1.8)。 发布分支的创建与发布构建的触发密切相关，该构建将为某个环境的发布准备所需的完整工件集。 相应地，相关的发布管道将由这个分支上的构建触发。

由于 Xamarin 应用包具有特定于环境的配置结构和多个应用构件，因此我们应该在这里专门用一段时间来介绍它。 如前所述，要让一个本地应用支持多个配置，我们需要创建多个应用包。 如果你考虑一个最小的支持场景，比如只支持 iOS 平台，为了在我们的发布管道中拥有 QA、登台和生产环境，我们将需要从相同的源代码版本创建三个独立的应用包。 如果我们也想支持 Android，这将意味着对于单一环境(例如 QA)，我们将需要部署一个 IPA 和一个 APK 到 Visual Studio App Center(两个独立的应用环)，并使用相同的 web 基础设施验证这些应用。 应该仔细设计和执行这些构建和发布阶段的同步。 单个平台的多配置构建可以与多代理构建模板一起使用，以创建一个包含多个包的单个工件，这样，只有在所有必需的构建完成之后，才会触发发布管道。

最后，版本工件的构建模板还可以用来检查质量，并处理要创建的版本所引入的范围。 发布管道还支持自动化测试的执行，以便在发布环境中自动化验证过程。 例如，在部署了某个服务 API 包之后，最好对部署 URL 执行功能测试，以验证部署是否成功。 以类似的方式，在将应用包部署到某个 App Center 环(例如，分段)之前，可以执行 Xamarin Test Cloud 测试来验证应用特性。

补丁分支

在使用发布管道将应用部署到快环或慢环(QA 或 UAT)之后，根据测试协议，QA 团队可以开始测试应用。

在此阶段，任何被拉入当前版本范围的错误或附加特性请求都应该由开发团队使用热修复分支引入。 热修复分支起源于当前的发布分支，并与 pull 请求的用户合并回发布分支(例如，release/1.8 -> hotfix/12324 -> release/1.8)。 一旦热修复被合并回发布分支(也就是说，它已经通过了验证)，它也需要合并回开发分支，以传播代码更改并避免在接下来的发布中回归。

对发布分支的合并和拉请求遵循与开发分支相似(尽管不完全相同)的方法。 通过这种方式，我们可以通过相同的质量验证过程推动修补程序的修改。

生产

在发布管道中，工件的某个版本可以从一个环境提升到更高的环境，直到产品发布完成，并将应用的新版本交付给最终用户。

根据管道设计、生产环境还可以利用分段或阶段性发布策略使用部署与释放环槽(即在 Azure 应用服务),本机分期与 TestFlight(即为 iOS 应用),甚至增量发布,苹果和谷歌播放存储支持。 通过这种方式，可以从 beta 用户那里收集发布环境中的应用遥测数据，并将其引入开发管道中。

在本节中，我们通过讨论交付管道的“左侧”开始分析，并从开发团队的角度观察该管道:如何创建、检查、合并应用源，以及可能交付到测试环境。 然后我们讨论了发布范围和交付管道，换句话说，转向交付管道的“右边”。 在这种设置中，我们当然需要在左侧尽可能早地开始验证和质量检查，这样我们的管道中就不会出现瓶颈。 在下一节中，我们将查看整个管道中的这些不同的质量验证检查点。

QA 过程

在一个 CD 过程的每个阶段中，特性的质量应该通过自动化过程或者至少通过适当的代码评审来验证。 这就是拉请求创建和验证过程变得更加重要的地方。 然而，如上所述，工件或分支的 QA 并不局限于流程的 CI 阶段，而是贯穿于 CI/CD 管道。

如您所见，我们可以对源代码和生成的工件进行各种质量检查，例如代码检查、自动化测试，甚至静态代码分析，以识别代码气味和编码约定问题。 让我们仔细看看这些 QA 步骤。

代码评审

一个健康的开发团队应该是由协作驱动的。 在这种情况下，同行评审的概念是非常重要的，因为它为开发团队提供了对同事工作的改进提出建议和建议的机会。 Azure DevOps 有两个分支策略，直接鼓励甚至强制同行评审过程。 其中一个策略是最少的审阅者数量，第二个策略是自动代码审阅者策略:

图 18.9 -代码评审策略

使用自动代码审阅器策略，多个可选和/或强制的审阅器可以自动添加到不同源路径的拉取请求审阅过程中。

这使得开发人员可以在 Azure DevOps web 门户上协作，在拉请求中包含的提交的特定行、部分甚至文件上创建注释。

审查过程不仅限于手动开发人员的反馈，而且还可以引入一些部分自动化。 如果作为一个验证构建政策的一部分,SonarQube 和声纳 c#插件可以检测包含在拉上构建执行请求,和代码问题,发现新代码静态分析的结果,被添加到拉请求评论拉请求完成之前得到解决。

可以使用注释解析策略强制(也就是说，它们必须在 pull 请求完成之前被解析)由同行或自动化工具添加的评审注释:

图 18.10 -注释解析策略

总的来说，可以说代码评审是 CI/CD 管道中代码质量维护的重要组成部分。

测试

正如您在第 16 章自动化测试中看到的，各种测试可以自动化并引入 CD 管道。 在任何 CI 构建上执行的测试都可以显示在构建结果摘要中，并在一个单独的部分中显示聚合的报告值(考虑到之前的运行)，从而使开发人员有机会在应用构件部署到目标环境之前识别问题。

任何(失败的)测试都可以作为在产品待办事项列表中创建工作项的起点(例如，一个 bug 或一个问题，取决于所使用的过程模板)，并附带任何相关的调试信息(如果可用的话)。 此外，自动化测试可以与实际的工作项相关联，例如特性或用户故事，允许 CI 过程与项目管理元数据创建有意义的关联:

图 18.11 -测试和工作项的关联

因此，自动化的测试不仅可以用于早期识别问题，还可以帮助分析和分类过程。 这种方式,开发团队可以提高两个重要 DevOps kpi:平均检测时间(MTTD)和平均恢复时间(【显示】MTTR),创建和保持健康的 CD 管道。

**## 使用 SonarQube 进行静态代码分析

由于 c#和。net Core 的编译特性，源代码的静态分析和质量指标可以帮助开发团队保持一个健康的开发管道。 与更老的工具(如 StyleCop)和更流行的 Visual Studio 扩展(如 ReSharper)类似，SonarQube 是一个开源静态分析平台，提供有价值的 kpi 和关于应用源代码的历史记录。 使用 SonarQube，质量度量的某些特征和趋势，如复杂性、代码气味和重复，可以用于在开发周期的早期识别问题，帮助开发团队将应用引导到正确的方向。

SonarQube 支持许多平台和语言，包括 c#，并与 MSBuild 和 Azure DevOps 基础设施深度集成，这使它成为任何。net Core 开发项目的理想选择。 服务器组件可以在本地托管，也可以作为云设置的一部分。 另一方面，SonarCloud 是基于 java 平台的托管版本。

设置好 SonarQube 服务器并安装好所需的插件(即 SonarCSharp)后，就可以设置给定项目的质量配置文件。 质量配置文件由源代码应该遵守的质量规则组成，每个规则定义了各种警告和错误级别:

图 18.12 - SonarCloud 问题视图

使用质量概要文件，可以定义一个所谓的质量检验关，确定源代码中哪一种类型的变更会触发检验关故障，提醒开发团队可能出现的问题。 质量检验关通常定义在泄漏期(即计算新代码的时期)内引入存储库的新代码上; 然而，整个项目中的一些聚合值也可以包括在内。

在这里，需要特别指出的是 SonarQube 使用一个 Git 扩展来访问源代码修订历史，并对代码树进行注释，这样就可以很容易地识别代码增量和提交的所有者。 一个简单的质量检验关可能看起来如下所示:

图 18.13 - SonarCloud 质量之门

SonarQube 分析的执行可以在 CI 阶段和 CD 阶段进行。 AzureDevOps SonarScanner 扩展提供了方便的集成构建和分析体验，而 SonarLint 和相关的 Roslyn 分析器为 Visual Studio IDE 中的开发人员提供了洞察和帮助。

使用 SonarLint 进行本地分析

SonarLint 是一个 Visual Studio 扩展，允许开发者将本地项目绑定到指定的 SonarQube 服务器及其相关的质量配置文件。 一旦源代码与 SonarQube 项目关联起来，它就下载规则集，并使用 Roslyn 分析器将这些规则应用到源代码中，提供了具有突出显示和问题解决方案选项的完全集成的编辑器体验。

将 SonarLint 与 SonarQube 一起使用，可以集中管理编码约定和规则，并有助于在更大的开发团队中维护代码质量。 虽然规则定义是由上述分析器提供的，但质量概要定义的级别使用规则集文件包含在项目中:

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="SonarQube - App Sonar way" Description="This rule set was automatically generated from SonarQube.
http://****.northeurope.cloudapp.azure.com:9000/profiles/show?key=cs-sonar-way-35075" ToolsVersion="15.0">
 <Rules AnalyzerId="SonarAnalyzer.CSharp" 
 RuleNamespace="SonarAnalyzer.CSharp">
 <Rule Id="S100" Action="Warning" />
 <Rule Id="S1006" Action="Warning" />
 <!-- Removed for brevity -->
 <Rule Id="S103" Action="Warning" />
 <Rule Id="S4027" Action="None" />
 <Rule Id="S907" Action="Warning" />
 <Rule Id="S927" Action="Warning" />
 </Rules>
</RuleSet>

这些规则定期与 SonarQube 服务器同步，可以与为其他分析器(如 StyleCop 分析器)定义的规则集文件组合在一起。

置信区间分析

一旦开发人员提交了他们的更改并创建了一个 pull 请求，就可以使用市场上可用的 Azure DevOps 扩展来执行 CSharp 的 SonarScanner。

在 Azure DevOps 实例上安装扩展之后，扩展的设置非常简单。 初始步骤是在你选择的 SonarQube 服务器上创建一个访问令牌(也就是说，SonarQube 或 SonarCloud 取决于所使用的变体)，并使用此令牌在 Azure DevOps 上创建一个服务连接:

图 18.14 - SonarCloud 服务连接

然后，集成的构建任务将作为一对任务包括在所需的拉请求验证构建(或 CI 构建)中:准备分析和运行分析。

Prepare Analysis 任务下载所需的分析配置并准备集成的 MSBuild 执行目标。 另一方面，Run Analysis 任务收集构建执行期间收集的结果，并将它们上传到服务器。 重要的是在进行任何编译之前放置准备任务，以便 Sonar 配置在执行编译时就绪。 一个简单的构建序列可能看起来像以下的:

图 18.15 - SonarCloud CI 管道任务

最后，可选的 Publish Analysis 任务可以等待分析结果，然后在当前管道中发布它们。

重要提示

. NET Core 项目不需要ProjectGuid属性，这与经典的. net 项目不同。 然而，声纳扫描仪使用ProjectGuid来识别项目并对其进行分析。 为了确保 Sonar 扫描仪能够成功执行，应该在每个.csproj文件上手动创建ProjectGuid属性，并将其设置为随机的Guid。

通过这种设置，Sonar 规则将在构建过程中被 Sonar 分析器用于识别不同严重程度的代码问题。 然而，如果我们需要或希望包含额外的 Roslyn 分析器，我们可能会希望运行声纳分析并计算关于聚合的代码问题集的度量。

外部 Roslyn 分析仪

除了内置的分析规则集，SonarQube 还可以使用由其他 Roslyn 分析器(如可用的 StyleCop 分析器)识别的警告和错误。

为了将 StyleCop 规则包含到。net Core 项目中，只需引用公开可用的 NuGet 包:

<ItemGroup>
    <PackageReference Include="StyleCop.Analyzers" Version="1.1.118" PrivateAssets="All" />
</ItemGroup>

此时，与编码约定相关的问题将被识别出来，并作为警告通过构建输出刷新。 此外，IDE 将使用 Roslyn 基础设施提供注释和解决方案。

最后，一旦项目通过 SonarQube 服务器分析，StyleCop.Analyzers识别的问题也将被存储并包含在质量检查计算中。 例如，下列问题由 StyleCop 规则识别，但包含在 SonarQube 中:

图 18.16 - SonarCloud Roslyn 分析器

总之，SonarQube 提供了一个完整的代码质量管理平台，再加上 Azure DevOps 和。net Core，提供了一个理想的自动化开发管道，并确保了 CI 过程的安全。

创建和使用发布模板

如前所述，一旦 CI 完成，理想情况下，发布的构建工件应该被转移到发布管道中，开始 CD 阶段。 Azure DevOps 发布模板和基础设施提供了一个完整的发布管理解决方案，无需任何额外的平台(如 Jenkins、Octopus 或 TeamCity)就可以处理 CI/CD 管道。

在这一节中，我们将看一下基本的发布模板元素，并在不同的发布模板中为 Xamarin 和 Azure web 应用发布制定细节。

Azure DevOps 发布

发布定义由两个主要组件组成:工件和阶段。 使用触发器和门，工件到目标阶段的部署是有组织和管理的。

释放工件

发布构件是为发布任务提供组件的元素。 这些构件可以从简单编译的应用库到直接从应用库检索的源代码:

图 18.17 -释放工件

让我们仔细看看这些工件类型:

• Azure 管道:这是最常用的构件类型，它允许构建管道将编译结果作为打包组件传递给发布管道。 使用此工件类型允许发布管道检测随工件引入的工作项，从而在项目工作项和发布详细信息之间创建直接的关系。 工件新版本的创建可以用作发布的触发器。
• TFVC、Git 和 GitHub:如果来自源代码存储库的静态内容，例如配置文件、媒体内容或源代码本身，对于发布管道任务来说是必需的，那么各种存储库都可以作为工件使用。 进入存储库的提交可以用作发布的触发器。
• Jenkins:如果在一个设置中涉及多个构建和发布管道，可以为 Jenkins 部署创建一个服务连接，并且 Jenkins 构建工件可以被 Azure DevOps 发布管道使用。
• Azure Container Registry, Docker 和 Kubernetes:当处理集装箱化的应用包时，可以将准备好的图像推送到私有容器注册表中，然后在发布过程中检索这些图像。
• Azure Artifacts (NuGet、Maven 和 npm):Azure 包管理构件可以被检索并使用该源来触发新发布，允许各种打包组件包含在发布管道中。
• 外部或本地 TFS:本地 TFS 基础设施也可以包含在 Azure DevOps 发布管道中。 为了使这种类型的集成能够工作，本地 TFS 服务器应该配备一个本地自动化代理。

使用市场上可用的 Azure DevOps 扩展，可以将 TeamCity 等其他构件引入到发布管道中。

在我们的应用管道中，我们将使用构建工件类型，它将包含 ARM 定义、web API 服务包以及用于各种环境的多个配置应用包。

发布阶段

用外行的话来说，发布阶段大致地转换为我们希望部署应用的环境。 重要的是要强调一个事实，即阶段只是一个逻辑容器，不需要引用单个服务器环境。 它可以指各种环境基础设施，也可以指移动应用的托管分发环。

发布阶段包含将在发布代理上执行的发布作业。 例如，如果我们要将构建工件部署到 Azure Stack 或将移动应用包部署到 App Center，我们可以在托管代理上使用代理作业。 然而，如果部署目标是一个内部服务器，我们将需要使用一个特定的部署代理或部署组。

如前所述，发布阶段可以包含多个发布作业，这些作业可以并行或顺序执行，这取决于组件之间的依赖关系。 例如，为了将 iOS 组件与 Android 或 UWP 包同时部署到 QA 分发环，我们可以利用并行代理作业来选择要下载和发布的特定工件。 每个工作都可以定义它需要的特定工件。 另一个多任务发布设置的例子是微服务包部署设置，其中每个服务都是独立部署的:

图 18.18 -各阶段的工件下载

在本例中，API 部署可能已经配置好，以便只有在主 ARM 部署完成之后，服务才被部署到与应用服务相关的地方。

释放门和触发器

在 Azure DevOps 发行版中，阶段之间的转换由触发器和门控制。 释放序列，以及手动或外部服务门，可以使用这些组件进行配置。

发布的主要触发器是通过发布中引入的工件来设置的。 如前所述，构建工件可以被设置为触发每个新版本的新发布。

以下触发器将在每次从匹配给定通配符表达式(即/release/*)的源分支创建构建工件时执行:

图 18.19 -连续部署触发器

可以对这个场景进行扩展，以包括构建标记和其他的exclude表达式。

在主要的释放触发器之上，每个阶段都可以定义一个单独的触发器。 这些触发器可以指实际的释放触发器或另一个阶段的完成。 还包括手动部署，以将一个阶段从主发布系列中分离出来。 下面的触发器将 QA 阶段定义为 UAT 阶段的触发器，将两个版本连接起来:

图 18.20 -阶段依赖

阶段之间的自动转换可以设置为期望来自特定用户(手动批准)或外部服务器的输入。 这些所谓的门可以定义为部署前或部署后的门，其中一个验证接收发布的环境的可用性，另一个验证部署的成功。

gates 最常见的应用是针对更高环境的手动审批部署前配置，因此正在进行的测试或实际的公共 web 应用不会受到危害。 Azure DevOps 组织中的任何用户都可以进行手动审批。 审批可以设置为在特定时间后过期，所选的审批人员可以委托给其他用户。

外部门户可以是各种服务端点，比如 Azure 功能、外部 web 服务，甚至是同一个 Azure DevOps 项目中的自定义工作项查询:

图 18.21 -释放盖茨

使用固有的触发和门功能，复杂的发布工作流可以按需或以自动的方式设置和执行。

Xamarin 释放模板

在 Xamarin 发布管道中，我们将接收用于多个平台和环境的多个应用包作为构建工件。 例如，考虑以下 Xamarin Android 的 CI 构建设置，其中我们将收到三个 QA、UAT 和 PROD 包:

图 18.22 -发布 Xamarin 工件

如果我们要为 iOS 创建一个类似的多代理构建，并将这些构建设置为在任何发布分支的传入提交时触发，我们将为每个部署环境创建一个新的应用:

图 18.23 -持续集成触发器

App Center 发布的发布管道现在可以引用这些构件并将它们部署到一个特定的 App Center 环上。 App Center 能够将应用包推送到 App Store，所以我们可以在 App Center 上创建一个生产环，将应用包从 App Center 部署到生产。

不同移动平台在并行环上的部署可以并行化为并行作业，也可以并行化为收敛于同步阶段的并行阶段:

图 18.24 - Xamarin 发布模板

同步阶段(例如Beta-Start和Beta-Finish)上的闸门可用于控制部署到某些分发环。

Azure web 应用发布

对于 Azure 基础设施，我们也将接收多个包。 Azure 部署管道中最重要的包是 ARM 模板和定义应用配置的相关配置参数文件。 可以直接从源存储库检索这些资源，也可以在 CI 构建期间使用用于复制文件的基本实用程序任务对它们进行打包，并(可选地)将它们打包到 ZIP 容器中。

重要提示

在构建 CI 期间可以使用的另一个有用工具是 Azure 资源组部署任务的验证模式。 通过这种方式，CI 构建可以验证在至少一个可用环境中引入的 ARM 模板更改。

API 服务，取决于所选择的托管选项(即，容器化，或打包为 web 部署，等等)，也将被创建为部署构件。

然后发布管道将 ARM 模板部署到目标资源组。 一旦资源管理器部署完成，web 应用包可以发布到目标应用服务实例或应用服务插槽，这取决于部署策略。

与 Xamarin 部署类似，发布管道可以配置为使用多个阶段来定义环境或使用多个部署的多代理阶段。 例如，将部署组件划分为多个阶段的示例发布管道如下所示:

图 18.25 - Azure 发布模板

在任何一种场景中，发布管理流程都应该是相同的:部署基础设施和配置，然后继续进行服务包部署。

总结

在本章中，我们完成了 Xamarin 存储库和 Azure web 基础设施的 CI/CD 管道。 我们已经看到 Azure DevOps 提供的工具集非常适合实现 GitFlow 分支策略。 该工具集还用于通过实现分支策略和设置 CI 触发器来管理应用生命周期。 此外，我们还了解了如何使用 CI 阶段来维护代码质量和技术债务。 最后，我们讨论了为分布式 Azure 和本地移动应用实现发布管道的策略。

通过这最后一章，我们已经达到了项目开发的最后阶段。 在本书的开头，在刷新了我们关于各种。net 概念、运行时、框架和平台的知识之后，我们转向了 Xamarin 开发。 我们使用。net 标准框架和 Xamarin 平台运行时创建和定制 Xamarin 应用。 希望您已经了解了在 Xamarin 上的何处使用哪种类型的定制。 形式框架。 一旦我们完成了 Xamarin 项目，我们的重点就转移到 Azure 云堆栈，以及我们如何在各种 Azure 服务上利用。net Core，这些服务可以与 Xamarin 移动应用一起使用。 Azure 堆栈的讨论主要集中在平台即服务(Platform as a Service)上，比如 App Service、无服务器组件，最后是数据存储服务，比如 Cosmos DB。 此外，我们还学习了如何在推送通知、Graph API 和认知服务等外部服务的帮助下更好地吸引用户。 我们慢慢地创建了移动应用和后端基础设施，最后一节是关于如何使用 Microsoft Azure DevOps 和 Microsoft Visual Studio App Center 有效地管理我们项目的生命周期。 通过使用 Azure DevOps，我们试图通过创建自动化 CI/CD 管道来实现现代 DevOps 概念。

虽然实现和实际示例非常一般化，但我们在本书中讨论的实践概念将是您和您的团队计划进行的任何跨平台开发项目的良好起点。 对于任何。net 开发人员来说，理解。net Core 和。net Standard 的其他实现是解锁多个平台并创建跨平台的用户体验的关键。**

版权属于：月萌API www.moonapi.com，转载请注明出处

本文链接：https://moonapi.com/news/33639.html