Was einen CI/CD-Pipeline tatsächlich startet

Ein Entwickler schließt einen Bugfix ab, tippt git push und geht. Wenige Minuten später leuchtet der Team-Chat auf: „Build fehlgeschlagen.“ Niemand hat die Pipeline-Konfiguration angefasst. Niemand hat einen Button gedrückt. Die Pipeline ist einfach gelaufen.

Das ist in den meisten Teams normal. Aber wenn man jemanden fragt, warum die Pipeline gelaufen ist, kommt oft eine vage Antwort: „Weil ich Code gepusht habe.“ Das stimmt zwar, überspringt aber ein wichtiges Detail. Pipelines starten nicht von selbst. Etwas muss sie auslösen. Und die Art des Triggers, den du wählst, verändert, wie dein Team arbeitet, was getestet wird und wann etwas in Produktion geht.

Schauen wir uns die realen Situationen an, in denen Pipelines starten, und was jeder Trigger für deinen täglichen Workflow bedeutet.

Wenn ein Entwickler Code pusht

Der häufigste Trigger ist ein Commit, der in ein gemeinsames Repository gepusht wird. Ein Entwickler schließt eine Änderung ab, committed sie lokal und pusht zu GitHub, GitLab oder Bitbucket. Das Repository sendet einen Webhook an das CI/CD-System, und die Pipeline startet.

Das klingt einfach, aber die Details sind wichtig. Der Commit trägt Metadaten: welche Dateien geändert wurden, wer die Änderung vorgenommen hat und die Commit-Nachricht. Eine gute Pipeline nutzt diese Metadaten, um zu entscheiden, was zu tun ist. Wenn der Commit nur eine README-Datei betrifft, musst du wahrscheinlich nicht die gesamte Testsuite ausführen und auf Staging deployen. Wenn der Commit aber Anwendungscode ändert, sollte die Pipeline alles ausführen.

Das folgende Diagramm zeigt, wie ein Push-Trigger basierend auf Commit-Metadaten verzweigt:

So könntest du einen solchen Push-Trigger in einem GitHub Actions Workflow definieren:

name: CI Pipeline
on:
  push:
    branches:
      - main
      - 'feature/**'
    paths-ignore:
      - 'README.md'
      - 'docs/**'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test

Teams, die jeden Commit gleich behandeln, verschwenden Zeit und Rechenressourcen. Ein smarterer Ansatz ist, die Pipeline den Commit und Branch prüfen zu lassen, bevor sie den nächsten Schritt festlegt. Ein Commit auf einem Feature-Branch könnte zum Beispiel nur Unit-Tests und Linting ausführen, während ein Commit auf dem main-Branch Integrationstests und ein Staging-Deployment auslöst.

Wenn ein Pull Request gemerged wird

Viele Teams nutzen Pull Requests oder Merge Requests als Review-Gate. Ein Entwickler eröffnet einen PR, Teammitglieder reviewen den Code, und wenn er genehmigt ist, merged ihn jemand. Der Merge selbst kann ein Trigger sein.

Das unterscheidet sich von einem normalen Commit-Trigger. Ein Merge signalisiert in der Regel, dass die Änderung die menschliche Überprüfung bestanden hat und bereit ist, in einen stabileren Branch zu gelangen. Pipelines, die durch Merges ausgelöst werden, führen oft strengere Prüfungen durch: längere Testläufe, Sicherheitsscans oder Datenbank-Migrationstests. Die Annahme ist, dass diese Änderung bald in Produktion geht, also willst du mehr Vertrauen haben.

Manche Teams führen Pipelines auch auf dem Pull Request selbst aus, vor dem Merge. Das gibt frühes Feedback. Aber der Merge-Trigger ist der Moment der Wahrheit. Sobald der Code im main-Branch ist, wird er Teil der gemeinsamen Historie. Eine fehlgeschlagene Pipeline an diesem Punkt bedeutet, dass das Team schnell handeln muss, weil andere Entwickler diesen fehlerhaften Code pullen werden.

Wenn die Uhr es sagt

Nicht alle Pipelines brauchen eine Code-Änderung, um zu laufen. Geplante Trigger starten eine Pipeline zu einer bestimmten Zeit, unabhängig davon, ob jemand Code gepusht hat.

Typische Anwendungsfälle sind:

• Ausführen langer Integrationstests jede Nacht, wenn niemand auf Ergebnisse wartet.
• Aktualisieren von Staging-Umgebungen mit Produktionsdaten-Snapshots.
• Aktualisieren von Abhängigkeitsversionen oder Ausführen von Schwachstellenscans.
• Durchführen von Backups oder Aufräumarbeiten.

