Wenn zwei Personen die ganze Show schmeißen: Eine einfache Pipeline, die wirklich funktioniert

Du bist einer von zwei Leuten, die ein digitales Produkt bauen. Vielleicht ist es eine einfache Web-App für Lagerverwaltung oder ein API-Service für Geschäftspartner. Dein Team ist klein, das Budget knapp, und das Ziel ist, in Wochen etwas Nutzbares zu haben, nicht in Monaten. An diesem Punkt geht es noch nicht um Pipelines oder CI/CD. Die erste Frage ist: „Wenn Leute diese App nutzen, wie sende ich ihnen eine neue Version, ohne mich jedes Mal auf dem Server einzuloggen?“

In einem kleinen Startup fühlen sich manuelle Prozesse natürlich an. Du kopierst eine Datei per SCP auf den Server, startest den Dienst per SSH neu oder führst eine Datenbankabfrage per Copy-Paste aus. Das funktioniert für die ersten paar Releases. Aber nach drei- oder viermal fallen dir die Risse auf. Du vergisst einen Schritt. Du kopierst die falsche Datei. Du überspringst eine Migration. Und wenn du mehr als eine Umgebung hast – sagen wir Staging zum Testen und Produktion für echte Nutzer – musst du dir die genaue Reihenfolge für jede merken und hoffen, dass nichts durchrutscht.

Hier kommt eine einfache Pipeline ins Spiel. Nicht als großes Projekt, sondern als Werkzeug, das jedes Mal die gleichen Schritte ausführt, wenn sich dein Code ändert. Du beginnst mit einer Konfigurationsdatei in deinem Repository, die drei Schritte definiert: Build, Test und Deploy. Build verwandelt deinen Code in ein ausführbares Artefakt. Test führt automatisierte Prüfungen aus – zum Beispiel, ob eine neue Funktion eine alte kaputt macht. Deploy sendet das Artefakt an den Zielserver.

Wie eine einfache Pipeline aussieht

Für ein kleines Startup muss das Werkzeug nicht kompliziert sein. GitHub Actions, GitLab CI oder die integrierte CI deines Cloud-Anbieters sind alle in Ordnung. Wichtig ist, dass die Pipeline automatisch läuft, wenn du auf einen bestimmten Branch pushst. Zum Beispiel löst ein Push auf main Build, Test und Deploy auf Staging aus. Wenn alles bestanden ist, deployst du mit einem Klick oder einem Befehl in die Produktion.

Hier ist ein konkretes Beispiel. Stell dir vor, du hast eine Node.js-Web-App, die auf einer kleinen VPS gehostet wird. Deine Pipeline-Datei könnte so aussehen:

Hier ist eine visuelle Übersicht der Pipeline:

So sieht die Pipeline-Konfiguration in der Praxis aus:

name: Simple Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build
      - run: |
          rsync -avz --delete dist/ user@staging-server:/var/www/app/
          ssh user@staging-server 'systemctl restart myapp'
flowchart TD A[Push auf main] --> B[Build: Artefakt erstellen] B --> C[Test: automatisierte Prüfungen ausführen] C --> D{Alle Tests bestanden?} D -- Ja --> E[Auf Staging deployen] D -- Nein --> F[Code korrigieren und erneut pushen] F --> A E --> G[Manueller Trigger für Produktion] G --> H[Auf Produktion deployen]
  • Bei Push auf main: Abhängigkeiten installieren, Tests ausführen, App bauen, Build-Artefakt auf den Staging-Server kopieren, Dienst neustarten.
  • Bei manuellem Trigger oder Tag: gleiche Schritte wiederholen, aber auf Produktion deployen.

Das war's. Kein Kubernetes, keine Container-Orchestrierung, keine mehrstufigen Freigabeprozesse. Nur drei Schritte, die jedes Mal konsistent ausgeführt werden.

Volle Verantwortung bedeutet, du trägst den Schmerz

Volle Verantwortung bedeutet, dass du und dein Kollege die komplette Verantwortung für diese Pipeline tragt. Es gibt kein separates DevOps-Team. Keinen langen Genehmigungsprozess. Du schreibst die Pipeline, du führst sie aus, und du reparierst sie, wenn sie kaputtgeht. Das klingt nach viel Druck, ist aber tatsächlich ein Vorteil. Du weißt genau, wie deine Anwendung ausgeliefert wird. Du weißt, was schiefgehen kann. Und du weißt, wie man es repariert, weil du es selbst gebaut hast.

