对亚马逊Manyrepo构建系统的思考

不久前，我考虑过Monorepo版本控制系统，本文则与此截然相反：Manyrepos。

Monorepos很有吸引力，因为谷歌、Facebook和微软都使用了这种方法。这是他们秘密计划的一部分，还是偶然的？还有另一家大型科技公司做了相反的事情。在亚马逊，团队更独立地工作。一些公司使用不同的版本控制系统，这些系统并不像Git那样颠覆和执行。我猜大多数公司没有单一的方法，因为从组织的角度来看，拆分一个单独的项目真的很容易，但很难合并它们。所以也许我们可以从亚马逊学到比谷歌更多的东西。所以，也许我们可以从亚马逊学到比谷歌更多的东西。我猜大多数公司没有单一的方法，因为从组织的角度来看，拆分一个单独的项目真的很容易，但很难合并它们。所以也许我们可以从亚马逊学到比谷歌更多的东西？

一个共同的模式是，亚马逊和其他公司一样建造了自己的基础设施，工程师们喜欢它，离开后也怀念它。

我听过关于许多其他大公司建立系统的描述，也看过博客文章，但老实说，甚至没有什么能与亚马逊创造的令人惊叹的技术相提并论。我可能会争辩说，谷歌、Facebook和大多数其他规模或更大的公司所做的事情，充其量客观上是不太好的，最糟糕的是浪费了数百万美元的生产力损失。-TB。

一旦你了解了构建和部署工具，你首先会想知道你以前是怎么做的，然后开始担心一旦你离开了，你会怎么做。-霍尔。

就像前谷歌员工用Pantand Buck在外面重新创造了他们的构建系统一样，QBT也重新发明了亚马逊的构建系统。不幸的是，QBT鲜为人知，也不那么成熟。

不幸的是，关于亚马逊的信息较少。我的信息来自HN和lobste.rs上的这个看台讨论。如果我说错了什么，请告诉我。简而言之，亚马逊巴西工具更像是一个打包系统，而不是构建系统。它更接近NIX，而不是Bazel。

巴西将实际的构建过程委托给特定于语言的工具。像tmux这样的工具也与巴西一起打包。有趣的是包是如何管理的，需要理解的核心概念是版本集。

如果您在Amazon创建包，则指定类似"；1.1"；的界面版本。只要更改是向后兼容的，界面版本就不会更改。当巴西构建包时，它会附加一个额外的数字，使其成为类似"；1.1.3847523"；的构建版本。您只能指定对界面版本的依赖关系。

巴西在构建包时做的另一件事是记录依赖项与其构建版本的可传递关闭。现代打包工具在您想要的依赖项和您实际使用的依赖项之间有所不同。例如，Rust中的Cargo.toml和Cargo.lock。

版本集是包的集合。包是特殊的全局包，与版本控制中的主干分支相对应。当您针对版本集构建包时，将执行对版本集中所有包的测试，并且版本集将递增。因此，单个包将更新(如果之前不是版本集的一部分，则会发布)。

巴西依赖项分为运行时依赖项、构建依赖项和测试依赖项，因此对于部署，它可以从版本集中剥离除运行时依赖项之外的所有依赖项。

巴西被滥用的最大方式之一是围绕主要版本[又名界面版本]的处理，就上下文而言，一个版本集中一次只允许存在一个包的一个主要版本。如果您尝试将包的不同主要版本合并到您的版本集中，您的管道将由于主要版本冲突而无法构建。最大的错误之一是在没有同时冲突库的主要版本的情况下冲撞库中的依赖项的主要版本。这将导致许多管道破裂。假设您有一个库foo-1.0，其中有一群其他团队的用户。您决定将Guava版本从25升级到29，并发布新版本的foo-1.0。任何使用foo-1.0的用户都会自动选择该库的新版本，因为这只是一个次要的版本更改，但是合并将失败，并出现主要版本冲突，因为他们在其版本集中使用的主要版本仍然是25。这意味着您要么必须将该库固定回以前的版本，要么将您对所有软件包中的芭乐的依赖提升到29个。--Pentlander。

这是一个概括的见解：即使你的API是稳定的，更新依赖项的主要版本也是一个突破性的变化。

总体而言，它听起来很像APT或Nix这样的发行包管理器。版本集的不同之处在于它们提供了分支机制，这就是团队可以独立工作的方式。这有什么特别的呢？你也可以用APT和Nix分叉。在Monorepo中，它将是一个分支。它肯定是关于不同的东西。

Monorepos的一个优点是可以跟踪所有用户。巴西的版本集提供了类似的机制，因为它是一个中央数据库。例如，这在安全更新的情况下很重要。不幸的是，在许多repo环境中，这些信息通常是不可用的，当出现问题时，必须对其进行艰苦的研究。那么，也许公司应该建立这样的基础设施，而不是梦想着Monorepos？

回到多个repo的优势，参考Amazon，我们可以具体描述它：版本集允许您一次使用同一包的多个界面版本(虽然不是多个构建版本)。这种混合在技术上使用git monorepo是不可能的(但使用Subversion或Perforce)。这至少是一般权衡的一个示例。

我真的不认为Amazon和Google/FB风格的构建/部署/源代码控制系统之间有什么更好或更差的地方，它主要反映了组织/团队的结构和他们优先考虑的事情-团队独立性/速度和优化整个代码库的横切更改之间存在紧张关系。

我希望在网上看到更多关于这方面的讨论。许多公司应该更看重团队的独立性，而不是横切的变化。所以问题是：如何在众多回购环境中获得我们目前唯一归功于单一数据库的优势？亚马逊的巴西有宝贵的想法可以做出贡献，应该更广为人知。