Demo – Introduction to Package Management Part 1

Hi, my name is Colin from North West Cadence. In this intro video, I’m going to briefly introduce package management in Visual Studio Team Services, or VSTS. In this video, part one of two, we’ll look at how to produce a package. In part two of two, we’ll see how you can consume packages from a VSTS package feed. Package management allows you to share binaries. The binaries are stored in a discrete unit called a package. The packages typically have strict versioning scheme. Sharing binaries this way allows consumers to choose when to upgrade. Examples of package feeds are NuGet, node package manager, and there are many others. What are feeds? Feeds are logical groupings of packages. A feed typically has an address.

Some feeds can be secured to control access. The first step in producing a package is to describe the package. This is done using some sort of metadata. Once the metadata and the binaries are ready to be packaged, the package is created and versioned. Finally, the package is published to a feed. Let’s jump into a demo and see VSTS package management in action. Here I am in a VSTS team project called package demo. You also see that one of the hubs I have is a package hub. Let’s look at the package hub. Here you can see a list of feeds.

The feeds in VSTS are held at account level so that they can be shared between different team projects within the account. In order to get access to the package management hub, you’ll need to instal the package management extension from the marketplace. I’ve already done this. I browsed to marketplace.visualstudio.com and found the package management extension, which I’ve installed. Let’s create a new feed for this video called demo. I’ll create new feed, and we’ll call this feed demo. And here you can see I can set security on who can read and who can contribute to this particular feed. We’ll keep the defaults and select Create. We get a splash screen telling us the address of this particular feed which we’ll use later.

I have a project called Awesome Logger. The code for this is not important for this demo, but I’d like to share this Awesome Logger with other members of my team. Let’s drop onto the command line and create a new spec file to create a NuGet package that contains the binary for the Awesome Logger. Here I’ve browsed to the Awesome Logger project directory. I have NuGet in my path, and I’m just going to type NuGet spec. Let’s open up the new spec file. This is the metadata that describes our package. Here you can see the Awesome Logger new spec. Because the spec file was created from a project, it’s created some placeholders for me.

I’ve hardcoded all the values except for version. This will be filled in by our build so that the build number and the package version match. We’ll see how to do that when we set up the build. So here we are in VSTS, and I’ve come to the build hub. Let’s create a build for our package. We’ll select Visual Studio from the templates. Select the correct repository and branch. We’ll enable continuous integration, and select Create. Let’s go and remove the Copy Files since we’re going to build our package to the artefacts staging directory. Let’s now add two build steps to the build definition.

We’ll come to the package category, and add in a NuGet packager task as well as a NuGet publisher task. We’ll put those just after the test. Let’s go and edit the NuGet packager task. Let’s explicitly select the csproj file.

We’re selecting the csproj file and not the new spec file because NuGet will check to see if there’s a new spec and grab the metadata from the new spec, but it will include all the assemblies that are produced from the csproj. So we don’t have to explicitly specify the files in the new spec. We just have to make sure that the new spec and the csproj are in the same folder and have the same name. For the package folder, we’re going to select the artefacts staging directory. For versioning, we’ll select Use the Build Number. In order to use the build number, we’re going to have to make sure the build number is in a format that NuGet expects.

Let’s go over to General, and change the default format to 1.0$(rev;r). The first build for this will be 101, the second, 102, and so on. That gives us a versioning scheme that NuGet understands.

So that’ll create a package into our build artefacts staging directory called Awesome Logger .nupkg. Let’s go and look at the publisher task. We’ll change the path to the artefacts staging directory *.nupkg. For the feed type, we’ll select internal NuGet feed. For the internal feed URL, we’ll need to copy the URL for our feed. That’s over here on the splash page for our demo feed. So we’ll paste it in here. Let’s save that build definition, and we’ll call this Awesome Logger Package. We can now go and queue the build.

This will compile a project, run any tests, and finally, package and publish to the feed that we’ve selected.

Now that our build is completed, let’s go and look at our package feed. You can see that we’ve successfully published Awesome Logger version 101 to our feed. Let’s go queue a new build.

You can see the version number for this build is 102. Now our build of 102 is completed, we should see package version 102 in our feed. Let’s go and refresh the feed again, and sure enough, here we see that the latest version for the Awesome Logger is 102. If we scroll down a little bit on the package description, we can see the old version 101. In this video, I gave you a brief introduction to package management in VSTS and showed you how to publish a package to a feed.