将Airbnb的JVM Monorepo迁移到Bazel
[
[
Press enter or click to view image in full size
按回车或点击以全尺寸查看图片
At Airbnb, we recently completed migrating our largest repo, the JVM monorepo, to Bazel. This repo contains tens of millions of lines of Java, Kotlin, and Scala code that power the vast array of backend services and data pipelines behind airbnb.com.
在 Airbnb，我们最近完成了将最大的代码仓库——JVM monorepo——迁移到 Bazel 的工作。这个仓库包含 数千万行 Java、Kotlin 和 Scala 代码，为 airbnb.com 背后的大量后端服务和数据管道提供支持。
Migration in numbers (4.5 years of work):
迁移数据概览（4.5 年的工作）：
- Build CSAT: 38% → 68%
- 构建 CSAT：38% → 68%
- 3–5x faster local build and test times
- 3–5 倍更快的本地构建和测试时间
- 2–3x faster IntelliJ syncs
- 2–3x 更快的 IntelliJ 同步
- 2–3x faster deploys to the development environment
- 2–3x 更快的开发环境部署
In this blog post, we’ll discuss the why, share some highlights on the how, and finish off with key learnings.
在这篇博客文章中，我们将讨论为什么，分享一些关于如何的亮点，并以关键经验作为结尾。
Why Bazel?
为什么选择 Bazel？
Before the migration, our JVM monorepo used Gradle as its build system. We decided to migrate to Bazel because it offered three key advantages: speed, reliability, and a uniform build infrastructure layer.
在迁移之前，我们的 JVM 单体仓库使用 Gradle 作为构建系统。我们决定迁移到 Bazel，因为它在速度、可靠性和统一的构建基础设施层方面提供了三大关键优势。
Speed
速度
Bazel’s cacheable, portable actions allow us to scale performance with remote execution
Bazel 的可缓存、可移植操作让我们能够通过远程执行来扩展性能
In 2021, builds of large services often took >20 minutes locally and pre-merge CI p90 was 35 minutes.
2021 年，大型服务的本地构建通常耗时超过 20 分钟，合并前 CI 的 p90 为 35 分钟。
Building with Gradle was near its limit. We had already vertically scaled to high-end AWS machines on CI and remote development machines for developers of large services. In CI, we also used heuristics to split project builds and tests across multiple machines. However, this was inefficient, because of machine underutilization and duplication of shared tasks.
使用...