3

需要以下方面的建议：

在我的公司中，我正在开发供外部利益相关者使用的 .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 上发挥它的魔力。通过扩展库中的 NuGet 引用 CoreLibrary。

选项 2 是我认为最干净的选项，并且具有按项目处理版本控制和打包的优点，但在维护它们方面可能会大大增加工作量，特别是考虑到我是这些库的唯一开发人员这一事实。

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

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

谢谢

4

2 回答 2

3

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

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

于 2018-03-15T03:15:06.950 回答
-6

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

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

于 2018-03-14T20:43:30.763 回答