如何在monorepo内部版本的产品?

jus*_*web 12 versioning continuous-integration continuous-deployment monorepo

我一直在教育自己关于monorepos,因为我相信这对我的团队和我们项目的现状是一个很好的解决方案.我们有多个Web产品(客户端门户,内部门户,API,核心共享代码).

我正在努力寻找我想要找到的答案的版本.

当您的所有项目和产品都在monorepo内时,版本控制策略是什么?

  • 1版适合所有?
  • 具有独立版本控制的Git子模块(打破了单声道回购的重点)
  • 其他策略?

从CI的角度来看,当您在项目A中提交某些内容时,是否应该在所有项目中启动整套测试以确保没有任何损坏,即使没有必要对依赖/共享模块进行更改?

bit*_*ift 5

当您的所有项目和产品都位于单一存储库中时,版本控制策略是什么?

我建议一种版本适合所有情况,原因如下:

  • release-x.x.x例如,在发布产品时,您可以标记整个分支。如果出现错误,您无需检查“YYY 使用的是 XXX 的哪个版本”
  • 它还可以更轻松地强制 XXX 的版本 xxx 使用 YYY 的版本 xxx。本质上,保持项目同步。当然,您如何进行此操作取决于您的项目是使用什么技术编写的。

从 CI 的角度来看,当您在项目 A 中提交某些内容时,是否应该在所有项目中启动整套测试以确保没有任何问题,即使不一定对依赖项/共享模块进行更改?

如果执行测试的时间不是特别长,那么这不会造成任何损害。我肯定会推荐这个。测试运行得越频繁,您就能越早发现与时间相关或与环境相关的错误。

如果您出于某种原因不想一直运行测试,您可以查询 VCS 并编写一个脚本,根据发生的更改有条件地触发测试。这在很大程度上依赖于 VCS 和 CI 服务器之间的集成。

  • 这个答案做出了一个根深蒂固的假设,即单一仓库内的所有项目都是相互关联的。这里的担忧是由诸如 XXX 是否使用 YYY 的 xxx 版本?如果单一存储库中的代码子段在逻辑上彼此无关,并且子项目的一个谱系的版本控制不应连接到另一个谱系的版本控制,则会出现非常不同的问题。 (15认同)
  • 例如,假设有人将 PostgreSQL 和 TensorFlow 的所有源代码放入同一个存储库中。每当 PostgreSQL 需要新版本时,现在 TensorFlow 也需要一个无操作版本,该版本没有任何变化,但必须增加版本才能为整个存储库保留一个整体版本?基于发布标签自动生成的变更注释将成为一个巨大的 PITA。现在假设您还将所有 Keras 源代码添加到同一个存储库中,这样给定版本的 Keras 使用哪个版本的 TensorFlow 确实很重要,但与 Postgres 的版本无关。 (10认同)
  • 你的解决方案是什么@Ely?你所谈论的场景正是我想要理解的。在单一存储库中为不同应用程序提供一个单一版本是没有意义的。 (8认同)
  • 我正在使用 Lerna 来管理我的 monorepo,当项目内部(或其依赖项内)发生更改时,这只会增加项目的版本号。尽管我的 monorepo 目前规模仍然很小,但这对我来说效果很好。 (3认同)