持续集成和测试

概述

React 使用全面的 CI/CD 管道，自动进行代码更改的构建、测试和发布。该基础设施可确保代码质量，防止回归，并简化多个分发渠道的发布流程。

CI/CD 管道具有以下几个主要用途

通过自动化测试验证代码更改
为多个发布渠道（稳定版、实验版）构建工件
监控捆绑包大小变化
自动化向 npm 和其他目的地的发布流程
确保跨浏览器和环境的兼容性

来源

CI/CD 工作流架构

React 仓库使用多个 GitHub Actions 工作流协同工作，以实现 CI/CD 管道。

主要工作流概述

主要工作流文件 runtime_build_and_test.yml 处理大部分测试和构建工作。它被组织成多个并行运行的作业以提高效率。

来源

主要 CI 工作流组件

主要的 runtime_build_and_test.yml 工作流包含几个关键作业

作业	目的	触发器
`runtime_node_modules_cache`	集中缓存 node_modules	所有构建
`discover_flow_inline_configs` & `flow`	使用 Flow 进行代码类型检查	所有构建
`check_generated_fizz_runtime`	验证 Fizz 运行时生成	所有构建
`flags`	验证功能标志	所有构建
`test`	在不同配置下运行单元测试	所有构建
`build_and_lint`	构建用于分发的包	所有构建
`test_build`	测试构建的工件	构建完成后
`process_artifacts_combined`	处理构建工件	构建完成后
`check_error_codes`	验证错误代码	构建完成后
`sizebot`	分析捆绑包大小变化	主分支的 PRs

这些作业在各种触发器（拉取请求、推送到主分支、计划运行）下以不同配置运行，以确保全面的测试。

来源

构建系统集成

CI 管道与 React 的构建系统深度集成，为不同的发布渠道生成工件。

构建过程概述

构建系统为每个包创建多个变体

稳定通道构建 (oss-stable)
实验通道构建 (oss-experimental)
Facebook 特定构建 (facebook-www, facebook-react-native)
不同的环境目标（开发、生产）

来源

版本和渠道管理

构建系统动态管理版本

ReactVersions.js 定义了所有包的基础版本号
CI 构建会附加额外的版本信息
- 稳定通道：<版本>-<通道>-<提交>-<日期> (例如，19.2.0-canary-a1c2d3e4-20240301)
- 实验通道：0.0.0-experimental-<commit>-<date>

这允许不同发布渠道拥有独立的版本跟踪，同时保持清晰的血缘关系。

来源

测试基础设施

React 的测试基础设施非常全面，支持多种测试类型在各种配置下运行。

测试类型和覆盖范围

测试类型	描述	配置矩阵
Flow 类型检查	静态类型检查	多个内联配置
单元测试	核心功能测试	多个发布渠道 × 环境 × 变体
DOM 夹具测试	浏览器环境测试	稳定通道
Flight 夹具测试	React 服务器组件测试	实验通道
DevTools 测试	DevTools 特定测试	多个浏览器目标
构建测试	针对构建工件的测试	多种配置

测试在多种配置下运行，以提供广泛的覆盖。

发布渠道：稳定版、实验版、www-classic、www-modern、xplat
环境：开发、生产
变体：启用和未启用特定功能

来源

测试作业执行策略

测试作业使用 GitHub Actions 的矩阵策略并行地在多个配置下运行测试。每个组合也会被分片以分散测试执行，从而加快完成速度。

测试命令接受指定配置的参数

yarn test -r=<channel> --env=<environment> --variant=<boolean> --ci --shard=<shard>

来源

.github/workflows/runtime_build_and_test.yml221-281

专门的测试工作流

除了主要工作流之外，React 还使用专门的工作流来应对特定的测试场景

DevTools 回归测试 (devtools_regression_tests.yml)：测试 DevTools 与多个 React 版本的兼容性
ESLint 插件 E2E 测试 (runtime_eslint_plugin_e2e.yml)：测试 React Hooks ESLint 插件
模糊测试 (runtime_fuzz_tests.yml)：运行随机输入进行可靠性测试

这些补充工作流确保对外围组件和边缘情况进行彻底测试。

来源

捆绑包大小监控

React 使用自动化捆绑包大小监控来防止意外的大小增加。

SizeBot 架构

SizeBot 系统比较基础分支和 PR 分支之间的捆绑包大小，并在 PR 评论中突出显示显著变化。

来源

大小变更阈值

SizeBot 报告变更的阈值不同

关键阈值：变化大于 2%（显著显示）
显著性阈值：变化大于 0.2%（显示在可折叠部分）

它总是报告关键文件（如 React DOM 生产构建）的更改，无论更改大小如何。

报告格式示例

## Critical size changes

| Name | +/- | Base | Current | +/- gzip | Base gzip | Current gzip |
| ---- | --- | ---- | ------- | -------- | --------- | ------------ |
| react-dom/cjs/react-dom.production.js | +1.5% | 125.45 KB | 127.33 KB | +0.9% | 39.25 KB | 39.60 KB |

来源

发布流程自动化

React 使用自动化工作流来简化跨多个渠道的发布流程。

发布渠道

React 维护多个具有不同 CI/CD 管道的发布渠道

渠道	目的	发布节奏	工作流
实验版	不稳定，新功能	每夜构建	`runtime_prereleases_nightly.yml`
Canary	下一个稳定版的预发布	每晚/手动	`runtime_prereleases_manual.yml`
稳定	生产版本发布	手动	`runtime_releases_from_npm_manual.yml`

每个渠道都有一个特定的 npm 标签和版本格式。

来源

自动化发布流程

使用 download-build-artifacts.js 下载构建工件
准备带有适当版本信息的包
发布前使用测试夹具测试包
使用适当的标签发布到 npm

对于每晚发布，这是由计划触发的。对于其他发布，它通过工作流调度手动触发。

来源

Meta 特定的工件处理

除了 npm 发布之外，React 还自动化了向 Meta 内部仓库的交付

Facebook WWW：处理并提交到 builds/facebook-www 分支
Facebook fbsource：处理并提交到 builds/facebook-fbsource 分支

runtime_commit_artifacts.yml 工作流处理此过程，并对内部使用的版本字符串、文件格式和签名进行特殊处理。

来源

CI 问题排查

常见 CI 问题和解决方案

问题	可能原因	解决方案
Flow 检查失败	代码中的类型错误	检查 Flow 输出以查找特定错误
测试失败	功能损坏	检查测试输出以查找特定测试失败
构建失败	语法错误、依赖问题	检查构建日志以查找错误
SizeBot 警告	大小显著增加	优化代码或说明大小增加的理由
工件处理失败	文件格式不正确	检查工件处理日志

调查 CI 失败时，请检查失败的具体作业及其在 GitHub Actions 界面中的相关日志。

在推送前进行本地测试

运行 yarn flow 以检查类型
使用适当的参数运行 yarn test 以在本地运行测试
运行 yarn build 以检查构建问题
运行 yarn lint 以检查 linting 问题

来源

总结

React 的持续集成和测试基础设施通过以下方式提供全面的质量保证

跨多个配置和环境的自动化测试
捆绑包大小监控以防止性能退化
并行执行以高效利用资源
为多个发布渠道自动化工件构建
精简发布流程至 npm 和 Meta 内部仓库

该基础设施使 React 团队能够保持高代码质量和发布节奏，同时支持多个分发渠道和内部消费者。