Nope. Not really—at least, not for the reasons you probably think. Obviously, sticking to NuGet best practices (authoring, versioning, vulnerability scanning, and so on) is best for your organization. It sets and keeps consistent standards, and helps your team to scale quickly.

So… why does following CI/CD best practices for NuGet packages trap teams in a CI/CD loop? NuGet with CI creates a lot of noise—tons of packages, library changes, and CI builds, along with the difficulty of keeping track of all the version numbers. And if you try to apply an application pipeline to NuGet? Yeah, that’s where things fall apart, since NuGet packages are unusable until publishing.

In this article, we’ll quickly break down a few NuGet best practices that can (ironically) end up clashing with your CI/CD pipeline, and touch on a solution to your NuGet CI/CD woes!

Packages are Immutable

We’ve said it a bunch of times in our blogs, and in a couple of our tutorials too: Packages are immutable. Once published, NuGet packages are locked in: you can’t edit the version number, change its status, or modify anything—it’s read-only, full stop.

Likewise, much of the data you’d want to change, version number or otherwise, is backed into the package’s metadata file (the .nuspec file).

Breaking the immutability rule—say, by downloading and overwriting packages—will cause chaos in your private NuGet repository. If you want to implement a smooth, reliable CI/CD pipeline, you’ll need to respect immutability.

Untested code shouldn’t be deployed

“Instead of renaming a package, why not rebuild a package with the same components?”

A totally fair question, but this line of thinking will backfire down the line. Rebuilding a NuGet package, even if everything looks the same, can produce different software due to wildcard version dependencies. You might think your rebuilt package is identical, but you still have to test it all over again before you can safely deploy it.

Avoiding this best practice risks unintentionally introducing vulnerabilities in your applications. Not great. For a successful CI/CD pipeline with NuGet, you need a way to create a new package from an existing package, using completely identical contents, while changing the version number and tracking the change.

Only deploy stable packages

Hopefully, this one’s already second nature: it doesn’t make sense to deploy pre-release packages to a production environment. Only stable packages should ever be released with your application.

You may have tried tagging your packages with pre-release labels (e.g. –ci.1, -ci.2, ci.11), then testing them in the application, releasing them to production when they pass. Don’t do this! Don’t use unstable versions of a package in your application—especially if you’re following CI/CD best practices.

Again, you need a way to push existing pre-release packages into release candidates, then to stable releases, all while tracking changes.

What’s the solution to NuGet and CI/CD Pipelines?

In order to escape the “CI/CD Loop,” you need package immutability, Semantic Versioning, and Continuous Integration for your NuGet packages. In ProGet, this is known as “repackaging.”

You can do it manually by downloading the package, opening it as a zip, and editing the .nuspec file. OR, you can rely on a specialized tool, either within your pipeline, like with BuildMaster, or with a private NuGet package server like ProGet.

What’s the solution to NuGet and CI/CD Pipelines?

Your CI/CD pipelines might work for everything else, but when combined with your NuGet packages, you end up dealing with a torrent of immutable, unused packages, and production applications containing unstable builds.

Keep implementing proper CI/CD best practices, but eliminate the friction between these effective tools and NuGet, with Repackaging, which lets you rebuild packages exactly as they were, but versioned ready for release.

This may be a lot to remember, so be sure to bookmark this page for future use! If you want even more insights, grab our free eBook, “NuGet at Scale”. It’s packed with info on authoring private NuGet packages in scaling organizations, NuGet package vulnerability management, and more! Download it for free today!