# Git-Workflow und Deployment

Ein Push auf main startet die Pipeline, die die Version aus den Commit-Nachrichten berechnet, Dev automatisch ausrollt und Produktion per manuellem Job freigibt; ein früherer Stand lässt sich auf demselben Weg zurückholen.

> Source: https://www.application-platform.com/de/docs/git-workflow/

## Branches und Merge Requests

Der Auslöser für ein Deployment ist `main`; ob du direkt pushst oder Feature-Branches über Merge Requests zusammenführst, entscheidet dein Team. Feature-Branches durchlaufen die Pipeline mit dynamischen Build-Versionen, aber ohne Versions-Commit und Deployment.

```bash
git checkout main
git pull
git add .
git commit -m "feat: Warenkorb speichern"
git push
```

Ziehe vor dem Push den aktuellen Stand von `main`, weil die Pipeline dort selbst Versions-Commits erzeugt. Der Pre-Commit-Hook `ap git pre-commit check` aus Setup-App und `ap platform projects clone` blockiert Commits an `.gitlab-ci.yml` und `env/*.generated.env`; `ap git auto-commit` erledigt Staging, Commit und Push in einem Schritt.

## Die Pipeline auf main

```mermaid
flowchart LR
  test["test"] --> version["update-version"]
  version --> build["build"]
  build -->|"automatisch"| publish["publish: Dev"]
  publish -->|"manueller Job"| release["release: Prod"]
```

`test` führt Tests und Prüfungen aus, `update-version` berechnet nach Conventional Commits die nächste Version (`feat:` erhöht die Minor-, `fix:` die Patch-Version), und `build` erzeugt das Docker-Image oder den App-Build mit dieser Version. `publish` trägt den Stand in `configurations/dev/versions.yaml` von `gitops-configuration` ein, woraufhin der Dev-Server die Version zieht; bei Apps bedeutet `publish` TestFlight und den internen Track im Play Store. `release` ist der manuelle Job für Produktion beziehungsweise die Store-Einreichung. Jeder Job hat in GitLab unter **CI/CD → Pipelines** ein Log, die erste Anlaufstelle bei einer roten Pipeline.

## Produktion freigeben

Produktion bekommt genau das Build, das schon auf Dev läuft. Öffne in GitLab unter **CI/CD → Pipelines** die Pipeline des `main`-Stands, den du ausrollen willst, und starte den Produktions-Job über den Play-Button; die Pipeline schreibt die Version in `configurations/prod/versions.yaml`, und der Prod-Server zieht sie. Zwischen Freigabe und Live-Schaltung gibt es keinen weiteren Bestätigungsschritt, prüfe die Änderung also vorher auf Dev.

Eigene Umgebungsvariablen für Dev oder Prod pflegst du in `gitops-configuration/configurations/<env>/custom.yaml`; ein Commit auf `main` in diesem Repository rollt die Änderung aus, ohne ein neues Image zu bauen. Die Dateien beschreibt [Umgebungsvariablen]({{< relref "environment-setup" >}}).

## Zurück zu einem früheren Stand

Weil jede Pipeline ihr Build behält, ist ein Rollback derselbe Klick wie eine Freigabe: Öffne die Pipeline des letzten funktionierenden `main`-Stands und starte ihren Produktions-Job erneut. Welche Version wo läuft, steht in `versions.yaml` der Umgebung; Sentry verknüpft Fehler mit derselben Release-Version, sobald unter **Anbindungen** ein Sentry-Konto verbunden ist. Wie du nach einem Release Fehler und Server im Blick behältst, steht unter [Betrieb]({{< relref "operations" >}}).