Gradle Build Tool 是一款流行的开源构建自动化工具,数百万开发者将其用于构建、测试和部署软件。TeamCity 是一种通用 CI/CD 解决方案,可以实现灵活的工作流、协作和开发做法。
在本案例研究中,我们将深入探索 Gradle Build Tool 如何使用 TeamCity 每天运行数以万计的构建,同时将失败率保持在控制之下。
“十多年来,我们一直选择 TeamCity 作为我们的 CI 系统。它直接提供所有功能,我们也很欣赏它的可靠性,我们喜欢使用 Kotlin DSL 配置我们的构建管道。”
— Piotr Jagielski,Gradle Build Tool 工程副总裁
Gradle, Inc. 推出的 Gradle Build Tool 是最受欢迎的开源构建自动化工具之一,Gradle Enterprise 是提高开发者工作效率的领先解决方案平台。Gradle 总部位于加州旧金山,在 30 个国家/地区拥有约 200 名员工,为全球数百万开发者构建开源工具和企业平台。
Gradle 有 100 多名工程师参与开发两个主要代码库 – Gradle Build Tool 和 Gradle Enterprise。每一个都包含数百万行代码。公司将 TeamCity 用于两个代码库,但本案例研究将重点关注 Gradle Build Tool 开发。
过去 10 年,Gradle Build Tool 团队一直依赖 TeamCity 执行 CI/CD 流程。在此期间,团队从未错过 TeamCity 更新。定期更新使团队始终拥有最新、功能最丰富的产品版本。
Gradle Build Tool 团队使用 Git 和 GitHub 作为版本控制系统。他们使用 Java、Kotlin 和 Groovy 编写代码,将自己的产品 Gradle Build Tool 用于构建自动化、将 Gradle Enterprise 用于构建加速和失败分析。团队依靠 TeamCity 作为 CI 解决方案,用于运行他们不希望在本地运行的任何任务:构建、部署、cron 作业、代理配置等。
Gradle Build Tool 拥有全面的测试套件,可验证产品在不同操作系统、Java 版本和其他组件上的运作状况。完整的“发布就绪”构建包含超过 15 万个测试。另外,更改必须成功通过性能套件才能集成到主分支。这需要具有数百个构建代理的复杂 CI 环境。
Gradle 使用 Windows、Linux 和 macOS 构建代理。约一半代理为裸机。团队还使用 Amazon EC2 Spot 代理。这有助于 Gradle 在高需求期间保持构建速度。
得益于 TeamCity 的内置 Spot 实例支持,团队从未遇到代理断开连接的问题。如果一个 Spot 实例消失,TeamCity 会自动重启构建。
Gradle Build Tool 的 TeamCity 设置公开提供,任何人都可以查看。主 (master
) 分支由大约 500 个构建配置组成,这些配置位于非常复杂的链中。如 Piotr 所说:“Gradle 非常广泛地使用构建链。事实上,我们根本离不开它们。”
由于链的复杂性,Gradle 依赖于 Kotlin DSL 配置其管道。
Gradle 具有 200 个固定构建代理和 200 个额外弹性 EC2 代理,用于管理通过云配置文件连接的峰值。每周运行构建的总时间为 283 天(6,792 小时)。
同时,每月约有 1,636 天由 TeamCity 优化。智能算法让 TeamCity 可以决定是否由于另一构建已在同一仓库提交上运行而不应执行构建。
Gradle 使用构建链,TeamCity 通过重用构建帮助团队节省大量构建时间。
由于 TeamCity 能够提供与 Prometheus 兼容的服务器指标,团队可以自动将构建数据导出到 Grafana 进行进一步的可视化和分析。团队可以跟踪排队构建等待时间、TeamCity 代理使用情况、队列长度和连接代理数量等指标。
因此,如果使用率过高,团队可以决定是否需要购买更多构建代理。
尽快提供反馈是任何 CI 解决方案的核心。监控反馈时间有助于 Gradle 开发者工作效率团队了解工程师在拉取请求合并之前需要等待多长时间。
为了进行跟踪,Gradle Build Tool 团队会密切关注 Trigger
构建 – 一种复合构建,聚合由快照依赖项组合的其他多个构建的结果,并将其在一个位置呈现。
反馈时间取决于拉取请求的复杂性。简单 PR 在 10 分钟内即可获得反馈,而在更复杂的情况下,最长可能需要一个小时。由于 Gradle 开源,来自 GitHub 社区的所有拉取请求都会经过相同的构建流程。
出于成本考虑,并非每个提交都会触发构建。开发者可以通过注释相关拉取请求来轻松触发构建,机器人将调用 TeamCity API 触发。
master
和 release
等分支的处理方式有所不同。在这些分支上的任何推送都会触发 TeamCity 构建。
Kotlin DSL 在帮助 Gradle 团队管理构建依赖项的复杂性方面发挥了巨大作用。通过将项目配置存储为代码,团队可以有效跨项目复制构建逻辑,一致地将更新应用于多个配置,并系统地管理管道。
在 Kotlin DSL 的帮助下,团队可以更加轻松地生成和测试构建依赖项。团队为几乎所有项目使用 Kotlin DSL,并禁用了 Web UI 编辑。
TeamCity 可以为 Gradle 加快整个 CI/CD 流程。在 TeamCity 的帮助下,Gradle Build Tool 每天成功运行 30,000 个绿色构建,同时将失败率保持在控制之下。
TeamCity 功能丰富,是 Gradle 团队的一站式商店。它具备其他工具所拥有的所有功能,还有许多其他工具没有的功能。
Kotlin DSL 为 Gradle Build Tool 提供了前所未有的灵活性,使团队能够快速创建和测试复杂的构建链。团队还对 Kotlin DSL 配置文件进行测试。Gradle 的 TeamCity 配置开源,并托管在 GitHub 上。
最后,Gradle Build Tool 团队非常重视 TeamCity 的可靠性。团队在 TeamCity 推出新版本后立即升级,很少遇到任何问题。TeamCity 管理着超过 400 个构建代理,但团队几乎从未遇到任何连接或构建代理问题。
Gradle Build Tool 团队致力于确保其基础架构可随团队发展而扩展。即使未来团队规模增加一倍,Gradle 也将维持当前反馈时间或使反馈时间进一步减少。
为了实现这一远大目标,Gradle Build Tool 团队计划全面采用开发者工作效率工程做法、提高自动化程度以消除人为干预,并在整个 CI/CD 流程中添加更多构建代理。
Ivan Babiankou,Picnic 高级软件工程师
我们正在为所有 CI 用例寻找托管解决方案。 除此之外,我们需要自托管代理来控制正在运行的软件以及正在使用的确切工具。带有自托管代理的 TeamCity Cloud 提供了一个量身定制的解决方案,我们包含 300 多名工程师的团队愉快地使用了该解决方案,我们的生产力被推向新水平。
Phillip Peterson,高级发布工程师
有一个产品我们在内部使用了很长时间。 我们尝试过换到不同的竞品,但都没有成功。 然后,一些来自另一家游戏公司的同行说,‘我们使用过 TeamCity。’ 我们调查了一下,发现 TeamCity 可以解决我们的很多问题。
Yuri Trufanov,技术平台执行技术总监
我们最终使用的是一种混合云解决方案,其中包括 TeamCity Cloud Profiles 和 AWS。 此外,我们还有用于构建代理的本地部署计算机。 这种组合能够全天容纳任意数量的构建,还为下班时间提供了基线代理数量。 我们可以在任何需要的地方运行任何需要的东西。