14 Nutzung von Tags zur Versionskontrolle

Tags in Git sind unveränderliche Markierungen, die auf einen spezifischen Commit verweisen. Anders als Branches, die sich mit jedem neuen Commit verschieben, sind Tags fest mit einem Commit verknüpft und dienen als eindeutige Referenzpunkte in der Entwicklungshistorie eines Projekts. Tags werden oft genutzt, um wichtige Meilensteine wie Releases oder spezielle Versionen eines Projekts zu kennzeichnen.

14.1 Eigenschaften von Tags

  1. Unveränderlichkeit: Einmal gesetzt, bleibt ein Tag fest mit dem zugehörigen Commit verknüpft und verschiebt sich nicht, wie es bei Branches der Fall ist.

  2. Referenz auf Commits: Tags bieten eine benutzerfreundlichere Möglichkeit, auf spezifische Commits zu verweisen, ohne sich auf kryptische Commit-Hashes verlassen zu müssen.

  3. Eindeutige Markierung: Sie dienen der eindeutigen Kennzeichnung bestimmter Versionen oder Zustände des Codes, die als besonders stabil oder veröffentlicht gelten.

14.1.1 Arten von Tags

Die Erstellung eines annotierten Tags erfolgt beispielsweise mit:

git tag -a v1.0.0 -m "Release Version 1.0.0"

14.2 Tags in Continuous Integration und Delivery

In CI/CD-Workflows spielen Tags eine entscheidende Rolle bei der Automatisierung von Releases und Deployments. Tags werden verwendet, um spezifische Versionen des Codes zu kennzeichnen, die bereit sind, in die Produktion zu gehen oder als offizielle Releases veröffentlicht zu werden.

In GitLab CI wird das Setzen eines Tags häufig als Auslöser für spezifische Pipelines verwendet, beispielsweise für den Start eines Produktions-Deployments oder den Export von Build-Artefakten.

14.2.1 Beispiel: Tag-basierte Pipeline in GitLab

stages:
  - build
  - deploy

deploy-production:
  stage: deploy
  script:
    - echo "Deploying to production"
  only:
    - tags

In diesem Beispiel wird die deploy-production-Stage nur dann ausgeführt, wenn ein Tag gesetzt wird. Diese Automatisierung stellt sicher, dass der Produktions-Deployprozess nur durch Tags gestartet wird und nicht bei jedem Commit im Main-Branch.

14.3 Release-Management und der Begriff “Release”

Ein Release ist eine offiziell veröffentlichte Version eines Projekts, die eine stabile und getestete Version des Codes darstellt. Releases sind oft mit Tags in Git markiert, die die exakte Commit-Historie dieser Version festhalten.

Ein Tag, der einen Release darstellt, dient nicht nur der Versionierung, sondern ist oft auch der Auslöser für automatisierte CI/CD-Prozesse, wie das Deployment in Produktionsumgebungen oder das Erstellen von Release-Artefakten (z. B. Binärdateien oder Installationspakete).

14.4 Semantic Versioning (SemVer)

Semantic Versioning, kurz SemVer, ist ein weit verbreiteter Standard zur Versionierung von Software, der es Entwicklern und Nutzern ermöglicht, die Kompatibilität von Versionen und Änderungen nachzuvollziehen. Das SemVer-Format besteht aus drei numerischen Komponenten:

MAJOR.MINOR.PATCH

14.4.1 Beispiel für SemVer

Ein Projekt könnte folgende Versionen haben:

SemVer hilft nicht nur Entwicklern, sondern auch CI/CD-Pipelines, verschiedene Versionsarten korrekt zu interpretieren und automatische Entscheidungen zu treffen. Ein häufiges Szenario ist, dass CI/CD-Pipelines auf das Setzen eines Major-Tags reagieren, um umfangreichere Tests oder Deployments durchzuführen, während Patch-Tags lediglich minimale Builds und Tests erfordern.

14.4.2 Nutzung von SemVer in CI/CD

In einem typischen Workflow könnte ein Patch-Update lediglich eine bestehende Version korrigieren und dabei das Deployment in einer Testumgebung triggern. Hingegen könnte ein Major-Update umfangreichere Tests auslösen und einen vollständigen Release-Prozess durchlaufen.

Ein Beispiel für eine semantische Versionierung in einem CI/CD-Workflow sieht folgendermaßen aus: