NuGet Server for multiple environments?

Question

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.

• Is there built-in functionally around the idea of "promoting" packages through multiple environments (Test/Beta/Production)?
• Do I have to host multiple servers (one per environment)?
• Is there another solution to this that I haven't though of?

---

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.

Answer 1

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:

• 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.

• 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.

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

• 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.

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

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.

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.

So to answer your questions:

• There is no built-in functionality around package promotion in NuGet. However it is not that hard to setup a system that allows you to handle package promotion. Also there are some commercial NuGet servers that provide promotion functionality.
• You can host multiple servers but that's not always necessary. Nuget can use a file share as a repository as well, so for the test / beta environments you could use a file share and then use a proper NuGet server for the production environment.