[ReactNative翻译]持续集成（CI）如何改善你的 React Native 应用程序？

Sunbreak
348 阅读12分钟

本文由 简悦 SimpRead转码，原文地址 www.callstack.com

阅读文章，了解持续集成（CI）如何改进构建、测试和 ......

以下文章是React Native 优化终极指南的一部分，介绍了如何通过持续集成（CI）改进应用程序。本文由 Expo 共同撰写，他们分享了关于设置 EAS Build 并在其上运行构建的见解。

为什么它很重要？

缺乏有效的持续集成可能会从多个不同层面严重损害您的应用程序。它可能会减慢开发过程和测试速度，并使您的最终应用程序面临错误和回归，从而降低您的收入。在本文中，我将向您展示如何使用持续集成来防止 React Native 应用程序出现这种令人不快的情况。

在本指南的前几部分，我们已经讨论了以下内容：

稍后查看这些内容，现在让我们进入正题。

应用程序开发中的多面反馈回路

正如您已经从本系列的另一篇文章中了解到的，用测试覆盖您的代码对于提高应用程序的整体可靠性非常有帮助。不过，虽然测试产品至关重要，但它并不是更快、更自信地交付产品的唯一前提。

同样重要的是，您如何快速发现潜在的回归，以及发现回归是否是日常开发生命周期的一部分。换句话说，这一切都归结于反馈回路。

冗长的反馈循环（无 CI）会对 React Native 项目造成怎样的损害？

为了更好地理解上下文，让我们来看看开发过程的早期。刚开始时，您的重点是尽快交付第一个迭代（MVP）。因此，您可能会忽略架构本身的重要性。当您完成修改后，您就可以将它们提交到版本库，让团队的其他成员知道该功能已准备好接受审核。

Github 上的一个工作流程示例，以 PR 的形式提出变更。

虽然这种技术非常有用，但它本身也有潜在的危险，尤其是当你的团队规模扩大时。在准备接受 PR 之前，您不仅要分析代码，还要将其克隆到您的环境中并进行彻底测试。在这个过程的最后阶段，可能会发现建议的修改引入了原作者没有发现的回归。

原因很简单--我们都有不同的配置、环境和工作方式。

组织更难接纳新成员。您无法在出现 PR 和不同贡献时对其进行发布和测试。

如果您手动测试您的变更，您不仅会增加向生产交付回归的几率。而且还会拖慢整体开发速度。值得庆幸的是，有了一套正确的方法和一点自动化，您就可以一劳永逸地克服这一挑战。

什么是持续集成，它是如何工作的？

这就是 持续集成（CI） 发挥作用的时候。CI 是一种开发实践，在这种实践中，开发团队每天都会多次将提议的变更签入上游资源库。然后，通过自动构建对其进行验证，使团队能够及早发现变更。

自动构建由基于云的专用 CI 提供商执行，该提供商通常与您存储代码的地方集成。目前，大多数云提供商都支持 Github，这是一个微软旗下的项目协作平台，使用 git 作为版本控制系统。

CI 系统会实时提取更改并执行一组选定的测试，以便及早反馈结果。这种方法为测试引入了一个单一的真相源，让不同环境的开发人员都能获得便捷可靠的信息。

使用 CI 服务，您不仅可以测试代码，还可以为项目构建新版本的文档、构建应用程序，并将其分发给测试人员或发布人员。这种技术被称为 持续部署，重点在于发布的自动化。

继 Circle CI 部分之后，本章将介绍 EAS Build 部分。为什么？我们相信，EAS 构建小节也能帮助开发人员实现与 CircleCI 一样的结果。

使用持续集成提供商构建 React Native 应用程序

有很多 CI 提供商可供选择，其中最受欢迎的是 CircleCI、GitHub Actions 和 Bitrise。对于 React Native 应用程序，另一个选择是 EAS Build，这是 Expo 创建的一项服务，对 React Native 有一流的支持。

