>> Alright. Hey. Hey Mitch, how are you doing?
>> Alex. I'm doing well.
>> Alright.
>> Thanks for asking me.
>> I'm doing great.
You are here to talk about
my favorite subject of all time,
Package Management here in Visual Studio Team Services.
>> Fantastic. So, I'm really interested
to hear what you've been
working on from a Package Management point of view.
So, here it's also little bit
about how the service has being evolving.
>> Yeah. So, we love listening to customer feedback.
If you've ever filled out a
developer community ticket or come
to our user voice visualstudio.uservoice.com,
we love hearing that feedback,
we take it in and we really do try to listen and improve.
And some of the things
we heard from customers were really interesting.
Things like, you help me tell people
when new versions of my package are available,
like make it more of a push model.
Send me an email, tell me, ''Hey,
I made something new and you can consume it.''
Making it easier also for people to use
packages from what we call Upstream Sources.
So, places like nuget.org and npmjs,
but in ways that I can configure
control in my organization, have a better understanding.
So, it's not just the wild west
of pulling in any open source that I want.
And then, even some basic things like, ''Hey,
I publish a lot of packages and
sometimes I want to clean them
up I don't want to look at the package.
I produce six months ago. So, we've added things
like retention policies to make that easier as well.
>> Well, you've been pretty busy.
So you covered a bunch of things.
So, what do you want to show us first?
>> Yeah. So, I think we'll dive right into
helping users keep up
to date with packages that you create.
And there's really two different ways
we've made to do that.
The first, we're going to look at
is just package notifications.
So, if you're a VSTS user you've probably
seen the notification settings before.
If I just go up to my face,
we'll do notification settings here.
And then, as soon as that pops up we'll
just make a new subscription,
it doesn't look pretty
familiar to anyone who's
used any of the other new subscriptions in VSTS.
>> So, you've plugged into
the builtin notification system within VSTS.
>> Exactly. So, the notifications look the same,
you can unsubscribe from them the same,
if you decide that we've sent you too
many. All that goodness.
>> Excellent.
>> So, I'm going to click new subscription.
And then we'll see just alongside all the other features;
the build, the code where
you're using it to get to your TFFC.
We have Package Management here at the bottom.
And now I can see I want to be
notified whenever a package is changed.
>> Correct.
>> And so, great.
It's going to deliver to my preferred email address.
I can also deliver to another email if I want that
and it's going to pop in some filter criteria here.
And so, the key with these notifications is I can
do really as much or as many
notifications as I want or as few.
So, in this case let's take your Adventure Works
feed. So, me go ahead.
Actually we're in a different account
will do the Fabrikam feed.
If you're a user of our release views
feature that came out I think about a year ago.
This is a feature where you can subset your packages
into views that are released or ready for consumption.
You can filter notifications to just one of those views.
>> All I can see where it would be really useful because
if you've got a build process
which is producing a lot of packages.
>> Exactly.
>> What too much noise.
>> Yep. And so, as a package producer if I say,
hey I promoted this package to release
now you only get an email once a week,
instead of once every 20 minutes.
>> Fantastic. I love that feature.
>> So, let's say packages from Fabrikam Release.
Now, this of course will tell me if there's
any package in that feed that promoted.
Maybe I only care about a specific package.
So, I can choose package name,
and I can enter any package that I want.
I will say I like cycle works.
If that's a package that I have.
I can just go ahead quick finish.
And then, anytime a new
version of that package is published,
I'll get a notification.
>> And so, this works for NuGet and NMPjs?
>> It does it works for any package
you store in Package Management.
Now, another way to stay up to date with packages,
is something that we call badges.
If you've ever been to like a GitHub README,
you know those little squares you see up at the top,
you see like my GitHub status,
my NuGet package status.
Yes you are familiar with those. So, we have those
now in Package Management as well.
So, I'm going to click into my favorite demo package,
my venerable Bacon package,
makes me hungry every time.
And I can just create a badge.
So, if I click in here,
and you can see again, we have
integration with release for you.
So, you can show basically
the latest version of
the package and any view or if you don't use views,
just the latest version in the feed.
>> So, why would I use a badge like this?
>> Yes. It's a great question.
So, if you have a README something on GitHub,
I'm actually going to go put this on
my project home page on VSTS.
It's makes it more of a one stop shop for users.
So, instead of you having to go and say,
"Oh, I know there's a new build."
I'll go to Builds, I know there's
new packages, are going to Packages,
and makes it so if I go to my project home page,
let's go back to my FabrikamFiber home,
you can see I already have a build badge here.
So, it's easy to click in and see the status of my build.
And now, if I add a package badge
and we'll pre-generate the markdown for you.
So, all you have to do is just paste it right in.
I'll go and commit this.
So, now you can also see the
latest version of my NuGet package.
So, if someone finds your package,
your project and search,
they just click on the new badge
and it'll take you right back to that job.
>> So, when to produce a new version
that you get packaged within that feed,
that number will update?
>> Exactly. So, two different
ways of helping customers know that you've made
a new version of a package available to them.
>> That's a great feature.
>> Awesome.
>> So, what's next?
>> So, we're going to switch gears a little bit now and
talk about a feature we call Upstream Sources,
a convoluted name. So, really.
>> It sounds pretty scary.
>> And certainly, we hope it's not.
What we wanted to do is make it possible to
basically collate all the packages that you use whether,
from public sources maybe even from other VSTS feeds.
If you're in a large organization and
bring them all into your feed,
with what we call provenance information.
So, it's like, hey I know this came
from over here from nuget.org or whatever but,
I'm using it through my feed.
Do things like save, copies of packages.
So, if NPM goes down,
if someone pulls a left pad and deletes a package
off the public registry, your builds keep going.
So, as long as VSTS is up and we
have that enterprise grade SLA and all that good stuff,
then you can keep your bills running and
your organization continues to be productive.
>> So, it actually changes a couple of things in it.
Simple one, is the number of feeds
needed from consumer but it also helps
make your build process more secure in terms of
the Upstream Sources going on.
>> Exactly. So, we'll
take a look at how to set one of those up.
I'm going to come over here to my Fabrikam feed.
And so, there's really two ways.
If you're new to Package Management,
and you haven't gotten started with us yet,
the first time you create a new feed,
you'll see a new option down here
as soon as this page warms up.
Where I can just say, "Hey, I would
love to use packages from public sources."
And so, this is nuget.org npmjs.com.
When you create a field like this,
let's call Mitch on our view,
and I'll go and click "Create."
Then all of my Upstream Sources are just wired up.
As soon as I put this patch feed into my NuGet client,
then I have access to everything that
comes from nuget.org automatically.
So, if we go back and look at
one of the fees we were looking at earlier,
we can actually see some of this in action.
You see these are all packages that I
saved from npmjs at one point.
>> So, you manually publish these into your feed?
>> Exactly. I connected to this feed just like this.
I said, here NPM know about my registry here.
Go ahead and connect to that.
And then when I ran I think it was NPM install express.
A great front and web framework.
All the hundreds of dependencies that that brought in,
all now saved in my feed all protected.
Again, that continuous reliable build process.
>> And so, those ones that there and you will see
those packages can't be replaceable in
the upstream sources that looked of that version.
>> Exactly. And so,
now let's go back to Mitch's feed,
we can see if I happen to feed setting's here briefly.
We can see what that looks like.
We'll just go to the Upstream Sources pivot,
and you can see here I have an NPM,
I have a nuget.org and now also add VSTS feeds.
So, if I have multiple feeds,
it's a large organization and I don't want to have to
go and edit my NuGet config files all the time.
I can just do it all server side.
One person can take on the burden and say,
I want to use packages from these teams.
>> So, there will be another team
producing a library that your team consumes,
but you only want to have one feed for your time.
>> Exactly. It helps me
manage all my dependencies in one place.
So, I can come to Package Management.
I can see exactly what's going on.
So, in this case,
our imaginary Contoso feed has some packages.
You can see just like before,
heavily integrated with release views.
So, if you choose to use views, in this case, I'll say,
"Hey I only want to use packages from
Contoso that they've released."
And actually, it's up to the feed producer to say, "Hey,
this is the view that I'm making available to you."
Some teams may choose to use what we call the local view.
That's just all the packages in your feed.
So, you don't feel you have to use release views
to get benefit out of Upstream Sources.
But they definitely work better together.
>> Fantastic, I love it.
>> Perfect, so I can add that in,
and then I'll just go ahead and save this.
And just as before now,
if it connects, I can install
packages from the cantoso feed.
They show up here again and have full what we
call provenance information
showing where this package came from.
>> So, the first time that I do
restore or install file on NuGet or NPM,
that's when this will get populated.
>> Exactly.
>> Sometimes they'll come from the Upstream Sources.
So, one of those issues with NuGet is that,
if you get multiple feeds hard to predict,
the order in which things will get
installed still does this help with a little?
>> So, it does. So, the context for the audience,
so every time NuGet runs.
If you have multiple feeds in your NuGet config file,
it just sends out requests to all of them
and whichever one comes back first, wins.
And so sometimes especially at Microsoft,
we actually see odd situations where
people have customized packages,
maybe pulled out VLLs they didn't think they needed,
added VLLS they thought were better,
and it was confusing.
Sometimes you'd get one package,
sometimes you'd get the other.
With Upstream Sources, we guarantee that as long as
the feed that has those streams
is the only feed in your config,
you always get the same back you got the first time.
So, now I'm thinking on the other
side of the package life cycle.
Let's go back to one of my bigger feeds here.
I think there we go we can actually jump into that.
So, sometimes we end up with
a lot of versions of packages.
As you mentioned,i f I'm producing
these in continuous integration,
sometimes you can see I have
200 versions of this Bacon package.
I got a little eager as we're going along.
And I don't need all this burden.
It's a little bit of a pain to scroll through,
and you can see that I've been good with release views.
I've marked the packages that I'm actually using.
So, before like I could select and I could
certainly go and manually delete
them and that would be great.
But now, we have a feature called retention policies,
where I can go into the feed settings
and just enter a number here and say,
"No, I only need, let's
say the last 20 versions of this package."
All right and I'll click "Save."
And the key thing here is anything I
promoted to a view as exempt.
We'll keep that for like we assume that,
maybe you deployed it somewhere, maybe you shipped it.
Maybe you're like Windows and you
need to keep it around for 10 years.
And we're happy to do that for you.
But, that CI exhaust,
what we call it don't have to keep that around.
>> That sounds really useful.
So, that means that keeps that view
nice and tight in terms of
the number of packages you're dealing with.
>> Exactly. And if the handle,
if maybe we cleaned up something
that you didn't want cleaned up or maybe I'm
just going to manually
delete this package and I didn't mean to.
And I ignored the red warning, everybody
just clicks right through that.
We've now added a recycle bin to the product,
it's a basic feature
but definitely nice to have where I can say,
"Hey, I really didn't mean to delete that package.
I would really love to have it back."
And now I can just restore it to the feed,
build start working again.
No panic, no having
to deal with a new version numbers any of that.
>> So, that's just the way it was.
>> Exactly. Just like the Windows recycle bin,
just like put it back please.
>> Fantastic. That's awesome.
>> Yes that's the whirlwind tour what you think.
>> That's a lot of things
that have improved for people to use in
Package Management and I can see how those improvements
will help improve
the reliability of the engineering system.
And actually simplify it a lot as well.
So, I think that's a fantastic set of features.
>> Awesome. Package Management
honestly does best when it fades into the background,
like we love you coming to our user experience.
But at the end of the day if packaging just works and
you're sharing code and you're succeeding.
that's really what we want to see.
>> Excellent. Thanks very much.
>> Absolutely. We thank you
for tuning in and watching and we'll see you next time.