使用 GitVersion 进行多个相关的 NuGet 库版本控制。 MonoRepo 还是 MultiRepo？

Question

需要以下建议：

在我的公司中，我正在开发供外部利益相关者使用的 .NET 类库，并在利益相关者可以访问的私有 NuGet 源上共享它们。

这些库依赖于一个核心库，如下所示。目前，我在一个 VS 解决方案中维护这些库，显然是在一个 Git 存储库中。我正在关注 SemVer 对它们进行版本控制。

CoreLibrary
CoreLibrary.Extension1 (references CoreLibrary as project reference)
CoreLibrary.Extension2 (references CoreLibrary as project reference)
...
There might be more of these extension libraries in the near future

到目前为止，我一直在 Visual Studio 中手动对它们进行版本控制（每当我需要升级版本时，在 AssemblyInfo.cs 中手动设置正确的值），并在每个项目中使用批处理文件来打包并将特定库推送到NuGet。

但现在我最近开始研究 VSTS，我的下一个任务是尽可能地自动化构建和发布，包括自动版本控制。我偶然发现了 GitVersion，我认为它对最后一部分有很大帮助。

但是，这里是但是。如果我理解正确，GitVersion 在存储库级别运行，因此由 GitVersion 计算的给定 semver 版本适用于存储库中的所有程序集/库，对吗？

那么您对这些库的发布和版本控制策略有何建议？

1) 像现在一样将所有内容保存在一个解决方案和存储库中，每当需要发布的一个包（例如 CoreLibrary.Extension1）发生更改时，这也会为所有其他库生成一个 NuGet 包。因此，如果所有包都在 1.0.0 上，并且其中一个有一点小变化，它们都会被撞到 v1.1.0 并且都被打包和推送？

2) 为每个项目创建一个 git repo，并让 GitVersion 分别在每个 repo 上发挥它的魔力。在 Extension 库中通过 NuGet 引用 CoreLibrary。

选项 2 是我认为最简洁的选项，并且具有每个项目处理版本控制和打包的优势，但在维护它们方面可能会大大增加工作量，尤其是考虑到我是这些的唯一开发人员这一事实图书馆。

你有什么想法？在给定上下文的情况下，您会选择哪个选项？我是否错过了其他可能值得考虑的选项？

设置我在自动化构建和发布方面的第一步，因此任何建议都非常受欢迎。

谢谢

Answer 1

我强烈建议不要在这里使用任何 nuget 包。 Nuget 旨在作为一种管理软件项目的第三方依赖项的方式，而不是作为一种管理您定期构建的互连代码的方式。为此，您最好拥有一个存储库、一个 Visual Studio 解决方案和一个您从中构建/部署的构建堆栈。

如果您必须使用 Nuget，只需制作具有单个版本的单个包。

Answer 2

您必须至少考虑以下两个因素：

1. 需要努力维护多个存储库/分支和发布流。
2. 当您对一个或一小部分库进行小幅或大幅更改时，您的客户需要付出的潜在努力。

当一个项目很小并且只有一个开发人员在处理它时，完全在一个存储库中工作并为所有版本剪切一个包通常会更容易。然而，即使对于单个开发人员，这也不会随着库的数量而很好地扩展。一方面，VS 并不是特别擅长处理大型项目，尽管随着时间的推移，它确实在这方面不断改进。即便如此，还是有一个实际限制，但单个开发人员不太可能在不到几年的时间内达到足够的生产力。

最终，即使是单个开发人员，通常也希望获得足够的成功，从而满足规模化需求，无论是在开发方面，还是在支持客户方面。考虑当重要客户发现扩展程序 1 中的错误时，对扩展程序 2 的一些主要工作进行到一半的影响。现在您需要签出较早的提交，生成快速修复，剪切新包，测试，冲洗/重复，发布，返回到您的存储库的头部，挑选错误修复，然后继续。如果您一直在不同的 repo 中工作，甚至在同一个 repo 中的分支中工作，那么这项任务会更容易组织并在第一次尝试时就做好。

现在，对于您假设每个 Nuget 包需要单独的存储库，或者 GitVersion“在存储库级别运行”，我有一个要点可以选择。通常，您会找到的大多数文档和几乎所有示例都绝对适合单一产品/包/repo 格式，在大多数情况下我可能会建议这样做，但实际上这并不是硬性要求。 GitVersion 在分支级别起作用，您绝对应该为不同分支中的不同库进行开发，如果不是不同的 repo 的话。拥有一个 master 分支来合并所有内容可能也是一个好主意，但 Git 或 GitVersion 甚至不需要 master。您可以在单个 git 存储库中拥有多个 VS 解决方案和项目，并且可以从中生成多个 nuget 包。我并不是说你应该这样做，我是说这并不少见，至少对于不平凡的产品线而言。

在客户方面，这在很大程度上取决于您产品的性质。所有的扩展都是必要的，甚至对每个客户都有用吗？您会为早期采用者制作 alpha/beta 版本吗？您的代码是否在服务器上使用？是否在移动设备上使用？通常，您不希望服务器上运行的任何代码的升级时间过长，因此您应该认真考虑将您的产品线分解为多个独立版本的软件包。客户端过去在这个领域并不那么重要，但在移动设备上，下载时间成为一个主要因素。并非每个人都可以使用无限的免费下载带宽，因此成本可能是一个主要因素。

如果您要制作大量预发布版本，您可能希望将产品线分成单独的包。您仍然可以生成一个包，但最终您需要选择在模块级别发送更新。

一旦您完成了一个 repo/project/package/release-stream 路径，您将快速开发所需的自动化来帮助维护它。这就像干净的编码实践，刚开始时会有些痛苦，但最终会成为第二天性，并且最终的回报可能是巨大的。请记住，没有任何理由不能让多个 repo 拥有自己的解决方案和项目，并且在父目录上也有一个 VS 解决方案，从而为您提供完全集成的构建。只需将其视为构建系统的层次结构。你只需要学习如何使用.gitignore 文件或 git 子模块（我更喜欢前者，因为后者的工具很弱）。