尝试以扩展 VS Code 中的代理模式!

改进 CI 构建时间

2020 年 2 月 18 日,作者:Ethan Dennis,@erdennis13 和 João Moreno,@joaomoreno

Visual Studio Code 是一个庞大项目,包含许多活动组件和活跃的参与者。我们展示了我们如何积极使用 Azure Pipelines,通过维护我们的构建和持续集成基础设施来遵循良好的工程实践。在这篇博文中,我们将讨论我们如何使用 Azure Pipelines Artifact Caching Tasks 大幅缩短 CI 构建时间。

我们在之前的一篇博文中描述了我们如何将 CI 构建时间缩短 33%。这是通过使用自定义构建任务实现的,这些任务缓存 VS Code 使用的 node 模块,而不是在构建时解析包。尽管我们对这种性能提升感到满意,但我们希望看看我们构建的缓存任务还能再提升多少。

当我们上次讨论 CI 工程时,我们的目标平台涵盖 Windows、macOS 和 Linux。而截至今天,VS Code 针对更多样化的平台,例如用于其远程服务器组件的 Arm64 和 Alpine Linux。总共有八个不同的目标,它们都共享通用的构建步骤。这篇博文概述了我们如何利用缓存任务来减少 CI 重复并进一步缩短构建时间。

改进空间

那么,所有构建作业中的共同步骤究竟是什么?每个构建目标都包含一组类似的步骤。从宏观上看,每个作业都必须:

  1. 恢复依赖项
  2. 整理 TypeScript 和 JavaScript 代码
  3. 将 TypeScript 编译为 JavaScript
  4. 运行单元测试套件
  5. 运行集成测试套件
  6. 打包 VS Code

我们的缓存任务显然是加速“恢复依赖项”步骤的选择。例如,如果 package-lock.json 文件很少更改,为什么还要运行耗时的 npm install 步骤,而您可以缓存上次运行的结果呢?由于我们之前已经讨论过缓存包,所以这篇博文的有趣之处在于我们如何将缓存应用于其他步骤。

由于代码整理和编译是平台无关的,这些步骤可以很容易地由一个构建代理运行,并将其结果共享给其他平台相关的代理,而不是让所有代理重复执行这项工作。我们创建了一个 Linux 构建代理,其唯一职责就是:恢复包、整理和编译源代码。我们所要做的就是将结果共享给其他代理。

缓存一切

为了在不同构建代理之间共享缓存结果,我们需要平台无关的缓存,而这最初是缓存任务不支持的。因此,在 Azure Pipelines Artifact Caching Tasks 中添加了一个可选的 platformIndependent 参数。

以下是 VS Code 如何使用 platformIndependent 参数:

- task: 1ESLighthouseEng.PipelineArtifactCaching.RestoreCacheV1.RestoreCache@1
  inputs:
    keyfile: keyfile
    targetfolder: target
    vstsFeed: $(ArtifactFeed)
    platformIndependent: true

缓存 node 模块时,使用 package-lock.json 文件作为缓存键是合理的。当此文件更改时,我们必须使缓存失效。缓存编译输出时,整个代码库必须作为缓存键。为了简化,我们决定使用 HEAD 提交作为缓存键,因为新的提交必然会创建一个新的缓存条目。这对于我们的目的来说很好用,因为尽管单个构建跨多个构建代理运行,但它始终针对单个提交运行。

另一个缺失的功能是每个构建作业能够创建多个缓存。我们现在发现自己在两个缓存(node 模块、编译)之间来回切换,却没有办法单独处理每个缓存。缓存任务会输出一个名为 CacheRestored 的环境变量,可以用于乐观地跳过构建任务。这个环境变量在与单个缓存交互的构建中表现出色,但在处理多个缓存时就不那么理想了——让我们搞不清楚 CacheRestored 指的是哪个缓存。因此,在 Azure Pipelines Artifact Caching Tasks 中再次添加了一个可选的 alias 参数。

以下是我们如何使用 alias 参数:

- task: 1ESLighthouseEng.PipelineArtifactCaching.RestoreCacheV1.RestoreCache@1
  inputs:
    keyfile: "yarn.lock"
    targetfolder: "node_modules"
    vstsFeed: "$(ArtifactFeed)"
    alias: "Packages"

- script: |
    yarn install
  displayName: Install Dependencies
  condition: ne(variables['CacheRestored-Packages'], 'true')

在这里,别名 Packages 会附加到环境变量输出中,这使得我们能够在单个构建作业中缓存 NPM 包和编译输出。我们终于能够对许多 CI 工作进行去重,现在这些工作可以只执行一次,并在平台特定的代理之间共享。

考虑到一个特定的用例:构建重新提交,仍然存在最后一项优化空间。有时我们必须在之前已构建的提交上重新触发 VS Code 构建,因为测试可能不稳定或者某些代理可能随机失败。理想情况下,共享代理不会恢复或重新编译公共代码,而是将工作委托给依赖平台的代理来执行。我们注意到的问题是,编译缓存包非常大,恢复它们需要大约 8 分钟——完全是徒劳的,因为如果缓存存在,共享代理就会直接放弃控制。因此,Azure Pipelines Artifact Caching Tasks 中再次添加了一个新的可选 dryRun 参数,它允许我们检查缓存包是否存在而不恢复它——有效地为我们的构建重新提交节省了 8 分钟。

在我们的构建中使用 dryRun 参数如下所示:

- task: 1ESLighthouseEng.PipelineArtifactCaching.RestoreCacheV1.RestoreCache@1
  inputs:
    keyfile: commit
    targetfolder: output
    vstsFeed: "$(ArtifactFeed)"
    dryRun: true

- script: |
    npm run compile install
  displayName: Install Dependencies
  condition: ne(variables['CacheExists'], 'true')

请注意,这还引入了一个新的 CacheExists 变量,它与 dryRun 参数协同工作。

结果

这些更改实施后,我们看到了总构建时间的显著缩短。下表显示了 VS Code 针对的每个平台的总构建时间变化:

平台 之前 之后 节省时间
Windows 58 分钟 44 分钟 24%
Windows 32 59 分钟 46 分钟 22%
Linux 38 分钟 23 分钟 39%
macOS 68 分钟 42 分钟 38%
Linux Arm 22 分钟 21 分钟 5%
Linux Alpine 23 分钟 26 分钟 -13%

VS Code before and after build times

Linux Arm 和 Linux Alpine 目标仅构建 VS Code 远程服务器组件,因此它们最初的构建时间已经足够好。但由于它们与标准 VS Code 客户端平台共享一些通用任务,我们决定让它们依赖通用构建代理。这导致在某些情况下由于开销增加而构建时间略有增加。

构建重新提交得到了显著改善,因为共享代理任务可以完全跳过。例如,以下是 macOS 的一些数据:

平台 之前 之后 节省时间
macOS 68 秒 34 秒 50%

总而言之,我们非常高兴地看到 VS Code 的 CI 构建时间总体上减少了约 50%!最好的消息是,您可以从我们的构建定义中汲取灵感,实现您自己的构建时间改进。

祝缓存愉快,

Ethan Dennis,开发服务高级软件工程师 @erdennis13

João Moreno,VS Code 高级软件工程师 @joaomoreno