c# - mono-repo 中包的独立版本控制

Question

我们刚刚开始研究一些可能最好描述为全公司范围的“开源”框架的东西。我们的主要语言是 C#，我们使用 Jenkins 和 ProGet 来创建和共享 nuget 包。我们开始将所有内容(我的意思是所有内容。一个模块至少有三个存储库)放入它自己的 Git 存储库中。我们认为这是一个好主意，因为我们可以单独版本化和发布所有内容，但如果您想对具有依赖关系的多个存储库进行更改，结果会导致非常烦人的工作流程。

我开始环顾四周，似乎大多数项目都使用更加单一的方法，我认为这也可能会让我们在这里的生活变得更轻松。我不太确定的是，这种方法的版本控制是如何工作的。

CoreFx 存储库是我们正在努力实现的目标的一个很好的例子。一个存储库会产生许多单独的包。当我在本地构建此版本时，所有包都有一个版本号，但是当我查看 nuget.org 上的可用包版本时，版本似乎是每个包的。例如，System.Diagnostics.DiagnosticsSource 的版本为 4.5.1，但引用 System.Diagnostics.Debug 版本为 4.3.0。

所以我认为这对我们来说是一个很好的解决方案。一个存储库，许多具有独立版本的结果包。

有谁知道 corefx 项目是如何实现这一点的，或者有其他建议，如何做到这一点？

Answer 1

monorepos 和very-many-repos 都有优点；许多小型存储库的优点之一是您可以 git tag轻松获取单个软件包的特定版本。在单一仓库中做同样的事情有时会更尴尬。

但是，如果您发布更多的是“一组相关的软件包”，那么这也许并不是一个坏主意:您可以拥有一个 .bat或.ps1文件，为您的存储库构建所有 NuGet 包并相应地设置版本号。喜欢this example (Powershell脚本)

您正在谈论的引用/依赖项( System.Diagnostics.DiagnosticsSource 版本 4.5.1 取决于 System.Diagnostics.Debug 版本 4.3.0)成为单独的 <dependency> .nuspec 中的标签“消费”包的(即本例中的 System.Diagnostics.DiagnosticsSource。)在这里，您可以选择两种主要策略:

• 始终碰撞所有 <dependency>版本，以便“升级一个即可升级所有”软件包。有时这就是您想要的，然后您就应该这样做。
• 更加细粒度:仅当您实际以某种方式使用更新/更新的功能时才更新依赖项。例如，当使用包使用仅存在于特定版本的依赖项中的方法时。

后一种策略可以说是更优雅的方法，但也更复杂(可能需要更多的工作才能以良好的方式完成)

.NET 特定的挑战

Assume that I have project A and project B, which has a reference to A and that both are in the same repository. Also I have a Visual Studio solution for project B, which holds a project reference to project A.

Now, I make a change to project B and increment it's version, without incrementing the version of project A. I push my changes and Jenkins makes a clean checkout of the repo and build the solution creating both packages but package A now has the same version as it had on a previous build and can not be pushed to the nuget feed

这确实是一个有趣的问题。一些潜在的解决方法:

• 让 Jenkins 检测/确定更改之间的增量，并且仅为树中已更改的部分构建包。可能可行，但也许不是很容易；需要你的.ps1中有一些逻辑脚本。也许是我能想到的最优雅的解决方案。

• 将因“版本已存在”而失败的 NuGet 推送设为非 fatal error 。 IE。检测何时运行 nuget push如果您收到特定错误(非常重要的细节!)并忽略它。您绝对不想忽略 nuget push 中的所有错误但仅限于这些特定的。不太优雅，但仍然是全自动的。

• 使发布包成为半自动过程，而不是全自动过程。在 Jenkins 中设置一个或多个作业，当要发布包的新版本时，您可以手动“按下按钮”，也许有一个作业参数说“要发布哪个包”(可以是 Jenkins 中的下 pull 菜单，因此没有人知道)手动输入名称。)听起来可能有点手动，但这个选项可以让您作为一个团队对推送哪些包以及何时推送进行最大程度的控制。

进一步阅读

(关于一般的 monorepos，不是专门处理你提到的 CoreFx 案例。不过仍然可以提供有值(value)的信息。)

• https://github.com/babel/babel/blob/master/doc/design/monorepo.md :为什么 Babel 是单一存储库？
• https://github.com/korfuri/awesome-monorepo :精选的 Monorepo 工具、软件和架构列表。
• https://github.com/pouchdb/pouchdb/issues/5128 :PouchDB 迈向 monorepo 的一些步骤