十四、Azure DevOps 和 Visual Studio App Center

Visual Studio App Center 是微软提供的一种一体化服务，主要供移动应用开发人员使用。 Xamarin 平台和 UWP 应用都是受支持的平台。 App Center 的主要目标是为移动项目创建一个自动构建-测试-分发管道。 App Center 对 iOS 和 Android 开发者来说也很有价值，因为它是唯一一个为两个目标运行时提供统一测试版发行版的平台，支持遥测收集和崩溃分析。 通过使用 Azure DevOps(以前称为 Visual Studio Team Service)和 App Center，开发人员可以为 Xamarin 应用建立一个完全自动化的管道，将源存储库连接到最终的商店提交。

本章将展示 Azure DevOps 和 App Center 的基本特性，以及如何创建适合个人开发人员和开发团队的高效应用开发管道。

本章将涵盖以下主题:

  • 使用 Azure DevOps 和 Git
  • 创建 Xamarin 应用包
  • Xamarin 的应用中心
  • 借助 App Center 进行分销
  • 应用中心遥测和诊断

在本章结束时，您将学习如何有效地使用 Git 为您将存储在 Git 上的项目创建可管理的历史记录。 使用这些 Git 存储库，你将能够创建持续集成和交付管道，向 App Center 提供 Android 和 iOS 包。 这些数据将用于分发和遥测收集。

使用 Azure DevOps 和 Git

我们将以介绍 Git 以及如何在 Azure DevOps 上使用 Git 开始我们的 Azure DevOps 之旅。 我们还将讨论用于 Git 分支和管理这些分支的不同技术。

开发人员使用的 Azure DevOps 的第一个也是最重要的模块是其可用的源代码控制选项。 开发人员可以选择使用Team Foundation Version Control(TFVC)或 Git 来管理源代码(甚至同时使用两者)。 然而，随着分散的源代码控制管理的日益流行，由于开发工具集提供的灵活性和集成，Git 对许多人来说是更有利的选择。 Git 本地集成了 Visual Studio 和 Visual Studio for Mac。

使用 Azure DevOps 创建 Git 存储库

多个 Git 存储库可以托管在 Azure DevOps 中的同一个项目集合下，这取决于所需要的项目结构。 每个存储库都可以使用不同的安全性和分支策略进行管理。

要创建 Git 存储库，我们将使用 Azure DevOps 的 Repos 部分。 一旦创建了 DevOps 项目，就会为您创建一个需要初始化的空 Git 存储库。 这里的其他选择是导入一个现有的 Git 仓库(不一定是从其他 Azure DevOps 项目或组织)，或者从你的工作站推送一个现有的本地仓库:

Figure 14.1 – Initializing an Azure DevOps Repository

图 14.1 -初始化 Azure DevOps 存储库

重要提示

在创建无法更改的 Visual Studio Team Services 项目时，选择存储库类型是一个最初的决定。 然而，使用 Azure DevOps，即使在初始项目创建之后，也可以创建 Git 存储库，并与 TFVC 存储库并排。

重要的是要注意，克隆选项允许我们生成 Git 凭据，以便使用这个 Git 实例进行身份验证。 主要原因是 Azure DevOps 使用了联合实时身份验证(可能的双因素身份验证)，这是 Git 本身不支持的。 因此，这个存储库的用户需要生成一个个人访问令牌(PAT)，并将其用作密码。 Git for Windows 插件通过自动创建 PAT(并在 PAT 过期时更新它)来自动处理这个身份验证问题。 如果你想在 Mac 上使用 Git 和 Visual Studio, PAT 是目前唯一的解决方案。

在初始化选项中，我们还可以选择要创建的.gitignore文件(类似于 TFVC 的.tfignore文件)，这样项目文件夹中不需要的用户数据就不会上传到源存储库中。

分支策略

使用 Git 和 Git 流程方法/模式，开发团队可以将本地和远程分支建立在两个主要分支上:开发分支和主分支。

