Using Azure DevOps Artifact as Upstream from another Organization
In this post, Sr. App Dev Manager Chris Westbrook draws attention to a relatively new capability in Azure DevOps services: upstream sources for Azure Artifacts.
You can now add an Azure Artifacts repository from a separate Organization that is within your same AAD as an upstream source. This feature was introduced this past August and can be very helpful for larger organizations with multiple Azure DevOps Organizations that share a common Azure Active Directory. This feature can be used to setup a hierarchy of feeds that allow individual teams to control their own feeds while participating in a larger ecosystem, giving the enterprise a better view of what packages are being used across all the teams.
Many development teams use NuGet and other package management systems to manage their component dependencies. A common practice is to include the configuration of where and how to resolve packages in a project’s source control repository. (See this article on setting up a multi-developer NuGet environment.) Another common practice is to configure one team controlled package feed as the primary source of packages and then use the concept of upstream sources to retrieve packages from other, often public, sources. This team owned feed can also house team created packages.
With the mentioned new feature an enterprise can now setup a hierarchical structure something like: team feed => department feed => enterprise feed => public feeds. This hierarchy can be both completely within Azure DevOps (not requiring separate tool setup and maintenance) as well as within the enterprise’s identity boundary provided by Azure Active Directory simplifying permissions and user management. This structure enables both team control and enterprise visibility.
This process also creates a backup of the public feeds in case they become temporarily unavailable. As a team member requests a feed with an Install-Package command or does a restore after updating their packages list, the search will progress up the tree until it finds the package, which may be in the public NuGet feed. The package will then be installed in each feed on the way back down until ultimately it is installed on the developer’s machine at the end.
One disadvantage is that the GUI tools in Visual Studio will only show you the packages installed in your immediate feed, which in most cases would be the team feed. In order for a developer to install a package that hasn’t already been loaded into the team feed they will need to use the command line not the GUI tool. Luckily the NuGet website makes it easy to browse and locate the needed command line so this shouldn’t pose too much of a burden.
If you are part of a larger group of development teams and have multiple Azure DevOps organizations this feature can enable visibility into all the packages being used by the enterprise while still enabling the team to manage their own feed.