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.