How to automatically incorporate semantic version information into NuGet libraries during building, packaging, and publishing of .Net libraries to private NuGet feeds.
In my last code sharing post I covered how create and consume private NuGet feeds in Azure DevOps via a script, but only locally, and manually. This isn't close to good enough assuming you've bought into the DevOps dream of consistently and reliably deploying code into production up to hundreds of times per day (ala The Phoenix Project, which I simply can't recommend enough).
To get a continuous integration server automatically compiling, packaging, and deploying a library to NuGet, you'll first need to solve versioning. Ideally the versioning information will contain semantic information such as whether an API was broken. That type of information can only be provided by a human, and yet a human shouldn't have to manually specify the version number for each build.
In this article I'll show how to incorporate semantic versioning information into libraries and yet automate it. I'll start with incorporating versioning information into the Cake scripts from the last post and then get into version automation with GitVersion.
Hard Coded Versioning
origin/master [should] be the main branch where the source code of HEAD always reflects a production-ready state … When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.
- If you tag a branch (typically on master for an official release) like v1.0.3, then GitVersion will return "1.0.3"
- If you're on a feature branch off of develop then GitVersion will increment the minor number and append a suffix of the branch name and a 1 up counter
- As you merge PR's back into develop GitVersion updates the minor version from what it found in master and appends "alpha" and a 1 up counter.
- When you're ready to deploy and start a release branch, GitVersion parses the version number out of the branch name and appends "beta" and a 1 up counter
- When you merge the release branch back into master GitVersion recognizes the version from the merged release branch even before you're tagged