Design and implement package feeds and views

Feed scope — and the one-way door

That conversion restriction is a genuine design decision, not trivia: choosing organisation scope is irreversible, so scope deliberately at creation time.

Feed Reader is the lowest feed-level role that can list and download packages. View permissions are a separate access path: a shared view can grant downloads through that view without direct feed access.

Views

Every feed ships with three views: @local, @prerelease, @release. The latter two are suggestions you may rename or delete; @local is the default.

Two rules that catch people:

Feed views are read-only. A consumer connected to a view can only use packages published to it or previously saved from upstream.

Packages can only be published to the base feed, where they appear in @local. You cannot publish directly into @release.

Promotion is not a publish and does not move a stored copy between view-specific stores. It appends the target view to the existing package version. @local contains all packages published to the feed plus all packages saved from upstream sources.

Views + upstream together

To let another feed consume yours as an upstream source, set your feed's visibility to members of your organization or members of your Microsoft Entra ID. That combination — a curated @release view, consumed upstream by other feeds — is the enterprise sharing pattern.

Primary sources

• https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-400
• https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/feeds
• https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/views
• https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/views
• https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions
• https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources