Copy aus dem letzten Job
- Die Pipeline existiert in Slack und in einem Gist.
CI/CD, die mit dem Repo entsteht – und im Repo bleibt
Eine brauchbare Pipeline kostet Tage, die niemand aufschreibt. Beim nächsten Projekt suchst du die Datei. Wir legen GitLab-CI mit dem Assistenten an. Danach gehört sie dir, du darfst sie ändern.
- Test, Build, Publish, Release – vorbereitet, nicht versteckt
- Die Datei liegt im Git. Spezialfälle editierst du, statt ein Ticket zu öffnen.
Folklore oder Datei im Repo
Mit dem Projekt da
- GitLab-CI kommt mit dem Template. Danach ist es euer YAML.
Pipeline für Kunden-App
test
build
publish
release
CI/CD automatisieren heißt nicht, ein Dashboard mit bunten Häkchen zu kaufen. Es heißt, Test, Build und Release als Datei im Repo zu haben, bevor das Team darüber streitet, wessen Laptop gerade grün ist.
Pipeline selbst aufsetzen oder mit der Plattform starten
Die Gegenüberstellung zeigt, welche Arbeit eine Continuous-Delivery-Kette verursacht und was die Application Platform davon mitbringt.
| Aufgabe |
Mit der Application Platform
|
Manuell aufgesetzt
|
|---|---|---|
| Erste lauffähige Pipeline | Vollständig abgedeckt: Entsteht mit dem Projekt, inklusive Test, Build, Publish und Release | Nicht angeboten: Konfiguration von Grund auf schreiben und iterativ debuggen |
| Runner und Build-Umgebung | Vollständig abgedeckt: Build-Infrastruktur ist vorhanden, inklusive macOS-Geräten für iOS | Nicht angeboten: Runner bereitstellen, aktualisieren und überwachen |
| Zugangsdaten in der Pipeline | Vollständig abgedeckt: Projekt-Credentials und CI-Variablen werden zentral verwaltet | Teilweise abgedeckt: Secrets pro Repository pflegen, Rotation gerät in Vergessenheit |
| Deployment auf Server | Vollständig abgedeckt: Server sind angebunden, Docker, Reverse-Proxy, SSL und Backups eingerichtet | Nicht angeboten: Deploy-Skripte, SSH-Schlüssel und Serverpflege selbst verantworten |
| Versionierung | Vollständig abgedeckt: Versionen und Build-Nummern entstehen in der Pipeline | Teilweise abgedeckt: Manuell setzen oder ein eigenes Skript dafür schreiben |
| Packages veröffentlichen | Vollständig abgedeckt: Docker-Images, Terraform, Go, Python, NPM und Dart mit Freigabe pro Ebene | Teilweise abgedeckt: Registry pro Format einrichten und Berechtigungen getrennt pflegen |
| Mobile Releases in Stores | Vollständig abgedeckt: Signing, Store-Metadaten und Upload über Fastlane sind Teil der Kette | Nicht angeboten: Eigener Prozess neben der Pipeline, meist mit manuellen Schritten |
| Nachvollziehbarkeit der Umgebungen | Vollständig abgedeckt: Umgebungen und Deployments liegen als Konfiguration im Git-Verlauf | Nicht angeboten: Serverzustand entsteht historisch, Änderungen sind schwer belegbar |
| Überblick über Deployments | Vollständig abgedeckt: Release-Karten pro Repository zeigen den ausgerollten Stand | Teilweise abgedeckt: Pipeline-Logs durchsuchen oder im Team nachfragen |
| Fehler nach Release zuordnen | Vollständig abgedeckt: Sentry wird eingerichtet, Fehler sind gefiltert nach Repository sichtbar | Teilweise abgedeckt: Error-Tracking separat anbinden und mit Releases verknüpfen |
Grün bedeutet vollständig abgedeckt, gelb teilweise, grau nicht vorgesehen. Selbst gebaute Pipelines können dasselbe leisten, der Unterschied liegt im Aufwand pro Projekt.
Stand: 9. September 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.
Keine Blackbox
- Du darfst ändern Die Datei liegt im Repo. Wer Spezialfälle braucht, editiert sie – das ist Absicht, kein Mangel.
Kostenmodell
Runner und Pipeline gehören zum Projekt. Es gibt keinen zweiten CI-Anbieter nur für Builds.
configurations/prod/versions.yaml
application:
backend_configuration:
image_tag: 0.26.8-98
frontend_configurations:
customer-frontend:
image_tag: 0.15.6-80
admin-app:
image_tag: 0.12.1-42-
Kunden-App — -
Admin-App — -
Backend —
So sieht der Weg vom Commit zum Deployment aus
Vier Schritte, die sich in jedem Projekt gleich anfühlen.
-
Projekt anlegen
Wähle deinen Stack. Repository, Projektstruktur und die passende CI/CD-Pipeline entstehen zusammen.
-
Server verbinden
Binde einen eigenen Server per SSH an oder nutze einen Managed Server. Docker, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet.
-
Commit und Merge
Die Pipeline testet, baut und veröffentlicht nach denselben Regeln, unabhängig davon, wer den Merge auslöst.
-
Rollout auslösen
Das Deployment stößt du in der Plattform an. Der ausgerollte Stand erscheint als Release-Karte am Repository.
Häufige Fragen
Muss ich die Pipeline selbst schreiben?
Nein. Beim Anlegen eines Projekts entsteht eine GitLab-CI-Pipeline für Test, Build, Publish und Release, die zum gewählten Stack passt. Du kannst sie unverändert nutzen oder anpassen, weil die Konfiguration lesbar im Repository liegt.
Welche Technologien werden abgedeckt?
Die Templates umfassen Next.js, NestJS, Laravel, FastAPI, Flutter, Expo, native iOS- und Android-Projekte sowie Astro und Hugo. Alle laufen über denselben Mechanismus, bei mobilen Releases hängt die Store-Veröffentlichung über Fastlane daran.
Wie werden Zugangsdaten in der Pipeline behandelt?
Projekt-Credentials und Umgebungsvariablen liegen zentral im Projekt und stehen der Pipeline zur Verfügung, ohne in Dateien im Repository zu landen. Deploy Keys und CI-Variablen entstehen mit dem Repository, den Zugriff regeln Rollen.
Wie sehe ich, was ausgerollt ist?
Deployments erscheinen als Release-Karten pro Repository, der ausgerollte Stand ist direkt ablesbar. Zusätzlich liegen Umgebungen als Konfiguration im Git-Verlauf. Fehler ordnet die Sentry-Anbindung dem Repository und Release zu.
Kann ich Pakete aus der Pipeline veröffentlichen?
Ja, für Docker-Images, Terraform Provider und Module sowie Pakete für Go, Python, NPM und Dart. Die Sichtbarkeit legst du je Artefakt fest: Projekt, Organisation, alle Plattformnutzer oder öffentlich.
Sieh dir die Pipeline im eigenen Projekt an
Registriere dich kostenlos, lege ein Projekt an und verfolge den ersten Durchlauf von Test bis Deployment.