Wenn etwas fehlschlägt – und es wird fehlschlagen – wartest du nicht auf ein anderes Team. Du siehst dir die Logs an, identifizierst den Schritt, der kaputt ist, und reparierst ihn. Diese praktische Erfahrung ist unbezahlbar. Sie lehrt dich die Grundlagen der Auslieferung auf eine Weise, die kein Buch und kein Kurs vermitteln kann.

Einfache Beobachtbarkeit ohne Dashboard-Besessenheit

Du musst wissen, ob deine Pipeline erfolgreich war oder fehlgeschlagen ist, und wenn sie fehlgeschlagen ist, bei welchem Schritt. Die meisten Pipeline-Tools bieten bereits Logs und Benachrichtigungen. Das reicht fürs Erste. Du brauchst keinen vollständigen Observability-Stack mit Dashboards, Alarmen und verteiltem Tracing.

Füge deiner Anwendung selbst ein oder zwei einfache Metriken hinzu. Zähle die Anzahl der eingehenden Anfragen, die Fehlerrate und die durchschnittliche Antwortzeit. Diese drei Zahlen sagen dir, ob eine neue Version nach dem Deployment normal läuft. Wenn die Fehlerrate steigt oder die Antwortzeit springt, weißt du, dass etwas nicht stimmt. Du kannst die Pipeline-Logs prüfen, um zu sehen, was sich geändert hat, und bei Bedarf zurückrollen.

Das Eine, das kleine Teams vergessen

Dokumentation. Nicht die lange, detaillierte Sorte, die niemand liest. Nur eine kurze Notiz darüber, wie die Pipeline funktioniert, was zu tun ist, wenn sie fehlschlägt, und wie man zu einer früheren Version zurückrollt. Schreib es auf, solange es dir noch frisch im Kopf ist. Diese Notiz wird entscheidend, wenn du nicht erreichbar bist – im Flugzeug, krank oder im Urlaub – und etwas schiefgeht. Sie hilft auch, wenn dein Team wächst und eine neue Person den Auslieferungsprozess verstehen muss.

Eine einfache Markdown-Datei in deinem Repository reicht völlig aus. Enthalten sein sollten:

  • Der Branch, der das Deployment für jede Umgebung auslöst
  • Die Befehle für ein manuelles Rollback
  • Wo Logs zu finden sind, wenn ein Schritt fehlschlägt
  • Wen man kontaktieren kann, wenn beide nicht verfügbar sind

Wann dieses Muster nicht mehr funktioniert

Diese einfache Pipeline wird nicht ewig passen. Wenn dein Team wächst, deine Anwendung komplexer wird und sich deine Nutzerbasis vergrößert, brauchst du mehr Struktur. Du brauchst vielleicht parallele Testläufe, Datenbank-Migrationsschritte, Freigabeprozesse für Compliance oder Deployment-Strategien wie Blue-Green oder Canary Releases. Du musst Build, Test und Deploy möglicherweise in verschiedene Phasen mit unterschiedlichen Verantwortlichkeiten aufteilen.

Aber für ein kleines Startup, das schnell sein muss, ist der Start mit einer einfachen Pipeline und voller Verantwortung der richtige Schritt. Du lernst die Grundlagen der Auslieferung, ohne von komplexen Werkzeugen erschlagen zu werden. Du baust eine Grundlage, die sich weiterentwickeln kann, wenn sich deine Anforderungen ändern. Und du vermeidest die Falle des Overengineerings, bevor du ein Produkt hast, das tatsächlich jemand nutzt.

Praktische Checkliste für deine erste Pipeline

  • Drei Schritte definieren: Build, Test, Deploy
  • Ein CI-Werkzeug auswählen (GitHub Actions, GitLab CI oder integriertes Tool des Cloud-Anbieters)
  • Pipeline so einrichten, dass sie bei Push auf main ausgelöst wird
  • Manuellen Deploy-Schritt für die Produktion hinzufügen
  • Anzahl der Anfragen, Fehlerrate und Antwortzeit in der App protokollieren
  • Ein einseitiges Dokument schreiben, das erklärt, wie man zurückrollt
  • Pipeline testen, indem man sie absichtlich kaputt macht und repariert

Das Fazit

Eine einfache Pipeline, die von den Leuten gebaut wird, die den Code besitzen, ist besser als ein komplexes System, das von jemand anderem verwaltet wird. Fang klein an, übernimm den Prozess und lass die Grundlage mit deinem Produkt wachsen. Du wirst im ersten Monat, in dem du eine Pipeline betreibst, mehr über Auslieferung lernen als in einem Jahr, in dem du nur darüber liest.