在本节中，我们选择 CircleCI 作为我们的参考 CI 提供商，因为它已被社区广泛采用。事实上，有一个示例项目演示了如何将 CI 与 React Native 结合使用。您可以在 此处 了解更多信息。我们将在本节稍后部分使用它来介绍不同的 CI 概念。

我们还将深入了解 EAS Build，它旨在尽可能简化应用程序的构建和测试。它还有助于向商店和团队内部分发应用程序二进制文件。

注：一个好的做法是利用 React Native / React Native 社区项目已经使用的资源。通过这一途径，您可以确保您选择的提供商可以与 React Native 配合使用，而且核心团队已经解决了最常见的难题。

如何使用 CircleCI 设置 CI

对于大多数 CI 提供商来说，在做任何其他事情之前研究一下它们的配置文件是非常重要的。

让我们来看看 CircleCI 的示例配置文件，它取自前面提到的 React Native 示例：

version: 2.1

jobs:
  android:
    working_directory: ~/CI-CD
    docker:
     - image: reactnativecommunity/react-native-android
    steps:
      - checkout
      - attach_workspace:
      at: ~/CI-CD
      - run: npm i -g envinfo && envinfo
      - run: npm install
      - run: cd android && chmod +x gradlew && ./gradlew
assembleRelease

workflows:
  build_and_test:
    jobs:
      - android

该结构是基于文本的配置文件的标准 Yaml 语法。在进一步操作之前，您可能需要了解其基础知识。

注：许多 CI 服务（如 CircleCI 或 Github Actions）都基于 Docker 容器和将不同作业组合成工作流的理念。Github 及其 Github Actions 就是此类提供商的一个例子。你可能会发现这些服务之间有许多相似之处。

CircleCI 配置中的命令、作业和工作流

CircleCI 配置中有三个最重要的组成部分：命令、作业和工作流。

命令只是一个 shell 脚本。它在指定的环境中执行。此外，它也是在云中执行实际作业的工具。它可以是任何命令，从安装依赖项的简单命令，如 yarn install（如果使用 Yarn），到更复杂的 ./gradlew assembleDebug（构建 Android 文件）。

作业是一系列命令（描述为步骤），专注于实现一个确定的目标。作业可以通过选择合适的 Docker 容器在不同环境中运行。

例如，如果您只需要运行 React 单元测试，您可能希望使用 Node 容器。这样，容器会更小，依赖关系更少，安装速度也会更快。如果你想在云中构建 React Native 应用程序，可以选择不同的容器，例如使用 Android NDK/SDK 或使用 OS X 构建苹果平台的容器。

‍为了帮助您在运行 React Native 测试时选择使用的容器，团队准备了react-native-android Docker container，其中包括执行 Android 构建和测试所需的 Node 和 Android 依赖项。

为了执行作业，必须将其分配给一个工作流。默认情况下，作业将在工作流中并行执行，但可以通过指定作业要求来更改。

工作流包含可分组按顺序或并行运行的作业

您还可以通过添加筛选器来修改作业执行计划，例如，部署作业只有在代码中的更改指向主分支时才会运行。

您可以为不同的目的定义多个工作流，例如，一个工作流用于在 PR 打开后运行测试，另一个工作流用于部署新版本的应用程序。React Native 就是这么做的，每隔一段时间就会自动发布新版本。

设置 EAS 构建

EAS 是 Expo Application Services 的缩写。它提供的服务之一就是 EAS Build。与一般的 CI 提供商不同，它专为构建和测试 React Native 应用程序而设计，可处理应用程序签名凭证和在团队成员之间的内部分发，还可与 EAS Submit 紧密集成，自动提交应用程序商店。

EAS Build 是一项托管服务。这意味着许多传统上在通用 CI 提供商中需要手动定义的工作流程步骤都将自动处理。它还为每个构建任务使用新的构建环境，并已安装 Java JDK、Android SDK 和 NDK、Xcode、Fastlane 等工具。

只需在您的开发计算机上执行以下几个步骤，您就可以开始了。完成这些步骤后，您就可以为 EAS 设置项目、配置构建配置文件并启动构建任务了。

