HowTo - Customize versioning in Azure pipelines
Azure Pipelines is a powerful devops platform, but in terms of versioning macros it misses some basic things we got used to while using other similar tools.
By default Azure offers very strange versioning: YYYYMMDD-REVISION:
It’s definitely not what I personally would like to use. In ETViewer, for example, I use a version like that: MAJOR.MINOR.YEAR_MONTH.BUILD_NUMBER. For example, 1.2.2012.10, which means version 1.2, built in December 2020, build number 10. An important thing is that I want a build number to be increased on each build and never reset non-regarding to other version components. In the same way as it is done in Bamboo or Jenkins.
Let’s customize project versioning in Azure pipeline configuration YML file (by default, azure-pipelines.yml in root folder of your repository)
Step 1: Setup version structure
Using Azure documentation you can easily extend your YML config with the following:
variables:
major: 1
minor: 2
name: $(major).$(minor).$(date: YYMM).$(rev:r)
Now builds will look like that:
You have 2 variables for major and minor version, then a date in format YYMM (2 digits for year, 2 digits for month) and then a revision, which is incremented with each build. It seems, that you have found what you were looking for. But no. There is a problem with revision - it is reset with any change in version string:
As you can see 2 consequent builds have non-consequent build numbers. Let’s try to fix it.
Step 2: Looking for the alternative
Let’s go back to Azure documentation. What else can be used instead of revision number? There is another one number there - BuildId
Trying to use it in pipeline configuration:
variables:
major: 0
minor: 1
name: $(major).$(minor).$(date: YYMM).$(BuildId)
Starting new build…
BuildId is working differently from Revision, it is never reset. But there is another one drawback - BuildId is unique across all the pipelines in the organization. So, each build of each project affects this counter. And again 2 consequent builds will have non-consequent build numbers.
Finally, it looks like there is no ready solution for build numbering in the way we need it. Let’s make it by ourselves.
Step 3: Implement a correct build number
To implement build number we will use a nice Azure feature - counters. You can define counter in you YML file and Azure will increment it for you on each run:
variables:
major: 0
minor: 1
revision: $[counter('revision', 1)]
name: $(major).$(minor).$(date: YYMM).$(revision)
I named a counter “revision” and put 1 as a starting number. Let’s test it:
As we can see, new build number is incremented with each build and is not reset when some version components are changed. That’s exactly what we need.
Image credits:
