31

我们的团队已经为我们大多数产品共享的一些核心 CRUD 功能试验了 git 子模块。我们还成功地将 Nuget 包（现在自托管）用于一些常见的实用程序。

我们的核心功能经常发生变化，以至于保持子模块正确提交被证明是我们所期望的更多的苦差事。我正在考虑将核心功能从子模块移动到 Nuget 包，但我想知道对包的频繁更新是否会在 Nuget 中更加痛苦。

在对我们的架构和流程进行这种略微侵入性的更改之前，是否有人对我可能遇到的其他挑战有任何经验和指导？

4

2 回答 2

6

与任何事情一样，这取决于。您是否考虑过使用单独的 CI 包存储库，其中对核心模块的每次提交都会生成一个 CI 包？

imo 最大的挑战是包版本控制，因为 NuGet 还没有完全支持 SemVer（例如预发布版本 + 内部版本号）。

编辑：nuget.org 现在支持 SemVer 2.0 包版本。请参阅此规范：https ://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

正确使用 SemVer。你通常不知道发布的版本号，所以你的 CI 包版本从最新的稳定版本继续。这样的 CI 包将被视为预发布。

例如：（2.2.0-CI201209140650这是 2012 年 9 月 14 日 06:50 为即将发布的 2.2.0 版本拍摄的 CI 版本）<-- 注意：此版本仍然可以更改，但总会有更新路径。

如果采用 SemVer v2.0.0，甚至可以采用下面的例子：2.2.0-CI.2012.09.14.06.50.

重要提示： nuget.org（以及任何其他 NuGet 服务器/服务，例如 MyGet 或 VSTS）不支持仅通过构建元数据不同的多个包版本！

使用这些约束（以及一些适当的 TeamCity 构建配置），这对我有用。简而言之，这些都是麻烦：

  • 正确的版本控制
  • 提醒选择正确的包源（将您的 CI pkgs 与预发行版和发行版分开，尽管从技术上讲，您的 CI 包被版本化为预发行版）
  • 如果预发布标签的字符串排序高于“CI”（例如“Alpha”），则从 CI pkg 升级到预发布可能会成为问题。在这种情况下：卸载包“CI”，然后是安装包“Alpha”。

希望这可以帮助！

于 2012-09-14T04:56:43.387 回答
5

我更喜欢使用子模块而不是 Nuget 包来频繁更改内部库。原因如下：

  • 合并：如果多个开发人员同时对同一个库进行更改，使用子模块，这些更改可以合并。对于 Nuget 包，显然没有合并的概念。

  • 更少的等待：使用子模块，您推送，然后使用您需要使用子模块的任何 repo 拉取。通常需要几秒钟。使用 Nuget，您必须等待发布包，通常是在 CI 流程完成之后。

  • 版本冲突：同样，如果多个开发人员同时进行更改，他们可能会将 Nuget 版本 # 增加到相同的版本，尽管他们的更改不同。要解决多少痛苦取决于您的 CI 流程。

  • 可以在“客户端”存储库中进行更改：有时在处理将使用该库的客户端代码时，最容易充实库更改的细节。使用子模块，这是可能的。当然，这不能代替测试覆盖率。

于 2021-01-20T20:39:34.310 回答