缩小我们的 monorepo 大小以提高开发者速度

At Dropbox, almost every product change flows through a single place: our server monorepo. A monorepo is a single, shared Git repository that contains many services and libraries used across the company. Instead of splitting code across dozens of smaller repositories, we keep a large portion of our backend infrastructure in one place. That architecture makes cross-service development easier, but it also means the repository sits at the center of nearly everything we build.

在 Dropbox，几乎每一个产品变更都流经一个单一的地方：我们的 server monorepo。monorepo 是一个单一的、共享的 Git 仓库，包含公司范围内使用的许多服务和库。我们不是将代码分散到数十个较小的仓库中，而是将后端基础设施的大部分放在一个地方。这种架构使跨服务开发更容易，但也意味着仓库位于我们构建的几乎一切的中心。

Building AI-powered features at Dropbox often requires small changes across ranking systems, retrieval pipelines, evaluation logic, and UI surfaces. All of that work moves through the same engineering loop: pull the latest code, build and test it, get it reviewed, merge it, and ship it. Over time, we began to notice that this loop was getting slower. Our monorepo had grown to 87GB; downloading a full copy of the codebase (or “cloning” the repository) took more than an hour, and many continuous integration (CI) jobs were repeatedly paying that cost. We were also approaching GitHub’s 100GB repository size limit, which introduced real operational risk.

在 Dropbox 构建 AI-powered features 通常需要在 ranking systems、retrieval pipelines、evaluation logic 和 UI surfaces 中进行小的更改。所有这些工作都经过相同的工程循环：pull 最新的代码，build 和 test 它，进行 review，merge，然后 ship。随着时间推移，我们开始注意到这个循环变慢了。我们的 monorepo 已增长到 87GB；下载完整代码库副本（或“cloning” repository）需要一个多小时，许多 continuous integration (CI) jobs 反复支付这个成本。我们也接近 GitHub 的 100GB repository 大小限制，这带来了真正的运营风险。

In this post, we’ll share how we reduced the repository from 87GB to 20GB (a 77% reduction), cutting the time required to clone the repository to under 15 minutes. We’ll also explain what was driving the growth and what we learned about maintaining a large monorepo at scale.

在本文中，我们将分享如何将仓库从 87GB 缩小到 20GB（减少 77%），将克隆仓库所需时间缩短到 15 分钟以内。我们还将解释是什么驱动了增长，以及我们在大规模维护大型 monorepo 时学到了什...