‍运行 EAS 构建

首先，在终端运行此命令安装 eas-cli 软件包：

npm install -g eas-cli

或者，如果不想安装全局依赖，也可以使用 npx eas-cli 运行这些命令。

设置 EAS 构建

接下来，为 EAS Build 初始化配置文件，并在项目根目录下运行此命令：

eas build:configure

该命令将在项目根目录下创建一个名为 eas.json 的文件。该文件包含 EAS 正常运行所需的全部配置。

{
  "cli":{
    "version":">= 3.3.2”
  },
  "build":{
   "development":{
    "distribution":"internal",
    "android":{
       "gradleCommand":":app:assembleDebug"
    },
    "ios":{
      "buildConfiguration":"Debug"
    }
   },
   "preview":{
    "distribution":"internal"
   },
   "production":{}
  },
  "submit":{
    "production":{}
  }
}

在使用 monorepo 等情况下，您的项目可能需要一些额外配置。请阅读本指南，了解如何进一步配置构建配置文件。

eas.json 是一个基于文本的配置文件，使用标准 JSON 语法。文件中包含一个名为 build 的顶级字段。该字段包含一个 JSON 对象，其中包含定义应用程序构建配置文件的所有配置。构建配置文件是一组命名的配置选项，用于描述创建特定类型构建（如内部分发或应用商店发布）所需的参数。

构建下的 JSON 对象包含多个配置文件。默认情况下，提供开发、预览和生产三个构建配置文件。开发配置文件用于包含开发工具的调试构建，主要用于开发和测试。预览配置文件不包含开发工具，用于在类似生产环境中测试应用程序时与团队共享的构建。最后，生产配置文件用于提交给应用商店的发布构建。

您可以在构建字段下为特定类型的构建定义其他自定义配置文件，以最适合您的项目和团队需求。此外，每个配置文件还可以为 Android 和 iOS 设置特定平台配置。

在 EAS Build 上运行构建

任何类型的构建都可以通过单个命令触发。例如，您可以使用预览配置文件与团队共享应用程序进行测试：

eas build --profile preview --platform all

使用 --platform all 选项可以同时为 Android 和 iOS 构建。

将分发字段设置为 "内部 "的构建配置文件（如前面的 eas.json 配置示例所示）会将 EAS Build 配置为提供可共享的 URL。构建完成后，可与队友共享该 URL 以进行内部分发。通过使用 URL，团队中的任何成员都可以将应用程序下载到自己的设备上。

在项目的开发生命周期内，您可以随时修改构建配置文件。在某些情况下，额外的配置可能是必需的或有用的，比如在项目中在 monorepo 内部或在不同配置文件之间共享配置。

通过 CI，您可以及早获得新增功能的反馈，迅速发现问题所在，并节省时间

正确配置并正常运行的 CI 提供商可为您在发布应用程序新版本时节省大量时间。

GitHub UI 报告 CircleCI 作业的状态，示例来自 React Native 代码库

通过事先发现错误，您可以减少审核 PR 所需的工作量，保护您的产品免受回归和错误的影响，这些错误可能会直接降低您的收入。

有了 EAS Build 这样专为 Expo 和 React Native 量身定制的托管服务，JavaScript、Android 和 iOS 依赖关系的缓存就能自动完成。您无需为缓存配置构建步骤，所有构建工作默认情况下都会加速。

有兴趣改进你的 React Native 应用程序吗？

我们是 React Native 的 Facebook 官方合作伙伴。我们已经在 React Native 项目 上工作了 5 年多，为客户提供了高质量的解决方案，并为 React Native 生态系统做出了巨大贡献。我们的 开源项目 每天都在帮助成千上万的开发人员应对挑战，让他们的工作变得更加轻松。我们的 React Native 开发公司 提供广泛的服务。

如果您需要 React Native 或跨平台开发方面的帮助，请联系我们。我们很乐意为您提供免费咨询。

www.deepl.com 翻译

avatar
文章
阅读
粉丝