>> Hi, I'm Alex Mullans,
a program manager on the Azure DevOps team.
Today, I'd like to introduce you or
maybe reintroduce you to Azure Artifacts.
Azure Artifacts is one of the five services in Azure DevOps,
a suite of tools from Microsoft
designed to help software teams plan,
build, and deliver software.
Azure Artifacts specifically focuses on
managing all of the artifacts and all of the tools,
the binaries, anything around
your software development process that's not source code.
That includes things like packages,
we support common package types like Maven,
NuGet, NPM, and Python.
So whether you're a.NET developer writing C#,
or a Java developer,
maybe writing some NodeJS server code,
or writing a front-end using a bunch of NPM packages,
Azure Artifacts has you covered,
and we can serve both your private packages
and help you keep a safe copy of
all the packages you use from
public sources like the NuGet gallery or PyPI.
If none of those package types are what you're looking for,
we also have universal packages,
a very lightweight and easy to use
package type that can wrap up any file or set of files that
you want to publish that has great de-duplication
so we can minimize all of
the files that you send up to the servers,
especially if you're working with large sets of
files that only change a little bit version over version.
In addition, if you're writing code, especially native code,
and you want to help teams across your organization debug,
Azure Artifacts contains a symbol server that you can use as well.
Azure Artifacts also powers
the new pipeline artifacts that you'll hear
more about from Azure Pipelines,
which help you really quickly move files between
jobs and stages as part of your DevOps pipelines.
Now, if you've been with us for a while,
there's a few exciting announcements we have at Build this year.
The first is around Pay-per-Gigabyte pricing.
We heard your feedback that
our user licensing models just
simply didn't make sense for a lot of you.
It was hard to set up. It was challenging to understand.
It required a lot of manual work getting,
and assigning, and buying licenses,
and so we've moved to a straight
consumption-based model that'll look
very familiar if you're coming from other Azure services.
Every Azure DevOps organization
gets two gigabytes of storage for free,
and there's tiered pricing after that that you
can find more about on Azure.com.
If you're an existing organization
that's used Azure Artifacts in the past,
you'll get 12 months of free usage as
a transition between user licensing and Pay-per-Gigabyte storage.
In addition, our support for Python packages and
our universal packages are now fully GA.
They've been in preview for a while
and we've already seen teams across
Microsoft and outside taking production dependencies on them,
but they're now fully GA and ready for
you to use and we look forward to your feedback.
Now, lets hop out of slides and take
a look at a few demos of Azure Artifacts.
I'll tab over here to my Azure Artifacts page.
If you're new to Azure DevOps,
we have our set of services over
here as you saw on an earlier slide,
over here on the left.
I'm going go to "Azure Artifacts",
which is here the pink set of deck packages.
On the Artifacts page is fairly straightforward.
I have a set of feeds,
think of feeds as a way of containing your packages.
By default, you'll have one package feed that
you can use across the entire organization.
But, if you want more control,
if you have teams that need to
share packages with just a subset of people,
you can use individual package feeds to do that.
Package feeds and Azure Artifacts are cross package type.
So you can have NuGet, NPM, Maven,
Python, whatever kind of packages you want.
All inside the same feed managed by the same set of permissions.
So there's no managing multiple repositories just to
have multiple package types in your organization.
In addition, Azure Artifacts
supports what we call upstream sources,
which help you use packages from public places,
like the NuGet gallery or PyPI in your feed.
I've already set them up, and we'll
take a look, and how that looks.
If I go to "Feed Settings", and "Upstream Sources",
and you can see this feed is configured to use all
of the upstream sources that we have available.
Going back to the feed, what that looks like,
if I clear our "Feed Filter",
you can see that in addition, to the packages that I've published,
these are my own company's packages,
I have packages that we've kept safe from PyPI,
from NPM JS, from the NuGet gallery.
So this is a great way to keep all of
the packages that you depend on in one place.
In addition, you can also see that we
have usage statistics on your packages,
both number of downloads and number of unique users.
So across your organization,
you can see the packages that are the most popular.
You can see in this demo feed,
we don't have a lot of real usage but if I
click over to one of our production feeds,
you'll see that that starts to help you ascertain
which packages we're supporting and
which ones you might want to consider deprecating.
Now, once you've configured a feed with upstream sources,
coming back to my "Demo Feed",
you'll click "Connect to Feed",
and do some setup on the client to basically
tell your computer about the Azure Artifacts feed.
I've already done that. So when
you want to use a new package from NPM,
in this case, let's assume I want to install the chalk package.
I can do that, and along
the way Azure Artifacts will keep a copy of this package,
put it into the feeds, so that any future developer that
uses it can get it directly from Azure Artifacts.
No need to go all the way to NPM.
So let's go and go back. I'll refresh here.
Now, I can see that we've saved a copy of
that chalk package into the feed.
Next, let's take a look at
how Azure Artifacts and Azure Pipelines work well together to
help you use and keep safe the artifacts that
you use as part of your DevOps Pipelines.
Moving over in Azure Pipelines.
What I have here is a very simple CI Build.
I'm going to take one of the packages that we
looked at earlier and build it in
Azure Pipelines and automatically publish it over to Azure DevOps.
Let's go and take a look at what this pipeline looks like.
In CI, you have fairly straightforward Azure Pipeline.
I'm triggering a new Build,
every time there's a check-in to the master branch,
I'm going to use a Windows VM.
I'm going to do a couple of things here
in my Azure Pipelines YAML file.
When you use the DotNetCoreCLI task,
which basically runs DotNet commands but also helps
me set up authentication to Azure Artifacts feeds.
This case, I'm going to restore packages.
This project depends on the NUnit package.
So we'll go ahead and install that from my codesharing-demo feed.
I'm going to pack this package.
I'm going to create a release version of it.
Then finally, I'll use the DotNetCoreCLI again
so I get DotNetAuth setup correctly.
I'll push this package out to the codesharing-demo feed.
So I'm going to switch to Visual Studio Code briefly,
and I can update this package.
In this case, we're just going to change
the version number and we're going to commit that.
Once that's pushed up to the server,
if we go back and look at our pipeline again,
I can see that there's going to be a new Build running in
the background and that's going to publish
a new version of my package straight to the feed.
So that we don't have to wait for that,
I'll actually jump and look at the last version of
the package that we published yesterday.
So going back to my codesharing-demo feed,
let's go find the bacon package.
We've added Provenance information
inside of Azure Artifacts to make it
easy to connect the packages
that you produced to the Builds that they came from.
So you can see in this case,
within the starter packages project that I'm working in,
I have this Build that ran yesterday and I can click over,
and you see we're back to that same set of Build results,
and I can now understand where
my packages came from, whether they were built.
This can help me do things like make sure that
packages didn't come from inside a developer machine,
and instead came through my proper Azure Pipelines.
Now, in this case,
I've published a package to my internal feed and that's great,
if I want to share it with users inside my organization,
but I can also use releases in
Azure Pipelines to take this package
and publish it out to NuGet.org.
So let's take a look at that.
I'll switch over to "Release Management".
In this case, let's take a look at my
published to NuGet.org Release.
Inside "Release Management", if I
click on "Add" next to "Artifacts",
there's an Azure Artifacts artifact type which
we've newly updated here for Build this year.
In it, I can select the feed and
the package that I want to publish.
In this case, collect my codesharing-demo feed.
I know that I want to publish this bacon package out to NuGet.org.
I'll publish the latest version every time this release runs.
You can customize that if you want.
Most importantly, I'm going to skip extracting this package,
so that I have a copy of
the actual NUPKG file that I can publish up to NuGet.org.
In this case, I'm not actually going to add this
because I have a pre-existing artifacts setup
which looks the same, you can see that here.
Then it's really a straightforward released to go ahead and take
this package out and published it to NuGet.org.
In this case, I'm going to use a visual designer release.
I'm going to select the NuGet task, use the push command.
I'm going to select that artifact that
I pulled down, that we just looked at.
I've set up a service connection to help me
publish this out to NuGet.org.
So I'll go ahead and let that happen now, perfect.
Again, we won't wait for that to complete,
but know that we have in the past
published this package successfully out to NuGet.org.
Now, for one final demo,
let's take a look at universal packages.
Again, these are
kind of a lightweight and flexible package type that
you can use to share any tools or binaries or scripts,
anything that you don't want to check in your Git repository,
but you want to use as part of
your Azure Pipelines or other DevOps processes.
So in this case, I'm going to jump directly to a shell.
When I go to publish an Azure universal package,
I use the address CLI.
This is something you can get through
the Azure Artifacts documentation.
So I'm going to say Azure Artifacts universal and publish.
In this case, I'm going to take this whole repo
that I have as starter packages.
So that has some things I've checked into Git and it
also has a set of files that I'm ignoring,
things that are binaries that really don't belong in
Git but I want to put somewhere.
I've told her about my codesharing-demo organization, my feed.
I've given it a name and a version.
That's really the core component of a universal packages,
the name, the version,
and I've given it a description,
in this case as well.
Then finally, I'm having it published
the path that I'm currently on.
So I'll let that run. It's really as simple as that.
Then if I want to use that package
and in Azure Pipelines for instance,
I can set up the same sort of artifact that
you saw me set up in the previous demo,
and pull these tools or these samples
right back down into my release process.
Great. While that uploads in the background,
let's talk a little bit about what's next for Azure Artifacts.
Probably, most excitingly by the end of Q2
we'll be adding public feeds to Azure artifacts.
So if you're doing open source development on
GitHub or with a public Azure Repo,
and you want to share nightly your
pre-release versions of your packages.
Packages that aren't quite ready for NuGet.org or NPM JS,
wherever you're trying to publish them.
We can store those for you in Azure Artifacts,
but have them publicly and world accessible.
So look for more on that by the end of Q2.
In addition, we'll be refreshing a lot of
the Azure Artifacts hub pages
to make them easier and a lot faster to use,
especially if you have big packages in your feeds.
Finally, we'll be doing more with
upstream sources to make them even simpler and easier to use,
especially if you're working across
Azure DevOps organizations or in a large enterprise,
something like the size of Microsoft.
To learn more about Azure Artifacts
you can use the aka.ms link that's
there on the screen or you can hit me up on Twitter @alexmullans.
Thanks and have a great Microsoft Build 2019.