The course is part of these learning paths
This course explains how to implement dependency management with Azure DevOps. It explores the strategies, tools, and methods used for creating and managing dependencies. First, you will learn what dependency management is and which packages are available for Azure DevOps. A practical demonstration then shows how to build a package. The course moves on to explore the strategies for dependency management, including versioning and componentization, and provides a demo that guides you through how to consume a package. Finally, you will learn about security and compliance, and watch a practical demonstration of WhiteSource Bolt.
By the end of this course, you should have a good understanding of how packages are managed within Azure DevOps and the implications of package management methodologies.
If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Explore what dependencies are
- Understand the various package types in Azure DevOps
- Manage packages in Azure DevOps through Artifacts
- Explore building software and creating dependencies
- Understand the strategies and methods for creating and managing dependencies
- Explore package security and compliance scanning options
- Individuals who want to learn more about Azure DevOps
- Individuals aiming to become Azure DevOps engineers
- Students preparing for Microsoft’s AZ-400 exam
To get the most from this course, you should have:
- Experience with version control and pushing changes into an Azure repo
- An Azure DevOps account
- Visual Studio installed if you want to follow along during the demos
- An understanding of Git and how to push code
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.
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 184.108.40.206 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.
Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.