Git Workflow

Diese Seite beschreibt die Git-Workflows, die bei ITeas für die Softwareentwicklung verwendet werden. Je nach Projektgröße und -anforderungen kommen zwei unterschiedliche Branching-Strategien zum Einsatz.

Unser Workflow zielt grundsätzlich auf GitOps ab, wo es sinnvoll möglich ist: Git ist die Single Source of Truth für Code, Konfiguration und Versionierung. Änderungen werden über Merge Requests nachvollziehbar eingebracht, und Deployments sowie Releases werden automatisch durch Git-Events (Merges, Tags) über CI/CD-Pipelines ausgelöst.

Siehe auch: Git & SSH Setup für die Einrichtung von Git, SSH-Keys und Commit-Signierung.

Workflow 1: Einfacher Master-Workflow

Für kleinere Projekte und Libraries/Packages wird ein einfacher Workflow mit dem master-Branch als Hauptbranch verwendet.

Beispielprojekt: yii2-loki-log-target

Branching-Strategie

feature/neues-feature ──┐
                         ├──▶ master (= dev + release) ──▶ Tag v1.0.0
chore/cleanup ───────────┘

• Der master-Branch ist gleichzeitig der Development- und Release-Branch
• Entwickelt wird in Feature- oder Chore-Branches, die per Merge Request in master gemergt werden
• Wenn eine Version freigegeben wird, wird ein Tag auf master gesetzt

Branch-Namenskonventionen

Prefix	Verwendung
feature/	Neue Funktionalität
chore/	Wartung, Refactoring, Dokumentation
fix/	Bugfixes

Release-Prozess

1. Feature-/Chore-Branch erstellen und entwickeln
2. Merge Request in master erstellen
3. Nach Review und Merge: Tag setzen (z.B. v1.2.0)
4. Der Tag löst die Release-/Deploy-Pipeline aus

CI/CD: Automatische Paket-Veröffentlichung

Bei Packages und Images wird durch den Tag automatisch eine neue Version in der Registry erstellt.

Beispiel für eine Composer-Package-Pipeline:

# Publishes a tag/branch to Composer Packages of the current project
publish:
  image: curlimages/curl:latest
  stage: build
  only:
    - tags
  tags:
    - 'build-docker01'
  variables:
    URL: "$CI_SERVER_PROTOCOL://$CI_SERVER_HOST:$CI_SERVER_PORT/api/v4/projects/$CI_PROJECT_ID/packages/composer?job_token=$CI_JOB_TOKEN"
  script:
    - version=$([[ -z "$CI_COMMIT_TAG" ]] && echo "branch=$CI_COMMIT_REF_NAME" || echo "tag=$CI_COMMIT_TAG")
    - insecure=$([ "$CI_SERVER_PROTOCOL" = "http" ] && echo "--insecure" || echo "")
    - response=$(curl -s -w "\n%{http_code}" $insecure --data $version $URL)
    - code=$(echo "$response" | tail -n 1)
    - body=$(echo "$response" | head -n 1)
    # Output state information
    - if [ $code -eq 201 ]; then
      echo "Package created - Code $code - $body";
      else
      echo "Could not create package - Code $code - $body";
      exit 1;
      fi

Workflow 2: Development-/Master-Workflow

Für größere Projekte wird ein erweiterter Workflow mit separatem development-Branch verwendet. Dies erlaubt eine bessere Trennung von Entwicklung und Deployment.

Beispielprojekt: iScan

Branching-Strategie

feature/neues-feature ──┐
                         ├──▶ development (stabiler Dev-Status) ──▶ master (Release) ──▶ Tag v1.0.0
fix/bugfix ──────────────┘                                              ▲
                                                                        │
hotfix/critical-fix ────────────────────────────────────────────────────┘

• Der development-Branch enthält den aktuellen stabilen Entwicklungsstand
• Entwickelt wird in Feature-Branches, die per Merge Request in development gemergt werden
• Der master-Branch ist der Release-Branch, auf dem die Tags gesetzt werden
• Bug- und Hotfixes für Production können direkt in master gemergt werden, ohne den gesamten development-Stand mitzunehmen

Vorteile gegenüber Workflow 1

• Klare Trennung von Entwicklung und Production
• Hotfixes können unabhängig vom aktuellen Entwicklungsstand deployed werden
• Der master-Branch enthält immer nur getesteten, release-fähigen Code
• Merge Requests können als Review Apps (MR Staging) auf einem Staging-Server deployed werden

Release-Prozess

1. Feature-Branches werden in development gemergt
2. Wenn development stabil ist: Merge Request von development nach master
3. Nach dem Merge in master: Tag setzen
4. Der Tag löst die Release-/Deploy-Pipeline aus

Hotfix-Prozess

1. Hotfix-Branch von master erstellen
2. Fix implementieren und testen
3. Merge Request in master erstellen
4. Nach Merge: neuen Tag setzen
5. Fix auch in development zurückmergen

Versionierung

Die Versionierung sollte bei allen Projekten erfolgen, die Pakete oder andere Artefakte erzeugen. Die Version wird dabei automatisch über den Git-Tag bestimmt - manuelles Version-Bumping in Projektdateien ist zu vermeiden, wenn möglich.

Dies gilt insbesondere für:

• Composer-Packages
• NPM-Packages
• NuGet-Packages
• .NET-Programme

Versionierung bei Applikationen

Das Deployment der Applikationen erfolgt via GitOps über Gitlab-Pipelines. Die aktuelle Versionsbezeichnung wird automatisch via der composer.json-Datei durch die Gitlab-Pipeline an die Application übergeben. Die Versionsbezeichnung ist entweder der aktuelle Tag oder der Name des letztgepushten Branches (nur in Dev-Umgebungen). Die aktuell ausgeführte Version wird im Footer der Applikation angezeigt.

Versionierung bei Composer-Packages

Bei Composer-Packages wird die Version über den Git-Tag bestimmt. Der Tag-Name entspricht der Versionsnummer (z.B. v1.2.0) und wird durch die CI/CD-Pipeline automatisch als Package in der GitLab Composer Registry veröffentlicht (siehe CI/CD-Beispiel oben).