Spotify 的车队管理(第 3 部分):整个车队的重构
May 15, 2023 Published by Matt Brown, Staff Engineer
2023 年 5 月 15 日,由工程师 Matt Brown 发布
This is part 3 in our series on Fleet Management at Spotify and how we manage our software at scale. See also part 1 and part 2.
这是我们关于Spotify Fleet Management的系列文章的第3部分,介绍我们如何在规模上管理我们的软件。请参见第1部分和第2部分。
For the third part of this Fleet Management series, we’ll discuss what we call “fleet-wide refactoring” of code across thousands of Git repos: the tools we’ve built to enable fleet-wide refactoring and make it an everyday occurrence, how we rolled them out, and lessons we’ve learned along the way.
在本系列的第三部分中,我们将讨论所谓的代码全车队重构,即跨数千个 Git repo 的代码的重构:我们构建的工具使全车队重构成为日常事务,我们如何推出它们以及我们学到的经验教训。
As mentioned in Part 1 of this series, Spotify’s codebase is spread out across thousands of Git repos. We use a polyrepo layout — each repo contains one or a small number of related software components out of the thousands of components we run in production (the codebase for our desktop and mobile clients is laid out differently, in monorepos). This layout has grown out of wanting each individual team to have strong ownership of their components, independently developing and deploying them as they wish.
正如本系列文章的第一部分中所述,Spotify 的代码库分布在数千个 Git repo 中。我们使用 polyrepo 布局——每个 repo 包含数个相关的软件组件之一,这些组件是我们在生产中运行的数千个组件之一(我们的桌面和移动客户端的代码库布局不同,在单体库中)。这种布局的发展源于希望每个团队都能够对其组件拥有强大的所有权,独立地开发和部署它们。
While having many repos favors individual team autonomy, much of the source code in those repos has dependencies on other parts of our codebase living in other repos. For example, a large percentage of our backend services is built on an internal service framework and set of core libraries, and most batch data pipelines are written using Scio. Updating every one of these repos for every change or bugfix in the framework or core libraries would require a big effort, and, in the past, this could not be done quickly — as mentioned in the previous post, it would usually take 6+ months for each new release of the backend service framework to reach 70%+ adoption in our backend s...