NuGet Server适用于多种环境? [英] NuGet Server for multiple environments?

问题描述

我一直在考虑为私人供稿设置NuGet服务器，这似乎很简单(有逐步指南).我预见到的问题是，它看起来并不是为支持多种环境而设计的.

I was looking into setting up a NuGet Server for a private feed, which seems easy enough (there is a step-by-step guide). The problem I foresee is that it doesn't look like it is made to support multiple environments.

• 是否在功能上内置了通过多个环境(测试/测试版/生产)推广"软件包的思想?
• 我是否必须托管多个服务器(每个环境一个)?
• 有没有针对我的另一种解决方案?

我主要担心的是，我们更新了一个程序包并将其用于我们的测试环境，但是我们不希望beta或生产环境在有错误的情况下失败...我们想等到更新获得批准" "，然后将其再次用于生产.

My main concern is that we update a package and utilize it for our test environment, but we don't want our beta or production environments to fail if it is buggy... we want to wait until the update is "approved" before it is made available for Beta, and then a second approval to make it available for Production.

推荐答案

在我目前的工作场所中，我们遇到了类似的问题.在不稳定分支中开发的NuGet软件包应可用于在我们产品的Alpha版本上进行的开发，但不能用于我们产品的Beta/RTM版本.因此，为了实现这一目标，我们建立了3个不同的NuGet存储库:

At my current workplace we have a similar issue. NuGet packages which are under development in an unstable branch should be available for development done on Alpha versions of our products but not for Beta / RTM versions of our products. So in order to achieve this we have set up 3 different NuGet repositories:

• 开发存储库:所有开发人员都具有只读访问权限的文件共享.文件共享中有一个用于存放NuGet包的空间，一个用于存放匹配的NuGet符号包的空间.只有构建服务器(和构建工程师)具有对此存储库的写访问权.

• Development repository: A file share that all developers have read-only access to. The file share has a space for NuGet packages and one for the matching NuGet symbol packages. Only the build server (and the build engineers) have write access to this repository.

质量检查存储库:与开发存储库类似的另一个文件共享.

QA repository: Another file share similar to the Development repository.

生产存储库:Klondike NuGet服务器用作所有可以在生产版本中使用的NuGet包(及其来源)的NuGet和符号服务器.

Production repository: A private instance of the Klondike NuGet server which serves as the NuGet and symbol server for all NuGet packages (and their sources) which are allowed to be used in production builds.

作为分支策略，我们使用 GitFlow .使用此策略可以使我们使用以下方法:

As branching strategy we use GitFlow. Using this strategy allows us to use the following approach:

• 在feature分支上完成的构建会将其NuGet软件包推送到开发存储库中.
• 在hotfix或release分支上完成的构建会将其NuGet软件包推送到QA存储库中
• 如果develop或master分支仅获得合并提交，则不会在这些分支上进行编译.

• Builds done on feature branches push their NuGet packages to the Development repository.
• Builds done on hotfix or release branches push their NuGet packages to the QA repository
• No compilation builds are done on the develop or master branches given that those branches only get merge commits.

将包引入生产存储库的唯一方法是通过QA存储库中的升级.为了实现这一目标，每个产品存储库都有一个指向master分支的构建.将新的合并提交推送到此分支时，构建将执行以下步骤:

The only way packages can be introduced into the Production repository is by promotion from the QA repository. In order to achieve this each product repository has a build pointing at the master branch. When a new merge commit is pushed to this branch the build takes the following steps:

1. 获取新版本的代码
2. 通过获取应用于新修订的版本号标签来确定该修订的版本号
3. 通过搜索nuspec文件并从这些文件中获取软件包名称，确定从新修订版中释放了哪些NuGet软件包.
4. 软件包名称和版本号的组合给出了完整的软件包文件名.
5. 在质量检查"存储库中找到软件包，并将其推送到生产存储库.还可以找到符号包并将其推送到生产符号服务器.最后，从质量检查存储库中删除软件包

1. Get the code for the new revision
2. Determines the version number of that revision by grabbing the version number tag that is applied to the new revision
3. Determine which NuGet packages have been released off the new revision by searching for the nuspec files and getting the package names from these files.
4. The combination of the package names and the version number gives the full package file names.
5. Find the packages in the QA repository and push them to the production repository. Also find the symbol packages and push those to the production symbol server. Finally remove the packages from the QA repository

该工作流程显然可以扩展为包括开发资源库，但是到目前为止，我们还没有看到它的必要.

This workflow could obviously be extended to include the Development repository as well but so far we have not seen the need for that.

请注意，如果您想以这种方式升级软件包，则向QA存储库供稿的内部版本必须生成具有最终版本号(例如1.2.3)而不是预发行版本号(例如1.2.3)的软件包，这一点很重要. -alpha0001)，否则促销版本无法确定要抓取的正确软件包.

Note that if you want to promote packages this way it is important that the builds that feed the QA repository generate packages with the final version number (e.g. 1.2.3) and not a pre-release version number (e.g. 1.2.3-alpha0001) otherwise the promotion build cannot determine the correct package to grab.

此方法的一个附带好处是，当开发人员将其代码推送到生产分支时，开发人员不必更改其项目文件，因为项目文件已经引用了正确的NuGet软件包版本.

A side benefit of this approach is that developers don't have to make changes to their project files when their code is pushed to the production branches because the project files already reference the correct NuGet package versions.

所以回答您的问题:

• NuGet中没有围绕包促销的内置功能.但是，设置一个允许您处理软件包升级的系统并不难.也有一些提供促销功能的商用NuGet服务器.
• 您可以托管多个服务器，但这并非总是必要的. Nuget也可以将文件共享用作存储库，因此对于测试/Beta环境，您可以使用文件共享，然后在生产环境中使用适当的NuGet服务器.

这篇关于NuGet Server适用于多种环境?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！