Pipelines: package management strategy · Topic 1 of 2
Package Management Tools, Feeds and Upstream Sources
AZ-400 packages: Azure Artifacts versus GitHub Packages, feeds and roles, upstream sources, the local, prerelease and release views, and authentication.
- 6 min
- Includes a diagram
- Azure Artifacts: NuGet, npm, Maven, Python, Cargo, Universal Packages. GitHub Packages: npm, NuGet, RubyGems, Maven, Gradle, containers.
- Upstream sources cache public packages in your feed on first use.
- Default views: @local, @prerelease, @release. You publish to the feed, then promote to a view.
What it is
A package is a versioned bundle of code or binaries that other projects consume. A feed is the place packages are stored and served from. Using a feed instead of copying files gives you versioning, access control, caching and a record of what each build used.
This topic covers two tools, Azure Artifacts and GitHub Packages, and how to design feeds, views and upstream sources so teams consume reliable packages from both internal and public sources.
How it works
Choosing the tool
| Tool | Package types | Strengths |
|---|---|---|
| Azure Artifacts | NuGet, npm, Maven, Python, Cargo and Universal Packages | Upstream sources, feed views, organization or project scope, tight Azure Pipelines integration, Universal Packages for arbitrary files |
| GitHub Packages | npm, NuGet, RubyGems, Maven and Gradle, and container images through the container registry | Packages sit beside the repository, permissions follow the repository or organization, GitHub Actions integration with the built in token |
| Azure Container Registry | Container images and Helm charts | Private registry for images in Azure |
A short rule: pick the tool that matches where the team already works. Azure DevOps shops use Azure Artifacts. GitHub centred teams use GitHub Packages. Universal Packages (any set of files, such as a deployment bundle) are an Azure Artifacts feature.
Feeds
| Setting | Meaning |
|---|---|
| Scope | Project scoped or organization scoped. A project scoped feed is deleted with its project |
| Visibility | Who can see the feed: specific people and groups, the organization or the Microsoft Entra tenant |
| Roles | Reader (view and restore), Collaborator (also save packages from upstream sources), Contributor (publish packages), Owner (manage the feed) |
Pipelines run as a build service identity, so grant that identity at least Reader (and Contributor to publish) on the feed.
Upstream sources
An upstream source lets a feed provide packages that live elsewhere, such as the public registries (nuget.org, npmjs, Maven Central, PyPI) or another Azure Artifacts feed.
- Developers configure one feed and get both internal and public packages.
- When a package is requested from the upstream, a copy is saved into the feed (the @local view) the first time it is used. If the public registry is down or the author deletes the package, your builds still work.
- You can control which packages come from the upstream. The Allow externally-sourced versions setting on a package decides whether public versions of a name that exists internally are allowed. Blocking them protects against dependency confusion, where an attacker publishes a public package with the same name as a private one and a higher version.
Views
Feed views let you share a subset of package versions. Every feed starts with three views.
| View | Purpose |
|---|---|
| @local | The default. All packages published to the feed and all saved from upstream |
| @prerelease | Suggested view for versions that are tested but not final |
| @release | Suggested view for versions that passed validation and are ready for consumers |
Packages are published only to the base feed (the @local view). You then promote a version to a view once it has passed checks. Consumers point at the @release view and see only validated versions. Views are read only. The two suggested views can be renamed or deleted.
Promotion can be done from the portal, the REST API or a pipeline task after tests pass, so the pipeline decides what counts as release quality.
Connecting pipelines and tools
In Azure Pipelines, authenticate before restoring from or publishing to a feed.
steps:
- task: NuGetAuthenticate@1
- script: dotnet restore --configfile nuget.config
- script: dotnet pack -c Release -o $(Build.ArtifactStagingDirectory)
- script: dotnet nuget push $(Build.ArtifactStagingDirectory)/*.nupkg --source "MyFeed" --api-key azEquivalent authentication tasks exist for npm (npmAuthenticate@0), Python (PipAuthenticate@1) and Maven (MavenAuthenticate@0). Universal Packages use the UniversalPackages@0 task.
In GitHub Actions, the built in GITHUB_TOKEN can publish to GitHub Packages when the job has the packages: write permission. Outside Actions you use a personal access token with the package scopes.
Choosing quickly
| Requirement | Answer |
|---|---|
| Builds must keep working if nuget.org is unavailable | Azure Artifacts feed with an upstream source |
| Only validated versions are visible to production teams | A feed view such as @release |
| Prevent a public package replacing an internal one | Disable externally sourced versions for that package |
| Share deployment bundles that are not code packages | Universal Packages |
| Publish a container image next to the code in GitHub | GitHub Packages container registry |
A worked scenario
A company builds internal NuGet libraries and also depends on public ones. They create an organization scoped Azure Artifacts feed with the public NuGet upstream source, so developers use a single source. The build pipeline publishes each build to the feed, runs tests, and on success promotes the version to @release. Production teams use only the @release view, and the internal package names are protected from being replaced by public ones.
What to remember for the exam
- Azure Artifacts: NuGet, npm, Maven, Python, Cargo, Universal Packages. GitHub Packages: npm, NuGet, RubyGems, Maven, Gradle, containers.
- Upstream sources cache public packages in your feed on first use.
- Default views: @local, @prerelease, @release. You publish to the feed, then promote to a view.
- Feed roles: Reader, Collaborator, Contributor, Owner. The build identity needs access.
- Dependency confusion is prevented by controlling externally sourced versions.
"Share only tested packages" means a view and promotion. "Keep builds working when a public registry is down" means an upstream source.
How the exam asks about this
- "Developers use one source for private and public packages." Upstream source on the feed.
- "Make a version visible only after tests pass." Promote it to a view.
- "A pipeline cannot restore from a feed." Give the build service identity Reader access and run the authenticate task.
- "Store zip bundles of deployment scripts." Universal Packages.
Common mistakes
Trying to publish directly to a view. Publish to the feed, then promote.
Forgetting feed permissions for the build identity. Restores fail with 401 or 403 errors.
Using the public registry directly in builds. A removed or changed package breaks the build.
Letting public names override private ones. Control externally sourced versions.
Check yourself
Which Azure Artifacts view is created by default and receives published packages?
@local.
What does an upstream source do the first time a public package is requested?
It saves a copy of that package into the feed.
Which Azure Artifacts feature lets you share only validated versions?
Feed views, with packages promoted to a view such as @release.
Topic 1 of 2 in Pipelines: package management strategy
Test yourself on Pipelines: package management strategy
The full Microsoft AZ-400 question bank has 766 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.