作为一名PM,我想知道将多个repo合并为一个monorepo的潜在风险是什么?
我试着询问首席工程师哪里可能出问题,但他们非常愿意使用个人repos为12个团队完成这一过渡,他们告诉我没有风险。
不可用
为了回答这个问题,我期待着一份我们应该接受或减轻的合理风险的清单:
示例:
风险1:我们需要恢复到旧的回购,但不能,因为旧的回购现在已经落后了。
风险2:单个存储库的大小需要花费更长的时间来下载,并且所有内容都需要克隆,而不是单个部分。
我知道上面说的都是废话,所以我才寻求建议……
谢谢
发布于 2019-07-18 06:43:03
一般来说,monorepos往往不是一个好主意。一些Git操作在提交或其他对象的数量上线性执行,这意味着将大量文件和大量提交放入一个存储库可能会导致存储库显著减慢。即使你现在没有遇到可伸缩性的问题,你将来也会遇到,在这一点上,将你的代码提取到多个存储库中将变得更加困难。
有一些解决方法可以使monorepos的性能达到可接受的程度,例如Microsoft的VFS for Git。然而,一开始就不需要它要好得多,因为它需要相当多的努力才能让事情正常工作。
任何CI作业都将花费更长的时间来运行,因为它们需要更长的时间进行克隆。您还可能在每次更改任何项时为整个monorepo运行CI作业,而不是为单个组件运行CI作业。
您还会发现,在开发人员系统上,最终会占用更多的磁盘。可能只需要检查几个repos的开发人员现在需要更多的磁盘空间,这可能需要更大、更昂贵的机器或VM。
最后,您的Git存储库将变得更大。如果你在云上托管,这可能会给你带来问题。例如,Bitbucket将所有存储库限制为2 GB。如果存储库的大小开始对他们造成性能问题,其他提供商可能会要求您缩小存储库。即使您在本地托管,大型存储库也需要更多的时间来打包和重新打包,这就需要更多的CPU和内存来处理相同数量的用户。
您可以将子模块用于多个存储库,而不是使用monorepo,也可以简单地将当前版本的散列保存在存储库中的一个文件中,并通过构建步骤对其进行签出并在其发生更改时进行构建。这些解决方案适用于大型组织,它们可能也适用于您。
https://stackoverflow.com/questions/57079190
复制相似问题