开发分支被用作默认分支(也被称为主干)，并代表下一个版本的源代码，直到特性集(分支)被开发团队完成并签署为止。 此时，将创建一个发布分支，下一个发布包的最后稳定阶段将使用该发布分支作为开发中所有热修复分支的基础。 每个来自更改发布版本的热修复分支的 pull 请求都需要合并回开发分支。

特性、开发和发布分支的一般流程如下图所示:

Figure 14.2 – Git flow Branching Strategy

图 14.2 - Git 流分支策略

一般流程如下:

  1. To safeguard the development branch as well as the release branches, developers, whether they're working on local or feature branches, will need to create a pull request that will be verified per the branch's policies.

    重要提示

    Pull 请求促进了同行评审过程，以及为了对开发或发布分支做出贡献而需要执行的额外静态分析。

  2. 在这种设置中，开发分支将有一个持续的集成构建和部署到 App Center 分发的快速环。 这允许开发和 QA 团队立即验证已合并到分支中的特性。

  3. 一旦当前版本分支准备好回归，它就可以合并到主分支中。 这种合并通常通过自动化 UI 测试(即自动化回归)进行验证。 主分支被用作 Visual Studio App Center 慢环部署(即登台环境)的源存储库。
  4. 过时的特性分支(参见外部特性分支)跨越多个版本，需要重新建立基础，以便将开发分支的历史添加到特性分支中。 这允许开发团队拥有关于提交的更清晰的元数据。
  5. 热修复分支用于纠正在发布分支中报告的存储提交失败或回归错误。 热修复分支可以通过自动化 UI 测试(完全自动化的回归)和手动使用慢环版本进行测试。
  6. 一旦主分支准备好发布，就会创建一个新的标记作为代码冻结的一部分，并且手动触发构建将为应用的 iOS 和 Android 版本准备提交包。

这个方法也可以修改为使用发布分支来进行登台和存储部署，而不是使用主分支。 这种方法为开发团队提供了更多的灵活性，并且比管理单个版本分支(即主分支)要简单一些。

管理开发分支机构

在开发阶段，保持开发和特性分支的清晰历史是很重要的——如果您正在与一个更大的团队合作的话更是如此。

在敏捷管理的项目生命周期中，分支(本地或远程)上的提交声明任务属于一个用户故事或一个 bug，而分支本身可能与用户故事或 bug 相关。 团队成员之间更大的共享分支也可以代表一个完整的特性。 在这种情况下，为了在保持源代码安全的同时减少提交的数量，而不是在每次发生更改集推入时创建一个新的提交，你可以使用Amend Previous commit特性:

Figure 14.3 – Amending a Commit

图 14.3 -修改 Commit

一旦用这些更改修改了提交，本地提交将需要与远程版本合并。 在这里，避免在远程和本地分支之间进行合并提交的关键(因为远程分支具有较旧的提交版本，因此需要进行不同的提交)是在push命令中使用--force或--force-with-lease选项。 这样，本地提交(修改后的)将覆盖远程版本:

Figure 14.4 – Enabling Push --Force

图 14.4 -启用 Push—Force

需要注意的是，当多个开发人员在同一个分支上工作时，不建议修改提交和覆盖远程分支。 这可能会为相关方的本地存储库上的分支创建不一致的历史记录。 为了避免这种情况，应该在特性分支准备好被合并后，将其分支扩展，并基于特性分支的最新版本进行重新划分。

让我们假设您已经从远程特性分支创建了一个本地分支，并推送了几次提交。 与此同时，你的团队成员向功能分支推送了几个更新:

Figure 14.5 – Git Feature Branches

