How do you set up Azure DevOps Artifacts to publish and consume NuGet, npm, or Docker packages?
Quick Answer
Azure Artifacts provides hosted package feeds that support NuGet, npm, Maven, Python, and Universal Packages. Teams publish internal packages from CI pipelines and consume them in other projects using feed URLs configured in nuget.config, .npmrc, or Docker registry endpoints.
Detailed Answer
Think of Azure Artifacts like a company cafeteria versus the public food court. The public food court (nuget.org, npmjs.com) has everything but no quality control over what your team eats. The company cafeteria (Artifacts feed) curates approved ingredients, serves internal-recipe dishes (private packages), and caches popular outside meals (upstream sources) so lunch is faster and consistent even if the outside food court has an outage.
Azure Artifacts feeds are containers that host packages. Each feed has a URL that package managers (NuGet CLI, npm, pip) use to restore and publish. Feeds support upstream sources — connections to public registries that cache packages on first use. This means if npmjs.com goes down, your builds still work because packages are cached in your feed. Upstream sources also enable package approval workflows where only vetted versions flow into your feed.
Publishing from a CI pipeline uses built-in tasks: NuGetCommand@2 with 'push' for NuGet, Npm@1 with 'publish' for npm, or Docker@2 for container images to an Azure Container Registry (which integrates with Artifacts views). The pipeline authenticates using the build service identity — no explicit credentials needed for same-organization feeds. Cross-organization access requires a PAT or service connection.
Consuming packages requires configuring the feed as a source. For NuGet, add the feed URL to nuget.config. For npm, configure .npmrc with the feed's registry URL. The Azure Artifacts Credential Provider handles authentication seamlessly in development environments (interactive login) and CI environments (system token). The key concept is 'views' — feeds have @release, @prerelease, and @local views that control package visibility, allowing you to publish to @local during CI and promote to @release after testing.
The production gotcha is feed permissions and cross-project access. By default, feeds are project-scoped and only accessible within the project. Organization-scoped feeds are accessible across projects but require careful permission management. Another common issue is npm feed authentication in Docker builds — you cannot use the credential provider inside a Dockerfile, so you must use a .npmrc with a PAT token passed as a build argument (not baked into the image layer).