Lesson276 words

Feeds, views and upstream packages

Design and implement package feeds and views

Feed scope — and the one-way door

ScopeVisibility
Project-scopedThe hosting project only
Organization-scopedAny project in the organisation; cannot be converted to project-scoped

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

Ready to study Designing and Implementing Microsoft DevOps Solutions (AZ-400)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free