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.
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
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.
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.