6

我正在将 NuGet 引入我们的软件开发流程，既适用于外部二进制文件（例如 Moq、NUnit），也适用于包含共享功能的内部库项目。

TeamCity 正在从我们的内部库项目中生成 NuGet 包，并将它们发布到本地存储库。我修改后的解决方案文件使用本地存储库来访问 NuGet 包。

考虑以下源代码解决方案：

  1. Company.Interfaces.sln构建Company.Interfaces.1.2.3.7654.nupkg。
  2. Company.Common.sln通过其 NuGet 包包含对 Company.Interfaces 的引用，并构建Company.Common.1.1.1.7655.nupkg，其中包含 Company.Interfaces.1.2.3.7654 作为依赖项。
  3. Company.DataAccess.sln使用Company.Common nupkg 添加 Company.Interfaces 和 Company.Common 作为引用。它构建 Company.DataAccess.1.0.8.7660.nupkg，包括 Company.Common.1.1.1.7655 作为依赖组件。
  4. Company.Product.A是一个网站解决方案，其中包含对所有三个库项目的引用（通过选择 Company.DataAccess NuGet 包添加）。

问题：

如果 Company.Interfaces 的源代码发生更改，我是否总是需要重新编号和重建中间包（Company.Common 和 Company.DataAccess）并更新 Company.Product.A 中的包？

还是这取决于源代码更改是否

  • 错误修复，或
  • 新功能，或
  • 一个突破性的变化？

实际上，我有 8 个级别的依赖库包。是否有用于更新整个包树的工具支持，是否有必要？

我知道语义版本控制。

我们正在使用 VS2012、C#4.0、TeamCity 7.1.5。

4

2 回答 2

3

最好在每次签到时更新所有内容，以便及早进行测试。

您所描述的内容可以使用工件依赖项（http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies）和“完成构建”构建触发器（甚至单独的“Nuget 依赖触发器”）轻松管理。

于 2013-06-01T19:44:37.177 回答
1

我们在基础项目（在本例中为Company.Interfaces.sln）上编写了自己的构建配置，它一次性构建和更新整个树。它会一路检查更新的 packages.config 文件和 .nuspec 文件。我不能说这最终为我们节省了多少时间，即使一开始听起来可能有点矫枉过正。

需要注意的一件事：我们编写的脚本会检查文件，即使链在两者之间的某处发生故障，以便我们有机会在本地机器上修复它，检查修复并重新启动发布。

于 2013-06-02T20:23:57.157 回答