IntelliJ Infrastructure 团队如何借助 TeamCity 将构建执行时间缩短 30%

挑战：为数百名开发者扩缩 CI/CD

开发者众多的庞大团队会不断推送更改，因此维护快速、可靠且可扩缩的 CI/CD 管道并非易事。IntelliJ Infrastructure 团队需要一种能够处理大规模工作的解决方案，这种解决方案应当能够每天运行数千个构建，而不会过多占用可用资源。他们还需要智能自动化来最大程度减少人工干预，同时确保交付高质量代码。

此外，对各种基础架构环境（包括本地部署、AWS、macOS、Linux 和 Windows 代理）的支持也至关重要。为了保持高代码质量，团队还必须管理数十万项自动化测试，同时尽可能减少不稳定测试失败的情况。

TeamCity 是一款由 JetBrains 开发的功能强大的 CI/CD 解决方案。事实证明，它是正面应对相关挑战的完美解决方案。

“我们在 TeamCity 中构建 IDE 以及与其相关的一切，例如内部服务、统计服务等。我已经非常习惯 TeamCity，它使用起来得心应手：你可以用它做任何事情。”

— Dmitry Panov，IntelliJ Infrastructure 技术主管

TeamCity 如何帮助 IntelliJ Infrastructure 团队

Safe Push

目前，大型 IntelliJ 团队的流程让每名开发者都能在代码准备就绪后立即推送代码，而不是将所有更改累积在一个分支中并等待一起进行测试。

为了支持此工作流，IntelliJ Infrastructure 团队实现了 Safe Push 机制，它本质上是 TeamCity 中的一组复合构建配置。对于用户而言，流程非常简单：他们只需通过其 IDE 推送更改即可。

在后台，专用的内部服务会分析 Safe Push 更改集，并使用 TeamCity REST API 触发测试更改所需的构建。它还会重新启动失败的构建以重试不稳定测试。

由于 Safe Push 测试构建可以包含多达 700,000 项测试，通过实现重用成功的构建，TeamCity 帮助显著加快了 Safe Push 的速度并降低了成本。构建重用功能可以重用工件、依赖项和测试结果，而无需从头开始构建所有内容。这提高了构建效率、加快了 CI/CD 管道速度并减少了资源消耗。

通过重用构建节省资源

构建重用是团队认为特别实用的 TeamCity 功能之一。以下是典型 TeamCity 构建链的样子。

当测试链首次尝试未通过时，Safe Push 机制会再重试两次以确保确实存在问题。

我们来设想一种典型的推送，看看构建重用如何优化重试。在首次尝试中，将执行链中的全部 329 个构建。319 个通过，但 10 个失败，因此链会重新运行。这一次，仅运行 10 个失败的构建，其余将全部重用。又有 6 个通过，但还剩一部分。因此在第三次尝试时，只需要运行剩下的 4 个，而 325 个将被重用。

这大大减少了构建代理的负载，并显著缩短了重试时间。借助构建重用，将不再需要运行三次完整尝试（每次大约需要 3 个小时），这将执行时间缩短了约 30%。

以无缝性能支持大规模工作

IntelliJ 团队每天都会为超过 180 位唯一身份用户运行超过 158,000 个构建，因此效率至关重要。得益于 TeamCity 的构建重用功能：

• 当测试失败时，75％的构建不需要完全重新运行。
• 重试次数平均降低 30%，显著化解了瓶颈。
• 由于可以同时运行超过 90 项 Safe Push 测试，开发者可以持续合并而不会互相阻碍。

Kotlin DSL

IntelliJ Infrastructure 团队通过 Kotlin DSL 管理 TeamCity。借助 Kotlin DSL，您可以获得完整编程语言的所有优势，以及旨在以代码形式构建管道的 DSL 的优势。

目前，TeamCity 实例包含超过 2,000 个项目、15,000 个构建配置和近 300 个 VCS 根。除了 Kotlin DSL，团队无法想象还能使用哪种其他语言来管理如此庞大的实例。

“我们还有将近 350 项单元测试专门针对 Kotlin 设置本身。使用 YAML 的话，我就不会这么做。”

— Dmitry Panov，IntelliJ Infrastructure 技术主管

代理管理

TeamCity 强大的代理管理功能使扩缩 CI/CD 管道变得轻松高效。与需要复杂变通方法（例如锚点、go-to 语句和手动重试逻辑）的基于 YAML 的 CI/CD 系统不同，TeamCity 通过内置代理编排简化了此流程。

