Lerna 分布式任务执行DTE实战指南用 Nx Cloud 并行化加速 CI 最坏情况【免费下载链接】lernaLerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.项目地址: https://gitcode.com/gh_mirrors/le/lerna当仓库核心代码变更导致所有任务都必须在 CI 中重跑时缓存和--since都无法继续优化唯一的出路是增加 agent 任务并高效并行化。本篇指南围绕 Lerna 官方文档《Distribute Task Execution (DTE)》展开讲解从按类型分桶binning到Nx 分布式任务执行的演进逻辑完整演示 main job 与 agent job 的 CI 编排流程、--concurrency在分布式场景下的传播机制并深入 Lerna 源码lerna run底层由 Nx 驱动的实现与仓库nx.json配置帮助你掌握一套可复制、可调试的分布式 CI 提速方案。为什么需要分布式任务执行缓存救不了最坏情况Lerna 通过 缓存任务结果 和--since标志可以大幅缩短日常 CI 时间--since只运行受影响的包及其依赖缓存则让相同输入的任务瞬间命中并回放结果。但这两项能力都无法处理最坏场景——当仓库核心位置的代码被修改CI 中每一个任务都必须真实执行时唯一能提升性能的手段就是增加更多 agent job机器/运行环境把任务高效地并行化。这里要特别澄清一个概念边界Lerna 自身的缓存与任务调度能力来自 Nx。官方在缓存文档中明确说明Lerna 和 Nx 在任务运行、缓存等方面可以互换使用。当我们说 Lerna 可以缓存构建时我们是指 Lerna 借助 Nx 实现缓存。分布式任务执行同样如此——Lerna 的lerna run命令在默认情况下useNx不为false会把任务委托给 Nx 的任务运行器与 Nx Cloud 编排器。朴素方案按任务类型分桶binning及其短板最直观的并行化思路是按任务类型拆分一台 job 跑所有测试、一台跑所有构建、第三台跑所有 lint。这种策略称为binning分桶。难点在于依赖关系——例如测试任务依赖构建产物此时你必须设计某种机制保证构建产物先就绪。一个典型的 binning 拓扑如下测试任务被推迟到所有必要构建产物就绪之后而构建与 lint 任务可以立即开始。binning 的核心缺陷在于负载不均衡导致的空闲时间某类任务一旦先跑完对应 job 就空转等待整体墙钟时间受最慢的桶支配。Nx 的分布式任务执行DTE正是为了解决这个缺陷而生。Nx DTE 的工作原理按平均耗时逐任务分配Nx 的分布式任务执行把空闲时间压缩到理论最小值其核心机制是逐任务调度Nx Cloud 根据每个任务的平均运行时长把单个任务动态分配到合适的 agent job 上而不是粗粒度地按类型分桶顺序保证Nx 基于仓库的项目依赖图project graph保证任务按正确依赖顺序执行构建任务一定先于依赖它的测试任务分布式缓存Nx 使用分布式缓存确保前序任务产生的构建产物出现在每一个需要它的 agent job 上agent 之间可以互相复用产物。启用 DTE 之后任务图不再按类型分桶而是由调度器在多个 agent 上均匀铺开分布式方案还有一个常被低估的收益调试体验与单 job 运行完全一致。因为 Nx 会在 main job 上通过分布式缓存回放所有 agent 的日志与构建产物你在主 job 上看到的输出、能访问到的产物文件和所有 CI 都在一台机器上跑时别无二致。快速开始两步启用 DTE启用分布式任务执行只需两步连接 Nx Cloud在 CI 工作流中开启 DTE。第一步在仓库根目录执行以下命令会启动一个交互式的、基于浏览器的连接流程将当前工作区与 Nx Cloud 绑定连接后 Nx Cloud 才会作为编排者介入npx nx connect-to-nx-cloud第二步修改你的 CI 工作流配置加入分布式编排所需的步骤详见下文CI 执行流程。各 CI 提供商的配置参考每个组织管理 CI/CD 流水线的方式各不相同官方无法覆盖所有情况但给出了在主流 CI 提供商上为 Nx CLI 配置 DTE 的示例这些示例可以很直接地改造成 Lerna 命令——把nx run-many或nx affected换成lerna run即可配置总览Azure Pipelinesmonorepo CI 配置Circle CIGitHub ActionsJenkinsGitLabBitbucket Pipelines有一个重要前提需要铭记只有可缓存的操作才能被分布式执行因为任务结果必须在 main job 上回放。判断标准是任务是否无副作用——给定相同输入总能产生相同输出。例如会真实访问后端 API 的 e2e 测试就不适合缓存和分布式执行因为后端状态可能影响测试结果。CI 执行流程main job 与 agent job 的分工DTE 可以运行在任何 CI 提供商之上。职责划分非常清晰你在自己的 CI 系统中负责启动 jobNx Cloud 负责协调这些 job 协同工作。你需要创建两类 job一个 main job主任务决定要执行什么多个 agent job代理任务实际执行任务。main job 执行流程main job 与未做任何分布式的 CI 看起来几乎一样只需在开头调用npx nx-cloud start-ci-run在结尾可选调用npx nx-cloud stop-all-agents# 协调所有 agent 执行任务 - npx nx-cloud start-ci-run # 在这里运行任意你想执行的命令 - lerna run lint --sincemain lerna run test --sincemain lerna run build --sincemain # 停止可能仍在运行的 agent - npx nx-cloud stop-all-agentsagent job 执行流程agent job 的配置极简——运行一个长驻的start-agent进程该进程会持续执行与本次 CI run 关联的所有任务直到 Nx Cloud 通知它终止# 等待任务下发并执行 - npx nx-cloud start-agent必须遵守的约束main job 与 agent job 必须拥有相同的运行环境和相同的源码并且应大致同时启动一旦 main job 完成所有 agent 都会被停止重要认知Nx Cloud agent 不是一台机器而是一个运行在机器上的长驻进程。Nx Cloud 不替你管理 agent——在 CI 配置中启动 agent 是你的职责参考上文各提供商示例。Nx Cloud 的编排者角色Nx Cloud 扮演的是编排者orchestratormain job 告诉 Nx Cloud想运行什么Nx Cloud 把这些任务分发到各个 agent 上并自动在 agent 之间、agent 与 main job 之间搬运文件。最终效果是当lerna run build --sincemain在 main job 上完成时所有在 agent 上产生的文件产物都被复制回 main job——就好像 main job 本地构建了一切。并行度控制--concurrency如何传播到 agent--concurrency是 Lerna 的全局选项适用于所有命令在 libs/core/src/lib/cli.ts 中定义为type: number默认值为os.cpus().length即本机 CPU 核数描述为Lerna 并行化任务时使用的进程数。在分布式场景下--concurrency会被传播到每个 agent。例如npx lerna run build --sincemain --concurrency3 --dte这条命令告诉 Nx Cloud在每个 agent 上最多并行运行 3 个 build 目标。因此如果你有 10 个 agent跨全部 agent 最多会有 30 个 build 并行执行。注意--dte是 Nx Cloud 侧的标志与 Lerna 的lerna run命令组合使用即可触发分布式执行。尽可能并行地提交命令除了单命令内的并发你还要尽可能多地并行提交命令。例如下面这种串行写法是更差的选择- lerna run lint --sincemain - lerna run test --sincemain - lerna run build --sincemain而并行提交三条命令shell 的后台符号更优- lerna run lint --sincemain lerna run test --sincemain lerna run build --sincemain后者的价值在于三条命令被同时调度某个 agent 找不到 build 可做时会立即转向执行 test 和 lint。结果就是更高的 agent 利用率与更短的 CI 时间。源码印证lerna run如何把任务交给 Nx从源码看Lerna 的lerna run命令在useNx不为false时直接委托给 Nx 的任务运行器。libs/commands/run/src/index.ts 中execute()方法的分派逻辑清晰展示了三条路径this.options.useNx ! false→runScriptsUsingNx()默认路径由 Nx 驱动useNx false且parallel→ 包内并行legacy task runneruseNx false且拓扑排序 → 按依赖拓扑顺序执行legacy task runner。在默认的runScriptsUsingNx()中libs/commands/run/src/index.tsLerna 会根据--since等过滤条件计算出projectsWithScript若只剩单个项目且脚本唯一调用 Nx 的runOne否则调用 Nx 的runMany把目标targets与项目列表交给 Nx 任务运行器。同时 Lerna 会读取nx.jsonnx.json中的targetDefaults/targetDependencies来判断是否存在自定义 Nx 配置若存在任务依赖由 Nx 自动推导若不存在则模拟 Lerna 的传统默认行为mimicLernaDefaultBehavior即仅按拓扑顺序跑同一脚本。这就是为什么 DTE 场景下的依赖顺序、分布式缓存都由 Nx 保证——Lerna 在此扮演的是入口 过滤 参数透传的角色。另外libs/commands/run/src/command.ts 定义了lerna run的常用参数如--parallel无限并发 流式输出、--stream按包前缀流式输出、--no-bail遇错继续、--no-prefix关闭输出前缀等其中--parallel在传给 Nx 时会被映射为极大并发数默认路径下为 999与 pMap 的传统默认行为保持一致。缓存是 DTE 的地基确保任务可缓存正如前文强调只有可缓存的操作才能被分布式执行。要让任务进入分布式执行第一步是在nx.json的targetDefaults中声明任务可缓存。参考仓库自身的 nx.json其test目标声明了inputs、dependsOn: [build]与cache: true最小示例为{ targetDefaults: { build: { cache: true }, test: { cache: true } } }如果你还没有nx.json可以运行npx lerna add-caching来生成。缓存任务的输出包括终端输出和任务在output目录中创建的文件两部分当缓存命中时Lerna经由 Nx会把这些输出原样回放到本地或分布式环境。关于缓存输入inputs与输出目录outputs的精细调优可进一步阅读 How Caching Works。相关示例仓库社区中有两个与本主题强相关的公开示例可作参考vsavkin/interstellar演示仅通过一次小的配置变更就让 CI 提速 16 倍是理解 DTE 收益的直观案例vsavkin/lerna-dte专门演示 Lerna Distributed Task Execution 组合用法的示例仓库包含完整的配置与 CI 编排示例。总结DTE 的最佳实践清单缓存优先先通过nx.json的targetDefaults声明可缓存任务只有无副作用、可回放的任务才能被分布式执行连接 Nx Cloud运行npx nx connect-to-nx-cloud完成工作区与编排器的绑定main job开头调用npx nx-cloud start-ci-run用lerna run script --sincemain声明任务结尾调用npx nx-cloud stop-all-agentsagent job每个 agent 只运行npx nx-cloud start-agent长驻进程并确保与 main job 环境、源码完全一致并行最大化用--concurrencyN控制单 agent 内并发用 shell并行提交多条lerna run命令放心调试分布式缓存保证 main job 能回放全部日志与产物调试体验等同单机 CI。通过这套组合拳Lerna 仓库在核心改动引发全量任务的最坏情况下也能借助 Nx Cloud 的任务级调度与分布式缓存把 CI 时间压缩到接近理论下限。【免费下载链接】lernaLerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.项目地址: https://gitcode.com/gh_mirrors/le/lerna创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考