three.js 库房地图_单仓库vs. 多仓库VS. 混合动力：什么是正确的方法？

three.js 库房地图

我仍然记得在Outbrain的第一天。 作为Bootcamp（培训计划）的一部分，我们需要从称为主干的存储库（包含我们所有代码库的一个整体存储库）中克隆代码。 克隆和构建整个源代码至少花费了半天的时间。 在我的团队使用monorepo的下一两年中，我们遭受了痛苦–复制存储库非常耗时； 缓慢的构建/发布时间使我们感到沮丧； 脆弱的测试和错误的提交影响了整个工程； 更不用说IntelliJ索引时间了，它很容易为我们腾出时间来闲聊。

但是请稍等。 Google，Facebook，Twitter和其他大公司都使用mono-repos，对吗？ 你为什么不应该这样做？ 好处一定是巨大的，不是吗？

根据我们在Outbrain的经验，我可以说是的，但是确实如此，但是您需要意识到在项目开始扩大规模时会遇到的困难。
使用monorepo的大公司已经开发了复杂的工具，并花费了大量的资源，金钱和时间来使用它。 例如，Facebook建立了自己的自定义文件系统（使用的保险丝文件系统 ）和源代码控制（fbsource-定制的Mercurial ），以解决扩大规模的问题。

我想与大家分享我们对单仓库与多仓库以及最终在Outbrain采用的混合方法的看法。

单仓库

我们正在从事的大型项目类型的Mono-repo阻碍了我们的开发过程。 如果一篇好的文章破坏了引起单购回交易固有问题的理论基础，请查看单购回购交易-请不要！ ，其中Matt Klein会解决您在使用这种方法时遇到的所有可能的麻烦，而无需开发需要大量人力和财力的工具。

这是否意味着我们不应该使用monorepo？ 没有。

Monorepos提供了一个集中的地方来管理依赖项，这使得升级库变得更容易，允许更多的协作和代码共享，并且仅使用一个CI。

但是，monorepo减慢了我们的开发过程，影响了公司的整体发展速度。 结果，我们决定打破垄断，转向微服务。 如果项目相互依赖，那么项目之间的耦合就只能成为API合同。 在这一点上，尽管我们仍处于monorepo中，但合同使我们能够过渡到multi-repo。 也就是说，由于团队的代码现在仅依赖于API合同，因此我们能够将代码移到他们自己的存储库中，以使其完全自治。

多重仓库的结构

每个存储库包含两个主要模块：

• 库-此模块包含我们发布到工件的所有库，以便其他团队可以使用它。
• 服务-该模块包含我们所有可部署的服务和内部库。

我们所有的问题都解决了吗？ 没有。

像单仓库一样，多仓库既有优点也有缺点。 一方面，我们希望每个存储库都包含自己的依赖关系，这些依赖关系由他们自己的团队管理，但是这导致了不同版本之间的依赖关系冲突（团队共享他们的库和API）。 另一方面，解耦使团队拥有充分的自治权。 结果，CI更快。 此外，灵活性使团队能够最大限度地提高自己的速度。

向多仓库的过渡要求所有团队自行管理其依赖性，从而降低了对多仓库之间依赖性的可见性和控制。 不幸的是，这导致了依赖性冲突，第三方库以及我们自己的第三方库的版本在生产中以“ NoSuchMethodError”或“ ClassNotFoundError”出现。

为了重新获得可见性和控制力，我们决定编写一个内部工具-保险杠工具。

保险杠工具

想象一下一种机制，该机制可以在几分钟内创建一个专用分支，更新100多个存储库并触发构建。 人们通常不记得其存储库中使用了依赖项的位置。 我们想要一个自动化工具来更新依赖关系的版本（跨多个存储库的第三方和团队的库依赖关系）。 保险杠工具将带有相关版本更新的拉动请求自动发送到存储库所有者。

保险杠分为两个阶段：

1. 扫描阶段—保险杠定期扫描存储库并收集信息，例如存储库位置，依赖项信息，pom.xml位置等。
2. 更新阶段-保险杠会破坏特定的多个依赖关系，并将拉取请求发送给回购所有者。

该工具既可以在内部使用（团队A通过将其库释放到工件中来公开其API，其他团队则可以将该API用作由版本管理的依赖项），也可以在外部使用（在我们的情况下为Maven依赖项）。

通过Slack更新版本！

保险杠工具实际上只是一个Slack机器人。 要更新版本，我们只需在Slack中执行命令即可。 可以使用存储库中的不同属性名称来管理依赖项（工件）。 这就是为什么我们从查询开始。

最终，我们在特定的pom.xml中碰撞了与特定工件相关的属性。

做完了！ 保险杠创建并向相关存储库发送拉取请求，并通知其依赖项已更改的所有所有者。

结果，每个凹凸都包含所有拉动请求的列表，并且可以在跟踪拉动请求状态的漂亮视觉效果（仪表板）中找到。

如前所述，bumper工具帮助我们自动在存储库之间更改版本，但并没有使我们摆脱依赖地狱。

混合回购

使用hybrid-repo，我们有一个repo负责维护团队之间的内部共享库和API。 为了保持其高编译速度并保持存储库精简，我们确保不要使用编译缓慢的库，例如用Scala编写的库或具有长期运行的测试的库。

混合存储库的优点之一是它们减少了依赖关系冲突，因为我们在一个存储库中拥有一个管理所有依赖关系的地方。 现在，带有服务的存储库只需要升级一个依赖关系，而不必升级多个团队的几个版本，我们仍然可以使用保险杠工具来修改（外部/内部）版本，这使得版本调整更加容易。

但是，我们需要确保存储库的大小可以控制并且不会扩大规模。

什么是正确的方法？

这不是万能的解决方案。 答案在于您的团队对项目需求和可用资源的协作分析。 正如我们在Outbrain所做的那样，需要考虑所有可能的方法，并且显然您需要根据组织的特定要求和需求来调整决策。

取得平衡-找到您的混合动力车！

翻译自: https://hackernoon.com/mono-repo-vs-multi-repo-vs-hybrid-whats-the-right-approach-dv1a3ugn

three.js 库房地图