{"id":43675,"date":"2018-05-23T16:35:13","date_gmt":"2018-05-23T23:35:13","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/devops\/?p=43675"},"modified":"2019-02-14T15:49:59","modified_gmt":"2019-02-14T23:49:59","slug":"upstreams-for-vsts-feeds","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/upstreams-for-vsts-feeds\/","title":{"rendered":"Use packages reliably with upstreams for VSTS feeds"},"content":{"rendered":"

Software packages are a crucial part of development in languages ranging from C# to JavaScript to Python to Go. They help you iterate faster, avoid solving a problem that\u2019s been solved many times before, and allow you to focus on your unique value. But, they can also add uncertainty and risk to your development process. Packages are sometimes removed from the public registries, or those registries are down. Even packages from other teams in your organization can sometimes become unavailable, if the creating team deletes the feed or has a retention policy that cleans up old versions you still rely on.<\/p>\n

With the upstream sources features that are now rolling out to all Package Management feeds, you can eliminate these concerns and consolidate all the packages you depend on into one feed.<\/p>\n

Upstream sources between VSTS feeds<\/h2>\n

Upstream sources (for NuGet and npm) are now available between VSTS feeds within the same account, and between feeds in multiple VSTS accounts that are within an organization<\/a>. With a few clicks, you can add another team\u2019s feed as an upstream source and start using their packages, without altering the NuGet.config or .npmrc in your project.<\/p>\n

When you use packages through an upstream source, a few helpful things happen. First, your feed saves a copy of the package that\u2019s retained until you delete it. That means that if the upstream feed goes away, your builds keep running. You can also manage this package just like any other package in your feed. If you want to move your team off an old version of a package from an upstream, you can unlist\/deprecate it or delete it. And finally, the saved package also remembers where it comes from and provides a helpful link back to the package in the upstream feed.<\/p>\n

\"A<\/p>\n

Upstream sources for public registries<\/h2>\n

You can also add upstream sources to public registries like\u00a0nuget.org<\/a>\u00a0and npmjs.com<\/a>. Just like with VSTS feeds as upstream sources, using public registries via upstream sources means VSTS keeps a saved copy of every package you use from the public source.<\/p>\n

Getting started with VSTS upstream sources<\/h2>\n

Setting up a VSTS upstream source is a 2-stage process. First, you\u2019ll need to ensure that the feed you want to add as an upstream source has a view that\u2019s shared. Feeds created in the last few weeks will already have this set up correctly.<\/p>\n

If the feed you\u2019re adding is older, have its owner go to feed settings, <\/strong>select the Views<\/strong> pivot, select the view they want to share with you (@local <\/strong>is a great one to start with), click Edit, <\/strong>and select the Shared with my organization<\/strong> radio button and click Save. <\/strong>Learn more about views and upstream sources in the docs<\/a>.<\/p>\n

\"The<\/p>\n

Then, to add an upstream source, go to feed settings<\/strong>, select the Upstream sources<\/strong> pivot, then select Add<\/strong>.<\/p>\n

\"The<\/p>\n

For more detailed instructions, see the docs<\/a>.<\/p>\n

Getting started with upstream sources to public registries<\/h2>\n

If you’ve created your feed within the last few months, you’re already set to use the\u00a0nuget.org<\/a>\u00a0and npmjs.com<\/a>\u00a0upstream sources, unless you selected “Only use packages published to this feed” when you created your feed. If you did, or if your feed is older, just go to feed settings<\/strong>, select the Upstream sources<\/strong> pivot, then select Add<\/strong>.<\/p>\n

New \u201cCollaborator\u201d permission for feeds<\/h2>\n

With upstream sources comes a new permissions level: \u201cCollaborator\u201d. In the private preview of upstream sources, we heard from many of you that there\u2019s a different level of trust between \u201centities allowed to publish my packages to my feed\u201d and \u201centities allowed to use packages from an upstream I already trust\u201d. If that sounds like you, you\u2019re in luck. \u201cContributors\u201d, as always, are able to publish packages directly to the feed (e.g. with npm publish<\/code>). \u201cCollaborators\u201d can save new packages from upstream sources (e.g. \u2018npm install package-from-upstream\u2019). \u201cReaders\u201d can only use packages that a Collaborator or above has already saved or published to the feed.<\/p>\n

What\u2019s next<\/h2>\n

Over the course of the summer, we expect to add support for other public\/non-authenticated NuGet and npm package sources. Upstream sources for Maven packages are on the backlog \u2013 help us prioritize by voting on this UserVoice item<\/a>.<\/p>\n

If you\u2019d like to learn more about the concepts behind upstream sources, check out the docs<\/a>.<\/p>\n

We\u2019d love to hear from you about how upstream sources are working for you \u2013 just shoot me a tweet @alexmullans<\/a> or use the blog comments below. If you run into any bugs (we hope not!), log \u2018em on Developer Community<\/a> and we\u2019ll take a look.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Software packages are a crucial part of development in languages ranging from C# to JavaScript to Python to Go. They help you iterate faster, avoid solving a problem that\u2019s been solved many times before, and allow you to focus on your unique value. But, they can also add uncertainty and risk to your development process. […]<\/p>\n","protected":false},"author":734,"featured_media":45953,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-43675","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"acf":[],"blog_post_summary":"

Software packages are a crucial part of development in languages ranging from C# to JavaScript to Python to Go. They help you iterate faster, avoid solving a problem that\u2019s been solved many times before, and allow you to focus on your unique value. But, they can also add uncertainty and risk to your development process. […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/43675","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/734"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=43675"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/43675\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/45953"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=43675"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=43675"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=43675"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}