Using Azure DevOps Artifacts as Upstream from another Organization
In this post, App Dev Manager Chris Westbrook explores scenarios for Azure Artifacts upstream sources.
With this post, I want to draw attention to a relatively new capability in Azure DevOps services. 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.
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. Teams can also consume feeds from other teams as an upstream source, so that packages can be shared within an Organization. With the mentioned new feature, a team can now collaborate with teams in separate Organizations.
One thing to keep in mind though, is that it doesn’t readily allow the creation of nested/hierarchical feeds. In a previous version of this post I had described a hierarchy, but later discovered a flaw in the testing regimen. It’s now clear that a hierarchy isn’t straightforward. The reason is that upstream sources always use Views which are read-only to consumers. This means that you can’t create a hierarchy of Team Feed -> Department Feed -> Enterprise Feed -> Public Feeds, and have it work as expected. Consumers of the Team Feed would not be able to access packages in Public Feeds without someone manually pushing and promoting those packages to each intermediary level (Enterprise and Department). If you are a highly regulated organization and have a set list of approved packages to use, you may like this approach and can build scripts to automate where appropriate, but it is a lot of overhead that most teams should avoid. Therefore, the more typical approach will be for each team to configure public upstreams on their own feed, as well as upstreams to other team feeds that have packages they need to consume.
Let’s also discuss a scenario where Team A produces a package that Team B uses. Team B in turn produces a package that Team C uses. In this scenario, Team B is responsible for including the Team A package in its own feed (and promoting through Views as appropriate), since it is important for each feed to provide a complete graph.
If you are part of a larger group of development teams and have multiple Azure DevOps organizations this feature can enable access to all the packages made available by the enterprise while still enabling individual teams to manage their own feed.
Light
Dark
0 comments