What is dependency management? With modern software architectures and development methods, software dependencies can become intertwined quickly. With more online repositories like GitHub and Docker Hub, pre-built libraries and services can be easily published and leveraged. These projects can be managed by all sorts of individuals or groups, and have a wide range of work ethics from well-maintained solutions, with good community and multiple contributors, and release schedules, all the way to the other end of the spectrum. Code is also developed internally and is often reused. Wherever the source comes from the problem is the same. Once implemented, one project now has a dependency on another.

When a team comes together to build a solution, they may decide for various reasons to leverage code that already exists. Depending on the type and language used for the project, there are different sources that can be leveraged to accelerate development. For instance, let's say you're running a .NET application, that's going to be processing JSON, that you retrieved from Azure to describe Azure resources.

Rather than having to write all the logic to handle the JSON, your team decides to leverage a popular package called Newtonsoft.Json, which is a publicly available package. You could leverage the NuGet package that's already been built and published for consumption.

By leveraging this package in your code, you have created a dependency on the package for your solution.

A package is a standardized way of distributing codes that can be consumed by another application or solution. Metadata is used to help store and version, and identify these packages.

There are different types of packages, as shown here in the image, that can be retrieved from upstream sources, found in artifacts in Azure DevOps.

NuGet. NuGet is a free open source package manager, designed for the Microsoft development platform used in .Net, since its introduction in 2010. NuGet has evolved into a larger ecosystem of tools and services. NuGet is distributed as a Visual Studio extension. The NuGet package has a.nupkg suffix, and as a zip file with a specific folder structure.

Maven packages are often used for Java projects. Maven can also be used to build and manage projects written in C#, Ruby, Scala, and other languages. A Project Object model file describing the metadata of the project is stored within the package.

NPM is a package manager for JavaScript programming language. It's primarily used for runtime environments with Node.js. An NPM package contains a package.json file, describing the metadata of the package.

The Python Package Index is a repository of software for the Python programming language. Python's packaging is built for distributing reusable code, called libraries, between developers. These packages are libraries used as building blocks to create applications, and have a.tar.gz extension.

Azure DevOps also has the ability to store Universal Packages. A Universal Package installed one or more files together in a single package that have a name and version, which is useful for many ad hoc situations where you want diversion and track files.

Containerized workloads are becoming more popular as platforms like Kubernetes are becoming mainstream. Docker images are generally complete self-contained systems.

Azure artifacts is available in Azure DevOps, DevOps server, as well as in Team Foundation Server 2017, and 2018. The sources allow you to integrate packages seamlessly into your CI/CD pipeline. There are three concepts you need to understand when managing Azure artifacts: feeds, views, and upstream sources.

Feeds are the primary method for delivering packages. Microsoft recommends one feed per project. To achieve this we can utilize the feature of upstream sources, which allows us to combine multiple sources into a single feed. Using this method allows us to control sources in your project in the various levels of access. Here we can see two options we have when adding upstream sources. A public source, and from an existing Azure Artifacts feed from within your Azure DevOps organization.

When adding a public source, the only supported package type is an NPM source as shown here.

When adding a source from within your Azure DevOps organization, you can target an Azure Artifacts feed. This allows you to use different package types, for example, NuGet, Python, and Maven.

You can scope the visibility of your package feed to your organizations, which is multiple projects. This is the default. To project that is, this project or one project, specific people, which is a target audience, or public use.

A benefit of bring all these packages together in one feed is the copies are made of the sources. If you're using sources, and those sources go offline, you'll be able to maintain your own version of this package.

Let's take a look at views, and when and how you should use a view. For example, let's Do you want to share a package feed with an external partner. With the scope, you could use a public scope. However, this would make the package available to the internet. Views are a good way to address this use case. Using views means the data is read only. To gain access to these views, the external partner needs to be part of your Azure AD.

Views provide way to have the same feed used for debug and release packages. By default, there are three views. The @Release view contains all the packages that are considered official releases. The @Prerelease view contains all the packages that have labels in the version numbers, and local, which contains all the releases and prereleases of packages as well as downloaded cached content from upstream sources.

By default, the published packages will all belong to the local view only.

You have the option to promote a version to a view. As we can see here the version 1.0.74.1 is published to the prerelease view.

Upstream sources enable you to manage your product's dependencies in a single place. Using upstream sources makes it easy to use common packages in your solution. It has the added benefit, and gives you protection against outages and corrupted or compromised packages from upstream sources, as a copy of the packages stored locally.

There are many different tools and ways to manage your packages, depending on the type of packages you're working with. We're going to look briefly at some of the methods using NuGet package management. However, these concepts apply generally to all packages.

To publish a package into your feed, if you're using the command line, you often need to use an API key. Here's a brief example of using .NET NuGet push.

dotnet nuget push MyApp.1.0.0.nupkg -k <yourAPIKey> -s https://repo.nuget.org/v3/index.json

These are some other commands or methods to assist with managing your NuGet packages. This is not a complete list, but highlight some of the key functionality. Pack, it creates a NuGet package based on the specific nuspec spec file or project file. List displays a list of packages from a given source. Restore downloads and installs any missing packages from the packages folder. Install downloads and installs a specific package into your project. Delete deletes or unlists a package from a packet source.

This brings us to the end of the first section, looking at what dependency management is, and what Azure Artifacts look like. We're going to jump into a demo and work through creating a package.