Over a million developers have joined DZone.

Update GitVersion for Large Repositories

DZone's Guide to

Update GitVersion for Large Repositories

In this post we take a look at how to update GitVersion in large repositories, a common task that will save you a lot of headaches in the future. Read on for details.

· Integration Zone ·
Free Resource

SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.

As you know, I’m a fanatic user of GitVersion in builds, and I’ve written a simple task to use it in a TFS Build automatically. This is the typical task that you write and forget because it just works and you usually not have the need to upgrade it, but there is a build where I start to see really high execution timing for the task; as an example, GitVersion needs two minutes to run.


Figure 1: GitVersion task run time it is too high, 2 minutes.

This behavior is perfectly reproducible on my local machine. That repository is quite big, it has lots of tags and feature branches, and it seems that GitFlow needs a lot of time to determine semantic versioning.

Looking at the GitHub page of the project, I read some issues regarding performance problem; the good part is that all performance problems seem to disappear with the newer version, so it is time to upgrade the task.

Thanks to the new build system, updating a task in VSTS / TFS is really simple- I just deleted the old GitVersion executable and libraries from the folder where the task was defined, I copied over the new Gitversion.exe and libraries, and with a tfx build tasks upload command, I could immediately push the new version on my account.

Since I changed GitVersion from version 2 to version 3, it is a good practice to update the Major number of the task, to avoid all build to automatically use the new GitVersion executables, because it could break something. What I want is all build to show me that we have a new version of the task to use, so you can try and stick using the old version if Gitversion 3.6 gives you problems.

Whenever you do Major change on a TFS / VSTS Build task it is a good practice to upgrade major number to avoid all builds to automatically use the new version of the task.

Thanks to versioning, you can decide if you want to try out the new version of the task for each distinct build.


Figure 2: Thanks to versioning, the owner of the build can choose if the build should be upgraded to use the new version of GitVersion task.

After upgrading the build, just queue a new build and verify if the task runs fine, and especially if the execution time is reduced.


Figure 3: New GitVersion executable has a real boost in performance.

With few minutes of work, I upgraded my task and I’m able to use the new version of GitVersion.exe in all the builds, reducing the execution time significantly. Compare this with the old XAML build engine and you understand why you should migrate all of your XAML build to the new build system as soon as possible.

Download A Buyer's Guide to Application and Data Integration, your one-stop-shop for research, checklists, and explanations for an application and data integration solution.

execution ,simple ,tfs ,git ,version ,integration

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}