Geplante Trigger sind nützlich für Arbeiten, die regelmäßig stattfinden sollen, aber nicht von der Aktivität eines Entwicklers abhängen. Sie erkennen auch Probleme, die erst mit der Zeit auftreten, wie eine sich langsam verschlechternde Testumgebung oder ein bald ablaufendes Zertifikat.

Der Nachteil ist, dass eine geplante Pipeline laufen kann, obwohl sich nichts geändert hat. Wenn sie fehlschlägt, muss jemand untersuchen, ob der Fehler echt ist oder nur ein flaky Test. Teams sollten geplante Pipelines auf Aufgaben konzentrieren, die wirklich eine regelmäßige Ausführung benötigen, nicht auf Dinge, die durch eine Code-Änderung ausgelöst werden könnten.

Wenn jemand den Button drückt

Manuelle Trigger geben einem Menschen das letzte Wort. Anstatt dass die Pipeline automatisch startet, meldet sich jemand im CI/CD-System an und klickt auf „Ausführen“ oder „Deployen“.

Das ist üblich für Produktions-Deployments. Selbst wenn alle automatischen Checks bestanden sind, wollen viele Teams, dass eine Person das Deployment explizit genehmigt. Manuelle Trigger decken auch Notfälle ab: Zurücksetzen auf eine vorherige Version, erneutes Deployen nach einem Umgebungsabsturz oder Ausführen einer einmaligen Datenmigration.

Manuelle Trigger dienen nicht nur der Kontrolle. Sie tragen auch Verantwortung. Wenn jemand manuell eine Pipeline startet, sollte er festhalten, warum. Ein gutes CI/CD-System erlaubt es, eine Notiz hinzuzufügen: „Zurücksetzen auf v2.1.3, weil das letzte Release ein Datenbankverbindungsleck hat.“ Diese Metadaten werden Teil des Audit-Trails.

Das Risiko bei manuellen Triggern ist, dass sie zum Flaschenhals werden. Wenn jedes Deployment erfordert, dass jemand einen Button drückt, und diese Person im Urlaub ist, wird nichts ausgeliefert. Teams sollten manuelle Trigger für Aktionen reservieren, die wirklich menschliches Urteilsvermögen erfordern, nicht für Routine-Schritte, die automatisiert werden könnten.

Warum Metadaten wichtiger sind als du denkst

Jeder Trigger trägt Informationen. Ein Commit-Trigger trägt den Commit-Hash, den Branch-Namen und den Autor. Ein Merge-Trigger trägt die Pull-Request-Nummer und die Namen der Reviewer. Ein manueller Trigger trägt den Namen des Operators und seinen angegebenen Grund.

Diese Metadaten sind nicht nur fürs Logging da. Die Pipeline nutzt sie, um Entscheidungen zu treffen. Soll sie eine vollständige Testsuite oder nur Smoke-Tests ausführen? Soll sie auf Staging oder Produktion deployen? Soll sie den diensthabenden Ingenieur benachrichtigen oder nur eine Zusammenfassung im Team-Channel posten?

Ohne Metadaten ist die Pipeline blind. Sie führt jedes Mal die gleichen Schritte aus, egal was sich geändert hat. Das funktioniert für einfache Projekte, aber wenn dein System wächst, brauchst du bedingte Logik. Der Trigger ist der erste Ort, um diese Logik einzubringen.

Eine kurze Checkliste zur Auswahl von Triggern

Wenn du eine neue Pipeline einrichtest oder eine bestehende überprüfst, helfen dir diese Fragen bei der Entscheidung, welche Trigger du verwenden solltest:

• Braucht jeder Commit die gleiche Pipeline, oder kannst du Schritte für dokumentationsbezogene Änderungen überspringen?
• Möchtest du Feedback zu Pull Requests vor dem Merge oder erst nach dem Merge?
• Gibt es Aufgaben, die täglich laufen sollten, auch wenn niemand Code pusht?
• Welche Schritte benötigen menschliche Genehmigung und welche können automatisch laufen?
• Erfasst deine Pipeline genügend Metadaten, um Fehler später debuggen zu können?

Das Fazit

Ein Pipeline-Trigger ist nicht nur ein Startknopf. Er ist ein Entscheidungspunkt, der definiert, wann die Arbeit beginnt, welcher Kontext verfügbar ist und wie viel Automatisierung sicher ist. Wähle Trigger basierend auf dem Risiko und der Häufigkeit jeder Aktion, nicht aus Gewohnheit. Eine gut getriggerte Pipeline führt die richtigen Checks zur richtigen Zeit aus, ohne darauf zu warten, dass jemand daran denkt, einen Button zu drücken.