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
Dependency management strategy. As the code base of your project grows, it can become complicated to track and manage changes for different aspects of your solution. The problem grows as more people and teams become involved. A standardized versioning system can be extremely useful to address this problem.
Versioning is a critical part of software development to help you track changes in your code over time. It allows us to know what features and what code is being deployed in various places, to know what we expect it to do, track bugs and issues, and ensure the right groups of people get the right versions of code.
Semantic versioning, also known as SemVer, is a versioning system that has become common practice to use over the last several years. A package version looks like this, 4.7.6. The first number is the major version.
The major denotes a significant change to the package. This could include a complete redesign, breaking changes and additional testing to ensure backwards compatibility still works.
The minor version. These changes are often used to increment towards a major change. These often include new features or functionality.
And the final number, patches. This is used to indicate that there are bug fixes.
Sometimes a qualifier is used such as alpha, beta, or RC1, RC2, for release candidate one and release candidate two. These help denote the quality of the package. It's used for those consuming the package in the pre-release cycles to know that they may experience unexpected results.
As you develop your package and create features, you can create new versions. Each version represents a fixed version of the code at a point in time. Whenever a package is published it should not be allowed to change any more. If this package did change you could risk breaking other solutions that rely on this specific version. The term for this is called an immutable package.
Depending on your pipeline and what type of package you are developing, there are methods to automatically increment version numbers. In the screen shot, we can see the build number format is using a function, rev:.r. This will automatically increase the revision each time the pipeline is executed.
Another method for addressing the complexities of managing dependencies is componentization. Componentization is the act of separating and structuring your product or library into a set of components, discrete parts of your code that provide a set of features. There are two methods for this, source componentization and package componentization.
Source componentization. Components are broken up into different projects within the same source code. This can mean a component can have references to another complied component within the same source code. This is called binary composition. This can work as long as the source code is not shared outside of the project, however, it can increase build times and comes with added complexity. Once these separate components are leveraged by different teams or code is branched, it becomes difficult to track changes and ensure the consistency. This method becomes very cumbersome and difficult to manage.
Package componentization refers to using packages for distribution of software. Packaging code with structured methods means you can add metadata, like versioning, to your package to allow for reliable distribution needed for dependency management. When a component package is checked into a package source, other solutions can leverage the package and be developed independently of each other.
It is important to remember there is no one right answer. When looking at your code base and considering how to componentize and turn your code into packages there are different methods you can use to guide how and where to create packages.
You can look for duplicate code within your code base, group parts of your code with similar functionality, perhaps code with similar release cycles, leveraging existing organizational group structures, or stable code with very few changes to itself.
There is tooling available to help you find dependencies and duplicate code that may be good candidates for creating packages. Visual Studio Enterprise has a code clone analysis tool to search for duplicate code. There are other tools like Sonarqube, ReSharper, and Copy/Paste Detector, depending on your needs. Many of these tools have other features to help you improve the general quality and detect dependencies.
This brings us to the end of this section. Now we're going to look at a demo where we'll consume the package that we created previously.
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.