来源:(https://www.atlassian.com/git/tutorials/merging-vs-rebasing / CC BY 2.5 AU)

图 14.5 - Git 特性分支

使用传统的同步(拉和推)，将创建一个合并提交，并且特性分支的历史将类似如下:

Figure 14.6 – Git Merge Commit

来源:(https://www.atlassian.com/git/tutorials/merging-vs-rebasing / CC BY 2.5 AU)

图 14.6 - Git Merge Commit

然而，如果本地分支在推送之前重新基于远程分支的最新版本，历史将会是这样的:

Figure 14.7 – Git Rebase

来源:(https://www.atlassian.com/git/tutorials/merging-vs-rebasing / CC BY 2.5 AU)

抱歉

在您创建到开发或发布分支的 pull 请求之前，应该使用 rebase 策略，这样可以保留分支的干净历史记录，从而避免复杂的合并冲突。

在本节中，我们关注 Azure DevOps 上的 Git 存储库，如何创建和初始化它们，以及如何在使用最佳实践的同时使用 Visual Studio 执行众所周知的 Git 分支策略。

创建 Xamarin 应用包

一旦我们的应用准备好在实际设备上进行测试，我们就可以开始准备管道，以便我们可以编译和打包应用，并将其部署到 App Center 的 alpha 和 beta 环境中。 Azure DevOps 为这两个 Xamarin 都提供了开箱即用的模板。 Android 和 Xamarin 的。 iOS 应用。 这些管道可以进行扩展，以包括额外的测试和静态分析。

使用 Xamarin 构建模板

为 Xamarin 应用创建构建和发布模板就像为 iOS 和 Android 使用 Xamarin 模板一样简单。 此外，UWP(如果你的应用支持这个平台)模板也可以用来创建 UWP 构建:

Figure 14.8 – Xamarin Build Tasks

图 14.8 - Xamarin Build Tasks

一旦创建了管道，我们将需要对两个平台做一些小的调整，以便准备应用，以便将其放到实际设备上。

Xamarin 的。 Android 构建

让我们来看看构建 Android 项目的步骤:

  1. First, identify the correct Android project to be built using the wildcard designation and the target configuration:

    Figure 14.9 – Xamarin.Android Build Setup

    图 14.9 - Xamarin。 Android 构建设置

    重要提示

    注意，配置和输出目录使用管道变量。 这些参数可以在Pipeline 配置页面的Variables部分中定义。

  2. Select a keystore file so that you can sign the application package.

    未签名的应用包不能在真正的 Android 设备上运行。 密钥存储库是一个存储库，其中包含将用于对应用包进行签名的证书。 如果你正在使用 Visual Studio 进行开发(在 Mac 或 Windows 上)，生成临时发行证书的最简单方法是使用 Archive Manager:

    Figure 14.10 – Creating a distribution certificate

    图 14.10 -创建发布证书

  3. Once the store has been created, the keystore file can be found in the following folder on Mac:

    ~/Library/Developer/Xamarin/Keystore/{alias}/{alias}.keystore

    它可以在 Windows 的以下文件夹中找到:

    C:\Users\{Username}\AppData\Local\Xamarin\Mono for Android\Keystore\{alias}\{alias}.keystore

  4. Now, use the .keystore file to complete the signing step of our Android build pipeline:

    Figure 14.11 – Signing the Xamarin.Android Package

    图 14.11 -签名 Xamarin。 安卓包

    注意，管道将.keystore文件作为安全文件使用。 以类似的方式，密钥存储库密码可以(应该)存储为安全变量字符串。

  5. 管道现在已经准备好了。 编译 Android 版本的应用，创建一个 APK 包。

接下来，我们需要为 iOS 平台准备一个类似的管道。

Xamarin 的。 iOS 管道

类似于 Android 版本的 Xamarin。 iOS 模板创建了编译 iOS 项目的完整管道。 我们需要修改已创建任务的参数，以便成功地准备应用包。 让我们开始:

  1. Before we start the pipeline configuration, head over to the Apple Developer site to generate a distribution certificate, Application ID, and an ad hoc provisioning profile:

    Figure 14.12 – Creating a Distribution Certificate

    图 14.12 -创建发行证书

  2. 选择分发证书选项，并让开发人员站点指导您完成生成 CSR 和生成签名证书的步骤。

  3. 创建证书之后，下载并安装证书，以便您可以将其导出为一个公钥/私钥对(.p12)。 你需要遵循以下步骤:
  4. 打开“Keychain Access”工具。
  5. 标识我们已经下载和安装的发行版证书。
  6. 展开证书，从而显示私钥。

  7. Select both the public certificate and private key so that you can use the Export option.

    一旦我们有了发布证书，我们将需要一个应用 ID 来生成一个配置配置文件。 在生成应用 ID 时，重要的决策是决定是使用通配符证书(这可能是在多个应用的预发布版本中使用的一个好选项)还是使用完整的资源标识符。

  8. 最后，为特别分发创建应用配置文件。 特别发行是通过 App Center 进行预发行的最合适的发行选择。

  9. With the P12 certificate we've exported and the mobile provisioning profile that we have generated and downloaded from the Apple Developer site, head over to Azure DevOps and modify the Install an Apple certificate and Install an Apple provisioning profile tasks:

    Figure 14.13 – Installing our Provisioning Profile and Certificate

    图 14.13 -安装我们的配置文件和证书

    最后，重要的是确保应用包是为真实的设备创建的，而不是一个模拟器。

  10. 在 Xamarin 中选择以下设置。 iOS 建设任务:

Figure 14.14 – Xamarin iOS Build Setup

图 14.14 - Xamarin iOS Build Setup

这里，可以将签名标识和配置概要 UUID框留空，因为这些元素将由管道安装。 如果管道中存在多个概要文件或证书，则需要定义一个要使用的特定概要文件或证书。

重要提示

Apple 临时发布配置文件需要允许使用该应用的分布式版本的设备的 UUID。 简单地说，使用和测试这个版本的应用所涉及的任何设备都应该在这个配置文件中注册，并且应用应该与它签署。

这最终完成了 Xamarin Android 和 Xamarin iOS 构建管道的设置。 现在，我们可以生成应用包，以便准备分发它们。 然而，我们没有考虑这些设置中特定于环境的配置。 让我们看一下特定于环境配置的一些可能的解决方案。

环境相关配置

从配置的角度来看，本地应用与 web 应用不同，因为应用 CI 管道应该将配置参数嵌入到应用包中。 虽然可以使用不同的技术来管理不同环境的配置参数，例如单独的 JSON 文件、编译常量等等， 这些实现的共同点是，它们都使用条件编译或编译常量来确定在应用包中包含哪些配置参数。 换句话说，如果不重新编译应用，就不可能更改应用特定于环境的配置。

要创建指向不同服务端点的多个分发环，应用将需要构建具有多个配置的不同单管道，或者我们需要创建多个管道来为特定平台和配置构建应用。

创造和使用人工制品

为了增加跨项目的可重用性，我们可以使用 Azure DevOps 的包管理扩展。 跨 Xamarin 项目的 UI 组件，以及在 Azure 项目和客户端应用之间共享的 DTO 模型，可以通过它们自己的生命周期(开发-合并-编译-部署)合并到 NuGet 包中。

将这些模块存储在同一个 Azure DevOps 项目的单独 Git 存储库中的单独项目/解决方案中，可以更容易地集成到之前创建的构建中。

一旦 NuGet 项目准备好编译并打包一个已定义的.nuspec文件，就可以设置一个单独的 DevOps 管道来创建这个包，并将其推送到同一个团队项目的内部提要中。

一个 NuGet 构建管道示例将类似于:

Figure 14.15 – NuGet pipeline

图 14.15 - NuGet 管道

为了在 Xamarin iOS 和 Android 管道中包含这个提要，需要配置 NuGet Restore 步骤来包含内部提要，以及Nuget.org源。 此外，可以将Nuget.org设置为内部提要的上游源，以便将公共包缓存在内部提要中。

在本节中，我们分析了多种平台的各种管道选项，包括 Xamarin。 Android 和 Xamarin 的。 iOS，以及 NuGet 包。 这些管道是持续集成和交付管道的基石，因为它们提供了要分发的构件。

Xamarin 应用中心

Visual Studio AppCenter 在其前身 HockeyApp 及其特性集的基础上进行了扩展，是一个移动应用生命周期管理平台，用于轻松地构建、测试、分发和收集来自 iOS、Android、Windows 和 macOS 应用的遥测数据。 它与各种存储库选项和构建功能的内在集成甚至可以用于从 Azure DevOps 迁移开发和发布管道。 Visual Studio App Center，就像 Azure DevOps 一样，遵循免费订阅模式，开发者可以通过免费订阅访问它的大部分功能; 他们需要付费订阅某些功能的配额增强。

与源存储库和构建集成

尽管我们已经在 Azure DevOps 及其相关的构建管道上建立了我们的源存储库，但 App Center 也可以用于同样的目的。

例如，如果我们要建立 iOS 构建管道，我们将遵循以下步骤:

  1. Start by creating an application within our organization. An application on App Center also represents a distribution ring:

    Figure 14.16 – Creating a New App on App Center

    图 14.16 -在 App Center 上创建一个新的 App

  2. Once the application has been created, in order to create a build, connect the App Center application to the target repository. Just like Azure DevOps pipelines, you are free to choose between Azure DevOps, GitHub, and Bitbucket:

    Figure 14.17 – Selecting the Source Repository

    图 14.17 -选择源存储库

  3. Now that the repository is connected, start creating a build that will retrieve the branch content from the source repository and compile our iOS package:

    Figure 14.18 – Setting up our App Center Build

    图 14.18 -设置我们的 App Center 构建

  4. 一旦构建完成，就可以手动构建，也可以将其配置为 CI 构建，每次有一个推送到源分支(在本例中是主分支)时都会触发 CI 构建。

在本节中，我们创建了一个应用注册，并将来自 Azure DevOps 的源存储库与其关联起来，以便可以利用 app Center 构建。 接下来，我们将在我们的应用注册上创建分发环，这样我们在 Azure DevOps 上的 CI 管道就可以向 App Center 提供包进行分发。

设置配电环

自从我们开始为我们的应用建立 ALM 管道以来，我们就一直在中提到 App Center 的分销环。 正如我们所见，分销圈指的是在你的个人或组织账户上创建的应用。 这个环代表应用上特定于环境(例如，Dev)的编译或特定平台(例如，iOS)。

App Center 应用通过所谓的应用段塞来表示。 应用段塞可以从 App Center 页面的 URL 中提取。 URL 语法如下:

  1. https://appcenter.ms/users/{username}/apps/{application}:

    App Slug: {username}/{application}

  2. https://appcenter.ms/orgs/{orgname}/apps/{application}:

    App Slug: {orgname}/{application}

如果我们回到我们的 Azure DevOps 管道，我们可以使用这个值来设置部署到 App Center。 然而，在我们这样做之前，我们需要创建一个带有 API 令牌的 App Center 服务连接，您可以从 App Center 检索该令牌。 这将允许 Azure DevOps 授权与 App Center 和推送应用包:

Figure 14.19 – App Center Integration on Azure DevOps

图 14.19 - Azure DevOps 上的 App Center 集成

让我们完成其余的配置参数:

Figure 14.20 – App Center Distribution Task

图 14.20 - App Center 分发任务

使用另一个 App Center 应用为 Android 版本重复相同的步骤将完成我们应用的初始 CI 设置。 与 App Center 构建类似，这个构建可以设置为每次合并到开发或主分支时触发。

重要提示

在解决方案文件夹(即存储库中)中存储降价表(例如ReleaseNotes.md)以记录对应用的更改是非常方便的。 在每个 pull 请求中，当开发人员将更新输入到这个文件中，关于正在部署的更改的发布说明可以很容易地推送到 alpha 和 beta 发行渠道中。

在本节中，我们成功地在 App Center 中创建了应用注册，并创建了简单的构建管道，以演示其功能。 最后，我们将之前准备好的 Azure DevOps 管道集成到 App Center 应用注册中，作为分发环使用。 在下一节中，我们将重点关注 App Center 发行版。

应用中心配送

除了 App Center 的构建、测试和遥测收集功能外，App Center 的主要功能是，你可以管理预发布应用的分发，以及自动提交到公共和私有应用商店。

App Center 发布

一旦应用包从构建管道被推送到 App Center，一个应用发布就被创建了。 这个版本代表应用包的一个版本。 这个包可以分发到当前分发环内的分发组或外部分发目标:

Figure 14.21 – App Center Release

图 14.21 - App Center 发布

当一个发行版被创建后，协作组(即对 App Center 有管理访问权的开发人员)可以访问它。

AppCenter 分发组

发布组是一组开发人员和测试人员，他们可以发布应用的版本(应用的特定环境和平台版本):

Figure 14.22 – App Center Distribution Groups

图 14.22 - App Center 分布组

分发组是非常有价值的，因为它们为不同的分发环提供了额外的阶段。 例如，一旦一个发布版本从 Azure DevOps 推送到 App Center，第一个发行组就可以在允许第二个发行组访问这个新版本之前验证该应用。 通过这种方式，来自各种管道的自动发布可以在 alpha 和 beta 通道上交付给特定的目标组。

此外，如果你导航到一个 iOS 应用环上的协作者组详细信息，你可以确定哪些设备目前包含在配置文件中:

Figure 14.23 – App Center Device Registration

图 14.23 - App Center 设备注册

对于注册设备，App Center 支持为 iOS 版本自动发放设备。 在这种设置中，每次在分发组中注册一个新设备时(假设配置了自动配置)，App Center 将更新 Apple Developer Portal 上的配置配置文件，并使用新的配置配置文件退出发布包。

App Center 分发到生产

一旦应用通过下环认证(即 alpha 和 beta)， App Center 发布就可以推进到生产阶段。 生产阶段可以是目标公共的 App Store(例如，iTunes Store，谷歌 Play Store 等)，或者可以使用移动设备管理或移动应用管理(例如，Microsoft Intune)将应用发布给用户。

要将 iTunes Store 设置为目标商店，你需要在 App Center 中添加一个 Apple Developer 账户。 类似地，如果你的目标是 InTune，一个管理员帐户应该添加到你的 App Center 集成:

Figure 14.24 – App Center Distribution to Stores

图 14.24 - App Center 对商店的分布

需要注意的是 App Store Connect 提交不会绕过苹果商店对应用包的验证——这只是一个通常通过 Xcode 处理的切换过程。

App 中心遥测诊断

App Center 提供先进的遥测和诊断选项。 要开始使用这些监控功能，应用 Center SDK 需要安装在应用上，并为所有目标平台初始化。 按照以下步骤来学习:

  1. 从公共 NuGet 商店安装 NuGet 包。 使用包管理器上下文，如下所示:
  2. 在本例中，我们正在创建 Xamarin。 表单应用，因此初始化不需要是特定于平台的:
  3. 一旦 App Center SDK 被初始化，应用将启用默认的遥测信息和崩溃跟踪。 这个遥测信息可以扩展自定义指标和事件遥测 usi 在 SDK 中可用的功能:

Figure 14.25 – App Center Telemetry Collection

图 14.25 - App Center 遥测采集

在这些遥测信息之上，App Center 允许你跟踪两种类型的错误信息:应用崩溃和错误。 应用崩溃信息与导致应用崩溃的遥测事件一起记录，让开发者可以轻松地排除问题。

此外，遥测信息可以推送到 Application Insights，以便在 Azure 门户上进行分析。

总结

在本章中，我们设置了初始的构建管道，这将在接下来的章节中展开。 我们还讨论了 Azure DevOps 和 Visual Studio App Center 上可用的 ALM 特性，以及如何有效地结合使用这两个平台。 根据团队的规模和应用类型，可以在这些平台上实现许多不同的配置，从而为开发人员提供了一个自动化且易于使用的开发管道。

在下一章中，我们将学习如何监控我们的移动应用，以及与 Azure application Insights 一起使用的 Azure 资源。

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

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