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

本文介绍了我应该如何使用 Nuget 进行内部企业开发?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我们使用 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，而 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.

在 C 中进行更改.
将更改推送到 git
CI 获取对 C 的更改并构建和部署新的 nuget 包.
进入 B 并使用 nuget update package 命令更新对 C 的引用.
将 packages.config 文件的更改推送到 git
CI 获取对 B 的更改并为 B 构建和部署新的 nuget 包
现在打开 A 并更改对 B 和 nuget 更新包的引用
在 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	estpackages" />
    <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:

对基础库 (A) 进行更改.如果需要，更新 (A) 的版本.
运行 MsBuild 脚本构建二进制文件并创建 (A) 的 NuGet 包
将新的 NuGet 包复制到本地计算机上的包存储库中
在依赖项目 (B) 中升级到 (A) 的新包，这些包刚刚放置在本地计算机包存储库中(其版本应高于公司范围存储库或 NuGet 中可用的版本.组织)
对 (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(?).

更改完成后，我们:

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

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

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

对基础库 (A) 进行更改.如果需要，更新 (A) 的版本.
构建二进制文件
将二进制文件复制到 NuGet 为项目 (B) 解压 (A) 包的位置(例如 c:mysourceprojectBpackagesProjectA.1.2.3.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 包中是否存在错误(例如忘记添加新程序集)，而在第二个过程中，开发人员直到包之后才知道for (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 进行内部企业开发?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！