CODEWITHSUNDEEP
teamcityversioninggitversion
Mohamed Hussain
Mohamed Hussain

Reputation: 144

How to integrate Gitversion

I would like to integrate an automated versioning system in my ASP.NET project. For each release, it should have a version number based on the previous release. I am planning to integrate Gitversion https://gitversion.net/. Does anyone use it in your projects? For the CI/CD pipeline we have teamcity and octopus deploy.

What is the best practice for automated software release versions?

Thanks in advance

Upvotes: 1

Views: 968

Answers (2)

Teneko
Teneko

Reputation: 1491

You told you want to integrate an automated versioning system? I would like to throw my hat in the ring.

I am author of Vernuntii, a simple semantic versioning library with git integration.

The answer of @Asbjørn told you already about the best practices for example choosing a workflow that is suited for your project.

The main part a versioning tool like GitVesion or Vernuntii is to generate a suitable NEXT VERSION based on (non-)existing git tags.

So at the end of the day it is a matter of taste what kind of complexity you want HOW the NEXT VERSION is calculated.

So when you want cross-branch versioning, then you are good to go with GitVersion, but if you don't need that kind of complexity then you can try a single-branch versioning like it is implemented in Vernuntii.

For more informations take a look at the README.md of Vernuntii.

Here, for giving you my impression of versioning tools and their complexity, let me give you a list (sorted from least complex to most complex):

  • MinVer
  • Verlite
  • Vernuntii
  • Nerdbank.GitVersioning
  • GitVersion

A fun fact beside: all libraries from top to Vernuntii also allows to calculate the next version from detached HEAD.

Upvotes: 0

Asbjørn Ulsberg
Asbjørn Ulsberg

Reputation: 8820

As one of the maintainers of GitVersion, I'm obviously biased, but since you're asking how to use GitVersion to implement a "best practice for automated software release", I'm going to unashamedly give you a textual description of a talk I've done on how I prefer to version and release software with GitVersion, TeamCity and Octopus Deploy.

Developer Workflow

The first thing you should figure out is what kind of developer workflow you want for your software. GitVersion supports Git Flow and many simplified variants of it, and GitHub Flow (as well as many other trunk based development flows). Which workflow you should choose depends on what type of software you are developing, your team and most importantly; your personal preference.

Once you have chosen your workflow, you can configure which mode GitVersion should operate under.

Version Source

GitVersion works by calculating a version number from your Git repository. This means that you should not commit a version number to Git in any shape or form. Not within a package.json, pom.xml, .csproj, or any other build- or project-related file that often mandates the existence of a version number.

Versioning

Instead, you should allow GitVersion to produce a version number based on the Git history, using the currently checked out commit as its starting point, and searching through the parents and their tags to calculate an appropriate version number for the current commit. This version number can then be used in any way you want in your build pipeline. You can, for instance, write GitVersion's FullSemVer variable to package.json by executing the following command:

npm version $GitVersion_FullSemVer

If you are developing on the .NET platform, it's also possible to use GitVersion to patch your AssemblyInfo.cs files so the calculated version number is compiled into your assemblies. With InformationalVersion containing the SHA of the Git commit being built and versioned, you'll be able to identify the exact origin of a compiled assembly.

Build

Once you have your workflow in order and GitVersion has a good source of information to use for its versioning, you can go ahead and create a build pipeline for your software. A typical build pipeline will look something like this:

  1. git clone. (Ensure that the clone is complete and not shallow or a detached HEAD. See requirements for more information.)
  2. GitVersion. Execute GitVersion by whichever means make most sense to your environment.
  3. Patch. Patch the version number created by GitVersion in step 2 into every file in your repository that makes sense, such as AssemblyInfo.cs, package.json, etc.
  4. Build. Perform the build of your software.
  5. Test. Run tests that ensure the quality of the software.
  6. Package. Create a package of your software, using the version number created by GitVersion in step 2.
  7. Release. Release the package using the package management software of your choice, such as Octopus Deploy, npm, nuget, composer, or similar.
  8. Test. Perform automatic tests of the released software, if possible. If successful, it's possible to automatically promote the released software to other environments, if applicable.

Through GitVersion's built-in support for build servers, the calculated version number will also be promoted to the build server to version the build itself. This will be done automatically on TeamCity, for instance. In TeamCity, I recommend that you run GitVersion as its own build configuration exposing the required variables which can then be used in dependent build configurations later on.

Release

Once you have a built artifact containing the version number generated by GitVersion, you can use the same version number to create a package, create a release and deploy the release in Octopus Deploy.

Upvotes: 1

Related Questions