当前，我们有一个“前端” git存储库，它是我们所有的JavaScript客户端应用程序，还有一个“后端” git存储库，其中包含用.NET Core编写的所有后端API。还有其他一些基于不同技术的随机存储库。所有这些都通过Azure DevOps进行管理，我相信这将使我们能够触发特定路径上的构建。

front-end repo
-- applications
----app1
----app2
-- common-library

back-end repo
-- apis
----api1
----api2
--common-library

some .net-core-product repo


我们正在考虑将所有内容放入一个单一的仓库中，因为它对于开发人员而言，使用Visual Studio等git客户端进行管理更容易。我找不到多语言monorepo的示例-github上有示例吗？优点/缺点是什么？

#1 楼

自从Google推广Monorepos以来，近几年来它们已经引起了很多关注。如果您的规模与Google不同，则可能效果不佳。我去过一家搬到monorepos的初创公司，我们很快发现：


大多数工具是用一个仓库构建的，导致部署了一个工件。您将必须重新处理所有这些工具以处理monorepo。有一些专为monorepos设计的工具。

monorepo将所有鸡蛋放在一个篮子里。如果有人偷了笔记本电脑，您是否希望他们得到一半或全部代码？将事物保存在自己的存储库中可以减少暴露。
您的CI用来代码验证现在变得更加复杂。您需要在代码一致性测试中支持多种语言。当您检查后端内容时，开发人员会感到沮丧，他们只进行了前端更改。现在，您一直在试图找出如何禁用某些CI检查的方法，但是请确保在需要时启用了这些检查。您是否有空闲时间专注于发布工程的人员来处理多个复杂项目？ Google之所以能够做到这一点，是因为他们拥有成千上万的工程师，他们可以花十个月的时间将十个人奉献给这种事情，直到它足够平稳以至于可以发展为止。如果您的规模与Google不同，则可能无法遵循他们的示例。成功的人往往是大型组织。您可能没有找到开放源代码示例，因为不存在。

本文还指出了这些要点：


坦率的现实是，从规模上看，组织在代码共享，协作，紧密耦合等方面的表现是工程文化和领导才能的直接结果，与使用单一仓库或多仓库无关。两种解决方案最终看起来与开发人员相同。面对这种情况，为什么首先要使用monorepo？



所以请专注于改善您的工程文化，不要担心不遵循最新的技术趋势。