对于使用 AWS 的团队，TeamCity 可以无缝集成云基础架构，支持根据需求自动启动和管理代理。例如，您可以配置 TeamCity 以在任何指定情况下启动所需数量的代理，并在空闲时将其关闭，从而确保最高效地利用资源。

相比外部插件可能会引入兼容性问题并需要额外故障排查的其他解决方案，这种精度的代理控制更加直观。

在规模上，TeamCity 可以处理大量工作负载，支持超过 10,000 个构建的队列，并动态管理多达 5,000 个构建代理。TeamCity 的一项突出功能是支持使用抢占式 AWS 实例。如果 AWS 将某一实例回收，TeamCity 可以自动在另一个代理上重新启动构建，从而防止中断并确保顺利执行。

团队跟踪的指标

在每天都要为数百名开发者管理涉及数万个构建的 CI/CD 平台时，跟踪重要程度最高的指标非常重要。TeamCity 提供了许多开箱即用的诊断工具和指标。TeamCity 还支持以 Prometheus 格式导出指标，因此您可以为更高级的用例构建自定义仪表板。

“TeamCity 为我们提供了一些基本要素，例如构建或测试的统计数据。然后，我们可以在这些基本结构上构建更复杂的内容。”

— Aleksei Smirnov，.NET Infrastructure 团队软件开发者

以下是 IntelliJ Infrastructure 团队在使用 TeamCity 优化其 CI/CD 流程方面密切关注的主要指标。

每日构建数量

团队每天会监控大约 158,000 个构建，以了解工作量和性能。虽然构建数量本身并非团队密切关注的内容，但它仍然是预测构建代理工作量的重要指标。

Safe Push 并发

每时每刻都会有 80-90 项 Safe Push 检查在同时运行。团队必须跟踪每项 Safe Push 检查所耗时间 – 执行速度越快，构建运行速度就越快。

构建重用效率

团队会分析重试期间重用的构建数量，从而减少冗余执行的需要并节省资源。

测试执行

IntelliJ TeamCity 项目中的一个复合构建内有近 700,000 项测试。

对于每个 Safe Push 链，团队会跟踪超过 700,000 项测试以识别任何故障。团队还会测量测试的不稳定性，自动重试失败的测试并将不稳定的测试静默，供进一步调查。

团队正在努力改进的指标之一是成功运行所需的尝试次数。这将帮助他们节省每次运行消耗的资源和时间。

代理利用

团队监控超过 5,000 个 AWS 和物理构建代理，他们通过诸如构建重用等功能优化资源分配，借此将构建时间缩短了约 30%。

TeamCity 的可改进之处

虽然 IntelliJ Infrastructure 团队每天都会使用 TeamCity 执行大量任务，并注意到它有助于解决许多问题，但他们仍希望加入一些功能。

团队特定功能

虽然 TeamCity 允许访问组织内的所有构建链和项目，但开发者通常需要更集中地查看与其相关的构建。例如，理想情况下，使用 PyCharm 的开发者应只看到 PyCharm 特定的构建、测试和配置，而无需浏览不相关的项目。

简化的仪表板仅显示相关的构建配置、测试和静默测试，这将显著提高实用性。团队曾尝试通过创建基于 Grafana 的解决方案来解决此问题，但 TeamCity 内集成度更高、更加人性化的方式成为最理想的方案。

静默测试管理

团队认为静默管理系统对于 TeamCity 而言大有裨益。鉴于自动化测试量巨大，某些测试不可避免地需要静默运行。虽然 TeamCity 提供了静默测试功能，但仍有测试在静默运行后被忘记的问题，这让需要使用它的其他同事的工作变得复杂。

借助专用的静默管理系统，团队可以轻松查看、管理和跟踪与其项目相关的静默测试，这有助于提供更好的所有权和透明度。

结论

IntelliJ Infrastructure 团队已利用 TeamCity 大规模掌握了 CI/CD 效率，TeamCity 可以简化构建、优化资源使用并显著缩短执行时间。通过利用 Safe Push、构建重用和自动化测试重试，他们将构建执行时间缩短了 30%，确保 700-800 名开发者可以无缝地推送更改。

IntelliJ Infrastructure 团队的故事证明 TeamCity 不仅仅是一款 CI/CD 工具 – 它是大规模软件开发的支柱。