多语言Monorepo

Question

我们目前有一个“前端”git存储库，它是我们所有的JavaScript客户端应用程序，以及一个“后端”git存储库，包含用.NET核心编写的所有后端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这样的git客户端。我找不到多语言单一语言的例子--在github上有例子吗？优点/缺点是什么？

Answer 1

自谷歌推广了它们以来，Monorepos近年来一直受到人们的广泛关注。如果你没有谷歌那样的规模，它可能对你没有那么好的效果。我在一家创业公司转到了monorepos，我们很快就发现：

• 大多数工具都是通过一次回购构建的，最终得到了一个部署的工件。您必须重新处理所有这些工具来处理monorepo。有些工具是专为单目设计的。
• 一个单位球把你所有的鸡蛋放在一个篮子里。如果有人偷了一台笔记本电脑，你会宁愿他们得到你一半的代码或全部代码吗？在自己的回购中保留不同的东西会减少暴露。
• 您的代码验证CI现在要复杂得多。您需要在代码一致性测试中支持多种语言。当您检查后端内容时，开发人员会不高兴，而且他们只做了前端更改。现在，您只能尝试找出如何禁用某些CI检查，但要确保在需要时启用它们。

所有这些都增加了发布工程师的工作量。你有没有人专注于有空闲时间的发布工程来处理多个复杂的项目？谷歌之所以能做到这一点，是因为他们有成群的工程师，而且他们可以在几个月的时间里把10个人投入到这类事情上，直到事情顺利到足以在此基础上发展为止。如果你与谷歌的规模不同，你可能无法效仿他们。成功通过这个倾向于成为大型组织的人。您可能还没有找到开源示例，因为它们都不存在。

这些要点在这篇文章中也有说明：

坦率的现实是，在规模上，一个组织在代码共享、协作、紧密耦合等方面做得有多好，这是工程文化和领导的直接结果，而与使用monorepo还是polyrepo无关。这两种解决方案最终看起来与开发人员相同。面对这种情况，为什么一开始就使用单一的方式呢？求你别这样！

因此，专注于改善你的工程文化，不要担心没有跟上最新的科技趋势。

Answer 2

您可以将两个或多个项目放入同一个存储库，而无需选择"monorepo“，默认情况下，每个项目都进入同一个存储库。

如果您有多个需要串联发布的产品--将它们放在同一个存储库中--允许您一次以相同的提交发布所有产品，“原子地”。据我所知，这是主要的考虑因素。

就像在您的示例中一样，如果前端的每个版本都需要在后端发布一个等效的版本。对于单独的repos，您必须在repos之间协调多个拉请求。这需要付出努力，而这种努力会使更多相互依赖的项目成倍增加。*相对于拥有一个包含两个项目的更改的单一PR，这两个项目都保证同时发布，而没有额外的协调工作。

API和前端可能不是一个很好的例子，因为API通常是设计成与任何客户端分离的版本。但是，假设您有一些UI集成测试。这两个代码库都是紧密耦合的；UI中的微小更改可能需要在测试中进行等效的更改。不管语言如何，从概念上来说，它们都意味着“一起改变”，因此，当它们在同一个存储库中时，管理它们就容易得多。类似于单元测试，尽管它们通常至少是相同的语言。

需要进行横切更改的代码评审会产生更大的摩擦，因为您必须更新多个存储库中的多个分支。特别是在做多轮审查的时候。

部署工作必须仔细协调。在一个回购中合并一个PR并触发一个部署，可能会破坏其他的部署，因为其他的PR还没有被批准。或者，您必须编写所有的项目才能始终向后兼容。

跨多个存储库的自动化可以缓解其中的一些问题，但通常仍然需要某种形式的手动同步。

现实地说，这两条路都有取舍，这使这个问题的答案成为一个令人深感不满的“它取决于”。我的经验法则是，代码一起变化，一起生活在同一个存储库中。只有当把它放在同一个存储库中的负担超过了将它们分开的负担时，我才会分裂。

关于混合语言

Git是语言不可知论的，所以它不在乎。你的另一个工具可能。你得权衡一下上面的好处。

当存储库的根不是项目的根时，一些CI/CD工具需要额外的配置。如果这个工具不能支持这种额外的配置，而且我还没有遇到这样的工具，我会认为它的设计很糟糕。

对于特定于语言的工具，如指针等，只要每个项目都在自己的文件夹中，它们就不会相互了解。现在，在CI/CD级别运行这些工具可能需要额外的cd <subdirectory>语句。

当您从根打开项目时，IDE可能会感到困惑。例如，如果您在同一个repo中有一个Python、C#和类型记录，那么一个VSCode实例将有3个“语言服务器”，它将与之通信，潜在的3个插件UI将根据您正在查看的文件隐藏和显示，从3个地方提取调试配置等等。到目前为止，在我的经验中，这只会导致对工作区设置进行一些小的配置更改，否则一切都会正常工作。最糟糕的情况是，我最终会在每个项目中打开另一个实例VSCode，如果它们是分开的，这就是我要做的事情。

团队也扮演着

的角色

这也涉及到您的团队结构。如果您对每个产品都有单独的团队，那么将它们分开可能是有意义的，因为无论如何跨团队的协调都需要进行，因为没有一个成员在多个repos中提交。

我个人不像这样划分团队，因为我更喜欢能够在应用程序系统的任何部分编写代码的团队，无论是前面、后面还是侧。但我认识到，这并不总是可取或可能的。

为什么谷歌、推特等会这么做？

在谷歌规模上，他们的项目依赖关系很可能是由他们自己的内部团队开发的。我怀疑这意味着，在任何给定的工作中，他们大多是在进行同时影响许多项目的提交。

因为这是他们的默认情况，他们决定把所有的东西都放在同一个回购中。他们为此付出了很大的代价，但对他们来说，这是有意义的，因为由于所有这些内部管理的依赖关系，横切更改是正常的。

对于典型的项目，依赖关系主要是由公司以外的第三方管理的项目。想想nuget和npm的套餐。你的其他项目基本上是相互独立的。因此，在默认情况下，将每个项目放在一个回购中是没有意义的。

总之，请记住，Google、Twitter等都是管理他们自己的产品，并且拥有完全的控制权。而您的公司可能正在为不同的客户开发多个项目。在这种情况下，尽管谷歌的规模有多大，但你仍然面临着谷歌所没有的挑战，而且谷歌在解决方案中也没有考虑到这些挑战。

Asides

*就使用该API的API和前端而言。我通常会认为它们是独立的，并且是独立的。API应该设计为服务于许多客户，而不仅仅是一个前端。否则，像ASPnet或PHP这样的服务器端UI框架将是更合适的选择，imo。不过，我认识到，情况往往并非如此，我们的前端与专为它们设计的后端紧密相连。