Semantic Versioning is a versioning scheme for using meaningful version numbers to avoid “dependency hell”. Semantic Versioning works by structuring each version identifier into three parts:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards compatible manner
- PATCH version when you make backwards compatible bug fixes
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. More information about the standard and implementation is on official SemVer.org.
There are a tons of tools implementing SemVer on different platforms and using various programming language. You may even create your own implementation.
Project setup in Azure DevOps
GitVersion is open-source tool which implement semantic versioning approach in variety of platforms like Jenkins, GitHub or Azure DevOps CI/CD:
| Continuous Integration | GitVersion can be used in a Continuous Server pipeline to generate a version number that both labels the build itself and makes the different version variables available to the rest of the build pipeline. |
| Command Line | The Command Line gives most flexibility by allowing the execution of GitVersion to be customized |
| MSBuild Task | Just install with NuGet and GitVersion will automatically generate assembly version information that is compiled into the resulting artifact. |
| Library | Install with NuGet and use GitVersion as a software library. Although this is an unsupported option and the API may break even between minor or patch releases, it’s a useful option to some. |
Today, I would show you a pretty simple SemVer implementation on Azure DevOps platform using GitVersion tool and yaml pipeline.
If you do not own an account on Azure DevOps, I advise you to do so for free on official page first. The simplest way to start learning is leveraging Azure DevOps Demo Generator and create a dump project choosing from a huge number of solution available:
Here you could find awesome real world Agile/Scrum or Waterfall projects or start your own lab environment playing with Terraform, Docker, Ansible and even ML. This is more that enough to start learning CI/CD.
For purpose of the article, I would create a default project based on Tailwind Traders template. It may take a few minutes to deploy.
Next, go and fork my azure-tools repositorium from here. After it is done, go to project dashboard and open project settings, next ‘Service Connections’ and create new GitHub connection:
Now, we are ready to create a new yaml pipeline. Select GitHub and choose the repository we forked and then ‘Existing Azure Pipelines YAML file’:
GitVersion semantic versioning configuration
Now, lets looks inside the repo. Basically all we need is placed inside SemVer folder:
1. azure-pipelines.yaml – base yaml file we are using to create pipeline. It contains setup parameters and configuration variables.
2. Main template calls calls template.yaml. This is a main logic which install and runs gitversion tool. First use gitversion/setup@0 Azure DevOps task of specific version. Next, gitversion/execute@0 and pass GitVersion.yml configuration file path.
3. GitVersion.yml semver configuration file. What important to know is:
- select git flow based on your project flow (
ContinuousDeployment, Mainstream and ect) - create separate rules for all of branches on repositorium base on match pattern
- exclude specific commits from calculation or all commits (including tags) starting from specific date
- increment MAJOR.MINOR.TAGS manually using commit message
- and much more
After, a some time GitVersion returns calculated version based on commit in specific moment of time. It is important to note, the version does not change until new commit pushed.
GitVersion is straightforward tool to control versioning base on branch naming policy implemented inside your organization. Here are advantage and some disadvantage of using GitVersion based on my experience. The biggest pros is customization and support for variety of CI/CD tools available on the market. The biggest disadvantage is lack of support of different semantic schemas inside one monorepo project:
| Pros | Cons |
| Repeatable version control, based on commit history | DOES NOT support separate versioning schema inside monorepo |
| Clear versioning strategy based on project flow | Needs additional configuration efforts on old control systems |
| Easy to integrate with external projects, implementing feed strategy | |
| Simple Hotfix and Release flow | |
| Compatible with variety of CI/CD tools, CLI, MSBuild, SDK |
Be an ethical, save your privacy!