Npm and Continuous Delivery in Package Management

Hi. I’m Alex Mullins, a programme manager working on Visual Studio Team Services, Microsoft’s platform for development, continuous integration, and continuous delivery. Today, I’ll be showing you what’s new in the Package Management extension for Team Services, which hosts your packages and components so they’re easy to use from your dev machine and from your builds and releases. It’s been a great year for package management, and one of the biggest updates is our support for Team Foundation Server. This means you can now take advantage of Package Management in public, hybrid, and private cloud environments. With the release of Package Management for TFS, we’re also making the Team Services version generally available.

This means Package Management is now available worldwide in every Azure region that Team Services supports. We’ve also continued to build on our best-in-class support for the latest NuGet 3 updates by extending the service with commands like unlist, delete, and download. And we heard you when you said NuGet wasn’t enough, so we’ve added support for npm packages to support all you web and Node developers out there. And finally, we’ve been hard at work bringing new features to the service. With Release views, we’ve created a new way to communicate the quality of your packages. They work great in continuous integration and continuous delivery scenarios that frequently produce new packages. Let’s take a closer look. I’ll start with our improvements for NuGet packages.

You can now manage the lifecycle of your packages, with full support for unlist and delete. Just look for the buttons or check out the updated REST APIs. You can also acquire packages straight from the web, thanks to a new Download button, and again, a corresponding REST API. Next, let’s talk about npm. We’ve updated your existing Package Management feeds to support npm packages. So whether you’re using npm as part of an asp.net solution, as a Node.js developer, or for React development, you can now create and host your npm packages in Team Services.

Because the npm client is designed to talk to a single feed, or registry in npm speak, we support npmjs.com as an upstream source so you can use your private packages and packages from npmjs together. And finally, if you prefer to scope your private packages and get public packages directly from npmjs, Package Management supports that, too. Let’s take a look. To get started with npm, I’ll first create a new feed for my npm packages. If you already have an existing feed, you don’t need to do this.

When I create a new feed, there’s now a new option to include packages from the public npm registry. Because the npm client limits you to a single registry, checking this is usually a good idea.

Just like with NuGet, it’s easy to get started using Connect to feed. Let’s take a look. We’ve built a small npm package that will automatically help you get a personal access token in the right format for npm so it’s easy for you to use this private registry. For today’s demo, I’ve already installed the auth helper package, so the next step is to make a project-level npm configuration file, or npmrc, so that anyone who checks out this project can instal and publish packages to and from our private feed. So I’ll copy this information and make that file.

Then I just run the auth helper and credentials are stored automatically in my user profile npmrc, where they won’t be checked into source control.

Now I can get started. First, let’s instal a package from the npm public registry to see how that works.

As you can see, you’re now able to use both the private VSCS registry and npmjs.com at the same time. Let’s publish this package.

And if I return to the web, you can now see the package that I just published.

We support all of the NPM commands you’d expect from a private registry, so let’s take a look at a few more of those– things like dist tags, deprecate, and unpublish. For this demo, let’s add a dist tag and then deprecate this package.

Now I can look at the dist tags and see that there.

And I can also deprecate this package when I’m ready not to use it anymore.

And again, if I return to the web, I can now see the deprecation message right here. I can also unpublish the package, either from the command line or from right here in the web. Now let’s talk about continuous integration and delivery for packages. On the Package Management team, we talk with lots of customers who are using packages as part of their continuous integration and delivery workflows. Some are using them to deploy updated bits to a server. Others, to help compose a product or make a shared framework available to a set of products. But we’ve seen them struggle to communicate the quality of packaged versions when those versions are produced rapidly by CI builds.

Unfortunately, NuGet packages require you to specify the version before you’ve validated the package and determined its quality. In the days of file shares, this was OK, because you could overwrite a package version as many times as you liked until you produced one of adequate quality. But most NuGet servers, including Package Management, are immutable, which means that a particular package version can only be published once. We’ve seen people solve this problem in a variety of ways. Most commonly, we see people maintain two feeds, usually called debug and release, and controlling when packages are published to the release feed to protect quality.

But this solution causes problems because it stratifies versions of the package across two feeds, so there’s no longer a single source of truth for that package. So we built something new, called Release views, that enable you to make a decision about the quality of the package after it’s been published. Release views sit on top of the feed and allow you to philtre the contents of that feed to only package versions that have been promoted into that view. So you and your consumers can connect to that feed, @Release, and only see the subset of packages that are ready to use. Let’s take a look at how they work. Let’s take a look at the PhysicsEngine package.

It’s updated frequently, as you can see from the long list of versions. This makes it hard for the PhysicsEngine’s consumers to know which versions have been tested and validated. So let’s use Release views to make it easier. First, I’ll promote the latest version of this package that I’ve validated. For the sake of the demo, let’s assume that I validated this version 120 already. To promote a package into a Release view, I can just click Promote, select the Release view I want it to be in, and click Promote. So now my PhysicsEngine consumers can find only the packages I’ve validated by going to the @Release view.

Notice the much shorter version list, which insulates my consumers from the churn in my PhysicsEngine. If we take a look at the Connect to feed dialogue, you can see that it’s been updated to reflect the view we’re currently browsing. If my consumers update their local NuGet configs to point to the view directly, which you can see here, they can just rely on NuGet’s update functionality to automatically get the latest supported version of the PhysicsEngine package. Let’s take a look at that. Right now, you can see that I’m relying on version 101, which was the last tested version of the PhysicsEngine. I’m going to run a NuGet update.

And now, if I look at my package’s config again, I’m now up to that 120 version. Notice that we didn’t go all the way up to .121, because that version has not been tested and validated, and so we haven’t promoted it into the Release view. So Release views make it possible for my PhysicsEngine consumers to stay constantly up-to-date with the latest supported versions of my PhysicsEngine without being exposed to all the churn of a continuously integrated code base. We’re excited for you to try Release views as part of your continuous delivery workflows, and we’d love your feedback on how they work for you. Just use the Send a smile in your account. That’s it for today.

To try out Package Management, first, make sure to instal the extension to your Team Services account or Team Foundation Server, if you haven’t already. Then check out our docs, which have been refreshed and updated to cover all the features we just looked at. Thanks for watching.