Git子模块与Nuget包

Question

我们的团队已经尝试使用git子模块来实现我们大多数产品共享的一些核心CRUD功能.我们还成功地使用了Nuget软件包(现在自托管)用于一些常见的实用程序.

我们的核心功能经常发生变化,以确保子模块正确承诺,这更像是我们所期望的苦差事.我正在考虑将核心功能从子模块移动到Nuget包,但我想知道对包的频繁更新是否会让Nuget更加痛苦.

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

Answer 1

对于经常更改的内部库，我更喜欢使用子模块而不是 Nuget 包。原因如下：

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

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

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

• 调试：由于 Nuget 包是编译的，因此您无法单步调试它们的代码。

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

Answer 2

与任何事情一样，这取决于。您是否考虑过使用单独的 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包与预发布和发布分开，尽管从技术上讲，您的 CI 包是作为预发布版本的）
• 如果预发布标签的字符串排序高于“CI”（例如“Alpha”），则从 CI pkg 升级到预发布可能会出现问题。在这种情况下：卸载包“CI”后跟安装包“Alpha”。

希望这可以帮助！