我应该如何使用 Nuget 进行企业内部开发? [英] How should I use Nuget for internal enterprise development?

问题描述

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

We use Nuget for our internal development to allow us to share code across teams. We run into issues however when one person is working on code that will be deployed across multiple nuget packages at the same time. For instance

A 依赖于 B 而依赖于 C.

A depends on B which depends on C.

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

A, B and C have their artifacts pushed to Nuget and that's how we manage the dependencies between A, B and C. The trouble we find is that if a developer wants to make changes in C and quickly see those changes reflected in A, they have to go through the following process.

1. 在 C 中进行更改.
2. 将更改推送到 git
3. CI 获取对 C 的更改并构建和部署新的 nuget 包.
4. 进入 B 并使用 nuget update package 命令更新对 C 的引用.
5. 将packages.config 文件的更改推送到git
6. CI 获取对 B 的更改，并为 B 构建和部署新的 nuget 包
7. 现在打开 A 并更改对 B 和 nuget 更新包的引用
8. 在 A 中进行更改以配合 B 中的更改(以及可传递的 C)

这看起来非常痛苦，并导致我们的一些开发人员质疑选择 Nuget 作为我们内部开发的代码.大家还是喜欢吃外部包的.

This seems extremely painful and is causing some of our developers to question the choice of Nuget for our internally developed code. Everyone still like it for consuming external packages.

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

Is there any better workflow for using Nuget internally?

推荐答案

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

In our company we have solved the cascading updates problem with the following setup. First we have the following setup for our NuGet repositories and build server.

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

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

• There is an internal NuGet repository that holds all the published packages for the company. This repository is just a shared directory on one of our servers.

• Each developer can have (but doesn't need to have) one or more directories on their own machine that serves as a local NuGet package repository. By using a user specific NuGet configuration the developer can control in which order NuGet searches through the package repositories to find packages.

<?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>

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

All solutions have automatic package restore turned on, so that we don't have to commit the packages to our version control system.

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

In order to make a change to one of the base libraries there are two possible processes being used. The first process is:

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

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

If more changes are required to (A) then repeat steps 1,2 and 3 and then delete the package of (A) from the working directory of (B). Next time the build runs NuGet will go looking for the specific version of (A), find it in the local machine repository and pull it back in. Note that the NuGet cache may thwart this process some of the time, although it looks like NuGet may not cache packages that come from the same machine(?).

更改完成后，我们:

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

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

Another way of doing the development work is by taking the following steps

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

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

The commit process is still the same, project (A) needs to be committed first, and in project (B) the NuGet reference to (A) needs to be upgraded.

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

The first approach is slightly neater because this process also warns if there are faults in the NuGet package of (A) (e.g. forgotten to add a new assembly) while in the second process the developer won't know until after the package for (A) has been published.

这篇关于我应该如何使用 Nuget 进行企业内部开发?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！