nuget - 我应该如何使用 Nuget 进行企业内部开发？

Question

我们使用 Nuget 进行内部开发，以允许我们跨团队共享代码。然而，当一个人正在处理将同时部署在多个 nuget 包中的代码时，我们会遇到问题。例如

A依赖于B，而B又依赖于C。

A、B 和 C 将他们的工件推送到 Nuget，这就是我们管理 A、B 和 C 之间依赖关系的方式。我们发现的问题是，如果开发人员想要在 C 中进行更改并快速看到这些更改反射(reflect)在 A 中，他们必须经过以下过程。

在 C 中进行更改。

将更改推送到 git

CI 获取对 C 的更改并构建和部署新的 nuget 包。

进入 B 并使用 nuget update package 命令更新对 C 的引用。

将packages.config 文件的更改推送到git

CI 获取对 B 的更改并为 B 构建和部署新的 nuget 包

现在打开 A 并更改对 B 和 nuget 更新包的引用

在 A 中进行更改以与 B 中的更改(和可传递的 C)一起进行更改

这看起来非常痛苦，并导致我们的一些开发人员质疑为我们内部开发的代码选择 Nuget。每个人仍然喜欢它使用外部包。

在内部使用 Nuget 是否有更好的工作流程？

Answer 1

在我们公司，我们通过以下设置解决了级联更新问题。首先，我们为 NuGet 存储库和构建服务器进行了以下设置。

有一个内部 NuGet 存储库，其中包含公司的所有已发布包。此存储库只是我们其中一台服务器上的共享目录。

每个开发人员都可以(但不需要)在自己的机器上拥有一个或多个目录，用作本地 NuGet 包存储库。通过使用特定于用户的 NuGet configuration，开发人员可以控制 NuGet 搜索包存储库以查找包的顺序。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
  </packageRestore>
  <packageSources>
    <add key="Dev" value="D:\dev\testpackages" />
    <add key="Company" value="<UNC_ADDRESS_COMPANY_REPOSITORY>" />
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
  </packageSources>
  <disabledPackageSources />
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

所有解决方案都开启了自动包恢复，因此我们不必将包提交到我们的版本控制系统。

开发者只能控制 4 个版本号中的 3 个，例如如果版本是 <MAJOR>.<MINOR>.<BUILD>.<REVISION>，那么开发人员只能更改主要、次要和内部版本号，修订号设置为 0，除非在由构建服务器完成的构建中，它是构建的内部版本号。这很重要，因为这意味着对于由主要、次要和构建号组成的给定版本，构建服务器将始终生成更高的版本号。这再次意味着 NuGet 更愿意采用来自公司包存储库(仅通过构建服务器获取包)的包版本。

为了对基础库之一进行更改，可以使用两种可能的过程。第一个过程是:

对基础库 (A) 进行更改。如果需要，更新 (A) 的版本。

运行 MsBuild 脚本来构建二进制文件并创建 (A)

的 NuGet 包

将新的 NuGet 包复制到本地计算机上的包存储库

在依赖项目 (B) 中升级到刚刚放置在本地机器包存储库中的 (A) 的新包(应该比公司范围的存储库或 NuGet.org 上可用的版本更高)

对 (B) 进行更改。

如果需要对 (A) 进行更多更改，则重复步骤 1,2 和 3，然后从 (B) 的工作目录中删除 (A) 的包。下次构建运行时，NuGet 将寻找 (A) 的特定版本，在本地机器存储库中找到它并将其拉回。请注意， NuGet cache 有时可能会阻止此过程，尽管看起来 NuGet 可能会不缓存来自同一台机器的包(？)。

更改完成后，我们:

提交对 (A) 的更改。构建服务器将运行集成构建以验证一切正常。

告诉生成服务器运行发布生成，它生成二进制文件并将 NuGet 包推送到公司范围的 NuGet 存储库。

在(B)中，升级到(A)的最新版本(它的版本号应该高于测试包，因为测试包的版本应该是abc0，而公司范围存储库中的新构建版本应该是abc其中 > 0

提交对 (B) 的更改。等待构建服务器完成集成测试

告诉构建服务器运行 (B) 的发布构建。

进行开发工作的另一种方法是采取以下步骤

对基础库 (A) 进行更改。如果需要，更新 (A) 的版本。

构建二进制文件

将二进制文件复制到 NuGet 为项目 (B) 解压 (A) 包的位置(例如 c:\mysource\projectB\packages\ProjectA.1.2.3.4 )

对项目 (B)

进行必要的更改

提交过程还是一样，项目(A)需要先提交，项目(B)中NuGet对(A)的引用需要升级。

第一种方法稍微简洁一些，因为此过程还会警告 (A) 的 NuGet 包中是否存在错误(例如忘记添加新程序集)，而在第二个过程中，开发人员直到 (A) 的包之后才会知道) 已发表。