如何使用Nuget进行内部企业开发？

Question

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

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

A、B和C将它们的工件推到Nuget，这就是我们如何管理A、B和C之间的依赖关系的方法。我们发现的问题是，如果开发人员想在C中进行更改，并且快速地看到这些变化在A中反映，那么它们必须经过以下过程。

1. 改变C.
2. 把变化推到git
3. CI获取对C的更改，并构建和部署新的nuget包。
4. 进入B，使用nuget更新包命令更新对C的引用。
5. 将对packages.config文件的更改向上推到git
6. CI获取对B的更改，并为B构建和部署新的nuget包
7. 现在打开A并更改对B和nuget更新包的引用
8. 使A随着B(和过渡C)的变化而变化

这似乎非常痛苦，并导致我们的一些开发人员质疑Nuget在我们内部开发的代码中的选择。每个人仍然喜欢它消费外部包。

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

Answer 1

在我们公司，我们已经用下面的设置解决了级联更新问题。首先，我们为我们的NuGet存储库和构建服务器设置了下面的设置。

• 有一个内部NuGet存储库，它保存着公司发布的所有包。这个存储库只是我们服务器上的一个共享目录。
• 每个开发人员都可以在自己的机器上拥有(但不需要)一个或多个目录作为本地NuGet包存储库。通过使用特定于用户的NuGet 配置，开发人员可以控制NuGet在包存储库中搜索的顺序以查找包。
• 所有解决方案都启用了自动包恢复，这样我们就不必将包提交到版本控制系统。
• 开发人员只控制4个版本号中的3个，例如，如果版本是<MAJOR>.<MINOR>.<BUILD>.<REVISION>，那么开发人员只能更改主版本号、次版本号和版本号，修订号被设置为0，除非生成服务器所做的构建是生成的版本号。这一点很重要，因为这意味着对于由主、次要和生成编号组成的给定版本，构建服务器总是会生成更高的版本号。这同样意味着NuGet将更愿意接受来自公司包存储库的包版本(它只通过构建服务器获取包)。

为了对其中一个基本库进行更改，需要使用两个可能的进程。第一个过程是：

1. 对基库(A)进行更改。如有需要，更新(A)的版本。
2. 运行MsBuild脚本来构建二进制文件并创建(A)的NuGet包
3. 将新的NuGet包复制到本地机器上的包存储库
4. 在依赖项目(B)中，升级到刚刚放在本地机器包存储库中的(A)的新包(该软件包的版本应该高于公司范围存储库( NuGet.org)上的版本)
5. 对(B)作修改。

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

一旦更改完成，那么我们：

1. 将更改提交给(A)。构建服务器将运行集成构建，以验证一切正常工作。
2. 告诉构建服务器运行版本构建，它构建二进制文件并将NuGet包推送到公司范围内的NuGet存储库。
3. 在(B)中，升级到(A)的最新版本(它应该比测试包有更高的版本号，因为测试包应该有版本a.b.c.0，而公司范围内的新构建版本应该是A.B.C。其中>0
4. 将更改提交给(B)。等待构建服务器完成集成测试。
5. 告诉生成服务器运行发布版本(B)。

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

1. 对基库(A)进行更改。如有需要，更新(A)的版本。
2. 构建二进制文件
3. 将二进制文件复制到NuGet为项目(B)解压缩(A)包的位置(例如c:\mysource\projectB\packages\ProjectA.1.2.3.4)
4. 对项目(B)进行必要的更改

提交过程仍然相同，需要首先提交项目(A)，在项目(B)中，需要升级对(A)的NuGet引用。

第一种方法稍微整洁一些，因为这个过程还警告如果(A)的NuGet包中有错误(例如忘记添加一个新的程序集)，而在第二个过程中，开发人员直到(A)包发布之后才知道。

Answer 2

你在这里有两个选择：

1. 在您的组织中运行NuGet画廊实例。这是运行nuget.org的代码
2. 获得Arti城Pro的许可证，它具有内置的Nuget支持，并充当Nuget存储库。

我使用了这两种方法，而#1是一个合理的选择，但NuGet Galley是为nuget.org优化和设计的，而不是在前提/企业中使用，因此删除包之类的事情是痛苦的(手动使用SQL )。

我想说的是，你应该支付Artifactory Pro的(低)许可费-这是一个优秀的产品，JFrog团队真的很热衷并打开了。

您不应该对内部/企业包使用nuget.org；nuget.org是为第三方/开源库设计的，而不是内部构建依赖关系。

编辑：在工作流方面，为什么要将共享的代码放入多个包中？如果代码需要共享，那么它需要放在自己的单独包中。

编辑2：为了加快开发人员的代码更改工作流，可以使用nuget.exe (命令行客户端)和命令行可访问的构建，这样就可以针对" developer“构建运行。然后，在您的"developer“构建(与CI构建相反)中，当您希望将新更新的-Source作为依赖项并对其进行构建时，将nuget install B -Source C:\Code\B指定为本地路径(例如nuget install B -Source C:\Code\B)；同样，对于C或其他本地更新的包也是如此。然后，当A、B和C都构建得很好时，您可以对它们进行git push (按反向依赖顺序)，并让CI完成它的工作。

但是，如果您必须经常进行这个构建“舞蹈”，那么您还应该质疑包分离是否真的合适，因为这意味着所有代码都应该在一个包中，或者可能在不同的包中沿着不同的线分开。定义良好的包的一个关键特性是，它不应该对其他包造成连锁反应，如果您正在有效地使用语义版本化，那么当然不会。

编辑3 marcelo所要求的一些澄清：“命令行可访问的构建”是完全可以在命令行中进行的构建，而不需要使用Visual，通常是通过批处理文件。"developer build“是一个开发人员从她的工作站运行的构建，而不是在CI服务器上运行的CI构建(这两个构建应该本质上是相同的)。

Answer 3

如果A、B和C采用相同的解决方案，则可以在单个构建中为它们创建NuGet包。

只需确保使用包具有它所依赖的包的新版本号(假设您的构建没有随机更改它)。

如果A、B和C有意采用不同的解决方案，例如A在基础结构解决方案下，B在产品解决方案下，那么我对您的唯一建议是定义您的CI构建在签入时运行，而不是定期运行。

编辑：

另一种选择是在本地构建期间向您的服务器创建一个push 预发布包(例如1.0.0-alpha版本)，这样开发人员就可以在创建发布版本之前对该包进行实验。