Just Another Day

The Requirement: Automatic version management

When using CD/CI there are a couple of things I don't really want to have to think about, especially if commits and changes are quite frequent and minor.

The first, is updating my app's version number. I guess this is more important if you are creating nuget packages as part of your CD pipeline. You need to provide a new version number for your package with each and every commit.

The second, in my case, is telling BugSnag that my AppVersion has changed. This is useful for associating bugs with specific versions, plus a whole host of other useful features. There are a number of ways you can do this, but BugSnag suggest you do this by adding a specific AppVersion setting to you BugSnag config in your appsettings.json file (asp.net core).

The Solution

Luckily I've written a couple of useful Azure DevOps build tasks which can handle these requirements perfectly.

Generating a new version number.

I start by adding AutoAppVersion to my primary agent job. (I also added SetJsonProperty too, as I'll be using that later). It's important to add these guys early in your pipeline so version values can be updated, then used by any proceeding tasks such as pack and push.

Agent Job

My first port of call is AutoAppVersion or AAV for short. AAV is responsible for generating and incrementing your app's current version number. For more information, you can check out the wiki on getting started. One important feature of AAV is it's ability to store a newly generated version number in an environment variable of your choice.

I provide AAV with an environment variable name. This doesn't have to be predefined in your build definition's Variables tab.

When I run the pipeline, you can see from AAV's console output, towards the bottom, my environment variable has been set with the updated app version 1.0.1

This is great. At this point, my project file has a newly incremented version, 1.0.1 plus, I also have access to that value by means of my environment variable MyNewVersionNumber.

Applying my new version number.

The next thing I want to do, is update my settings for BugSnag. I do this by updating my appsettings.json file. At the moment, my appsettings file is holding a static value for BugSnag.AppVersion.

  "BugSnag": {
    "ApiKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "AppVersion": "0.0.1",
    "AutoCaptureSessions": true

Normally I would need to remember to increment this value each time I committed my code, but I really want to automate this process too. This is where SetJsonProperty comes in.

Setting up SetJsonProperty is super-simple. It needs to know which json file you want to update, which property you want to target, and the value you want to set. So, I want to target my appsettings.json file, I want to update the BugSnag AppVersion property, and I want to use the value from the environment variable MyNewVersionNumber set by AAV in the previous task. My SetJsonProperty's fields end up looking something like this.

Now, when we inspect our build's console output for SetJsonProperty, we can see the value for BugSnag.AppVersion has been replaced with the new version number 1.0.1 which AAV generated in the previous task.


We can then check our artifacts to make sure the appsettings.json file has actually been updated as expected.

lo and behold, our setting has been updated.

  "BugSnag": {
    "ApiKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "AppVersion": "1.0.1",
    "AutoCaptureSessions": true

We could obviously check BugSnag the next time an error comes through, to ensure the error has been correctly associated with our new AppVersion. That could take a while though, because let's face it, who has bugs?

And that's it, until I want to make a Major or Minor version change, I don't need to worry, or think about updating my version numbers on each and every commit and build.


On GitHub

On Visual Studio Marketplace