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.
Join the DZone community and get the full member experience.
Join For Freeas 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.
Published at DZone with permission of Ricci Gian Maria, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments