NuGet Enterprise - best practices for different maturity levels of packages

Question

We want to use NuGet to share assemblies amongst developers in our organisation. We are currently looking at setting up three NuGet feeds, like this:

• Rele

Answer 1

In my view, the process you suggest is too complicated, both for your team size now and for the team size a year ahead.

I understand the reasons why you think you need three separate feeds (Dev, QA, Release), but I predict this will become painful for you in a year's time. I expect that you want to increase the confidence in the stability/quality of the packages as they progress from Dev to QA to Release - a completely reasonable requirement. However, separate branches and especially separate builds for Dev, QA, and Release is considered by many to be an anti-pattern. Specifically, in the seminal book Continuous Delivery by Humble and Farley, it's strongly recommended to have only a single code base from which builds are taken, and any of those builds should be capable of being promoted to Production if tests pass: "Build your code only once" is the key.

Instead of the pattern you outline, I would recommend that you:

1. Use a CI tool which allows you to model a deployment pipeline: Jenkins, TeamCity, TW GO, etc. This sets a good precedent for flowing artifacts directly from the initial CI build all the way to Production without a re-build
2. Use semantic versioning (called SemVer in the .NET world) to protect package consumers from breaking changes, and to communicate the nature of package changes to other teams.
3. Use version range constraints in packages.config so that builds are not broken by new Major versions of packages (with breaking changes)
4. Make dev teams responsible for specific packages from code commit to Production - if one of the packages they maintain has problems, they need to provide a fix rapidly so that other teams are not blocked. Teams also need discipline to ensure that they communicate the nature of package changes via SemVer (is it a breaking change? a new feature? a bug fix?)
5. If you feel it's necessary, use the Prerelease feature of NuGet to 'hide' new package versions from downstream builds and testing. This might allow dev teams to make changes more effectively, but will probably not be necessary if you use deployment pipelines which allow new package versions to be made and delivered rapidly.

In short, only build your source code once, and set up automation such that any fixes to existing packages can be rolled out rapidly using the deployment pipeline.