Eine normale Anwendung braucht keine Plattform-Pipeline. Sie braucht eine Strecke, der das Team am Dienstagvormittag traut. Alles, was ich in die erste Fassung packe, dient diesem einen Satz.
GitHub Actions oder GitLab CI ist dabei fast egal. Der Unterschied zwischen den beiden ist Syntax. Der Unterschied zwischen einer Strecke, der man traut, und einer, der man nicht traut, ist es nicht.
Was ich unter normal verstehe
Gemeint ist ein Team, eine Handvoll Dienste, ein Repository, eine Auslieferung auf einen Server, auf ECS oder auf etwas in derselben Größenordnung. Kein internes Portal für zwölf Teams, keine eigene Runner-Flotte, kein Katalog eigener Actions. Die Strecke hier setzt voraus, dass der Code in Git liegt und ein Befehl ihn bauen kann.
Wer heute noch Dateien von Hand auf den Server legt, steht einen Schritt früher. Den beschreibt Wenn das Deployment noch per FTP läuft.
Die vier Dinge der ersten Fassung
Eine Prüfung vor dem Zusammenführen, die Nein sagen kann. Tests, und die statische Analyse, die es schon gibt. Die Prüfung, die vor dem Merge läuft, bleibt unter zehn Minuten. Darüber fangen Leute an, Änderungen zu bündeln, und der Vorteil kleiner Schritte ist weg. Mehr zum Begriff unter CI/CD. Lange Tests gehören in eine zweite Stufe nach dem Merge, nicht in den Weg, den jeder Commit nehmen muss.
Ein Artefakt je Commit. Ein Container-Abbild oder ein Paket, und dasselbe Artefakt geht durch Abnahme und Produktion. Ein zweiter Bau je Stufe prüft etwas anderes als das, was später läuft: dieselben Zutaten, ein anderer Zeitpunkt. Die Stufen unterscheiden sich in Konfiguration und Freigabe, nicht im Inhalt.
Abnahme folgt dem Merge. Produktion wartet auf einen Menschen. Continuous Delivery heißt, dass jeder geprüfte Stand ausgeliefert werden könnte. Es heißt nicht, dass jeder Merge allein in Produktion geht. Solange der Rückweg noch aufregend ist, gibt ein Mensch die Produktion frei. Das ist die normale Endstufe, keine halbfertige.
Ein Rückweg, der das vorherige Artefakt ist und den schon jemand gegangen ist. Zurück heißt: dasselbe Artefakt wie beim letzten guten Stand, noch einmal ausgeliefert. Eine Schemaänderung, die eine Spalte umbenennt, macht genau das unmöglich, egal was im Runbook steht. Schemaänderungen laufen deshalb in zwei Schritten: erst ergänzen, dann die Anwendung, dann aufräumen. Einmal wird der Rückweg an einem echten Dienst ausgeführt. Ein beschriebener Rollback ist eine Behauptung.
Wie der Wechsel zwischen zwei Ständen ohne Kubernetes aussieht, steht in Blue/Green und Canary ohne Kubernetes. Das ist die Ausrollform. Sie ist nicht die Strecke, die das Artefakt baut.
Zugang und fremde Actions gehören dazu
Zwei Dinge sehen nach Härtung aus und gehören trotzdem in die erste Fassung, weil sie klein sind und weil ihr Fehlen der Teil ist, den ein Angreifer benutzt.
Keine dauerhaften Zugangsschlüssel. Wo die Strecke AWS berührt, holt sie sich Rechte zur Laufzeit über OIDC: ein kurzlebiges Token, getauscht gegen eine Rolle. Gebunden an Repository, Zweig und Umgebung ist es nur, wenn die Vertrauensrichtlinie der Rolle genau das prüft; eine zu offene Richtlinie lässt jedes Repository herein. Ein Schlüssel im Secret-Speicher gilt, bis ihn jemand dreht. Niemand dreht ihn.
Fremde Actions auf einen Commit-SHA, nicht auf ein Tag. Im März 2025 wurden mehrere Versions-Tags einer weit verbreiteten Action nachträglich auf einen anderen Commit umgebogen (CVE-2025-30066, tj-actions/changed-files). Der Commit las Geheimnisse aus dem Speicher des Runners und schrieb sie in die Workflow-Logs. Ein Tag ist kein Fixpunkt. Das Pinning ist eine Zeile je Action, keine spätere Phase.
Die Vorfälle darum, die Attestations und die Frage, wann ein selbstbetriebener Runner sich rechnet, stehen auf der Seite zum Aufbau einer Deployment-Pipeline. Hier reicht die Grenze: Diese beiden Punkte sind die erste Fassung. Der Rest der Lieferkette kann warten, bis die Strecke langweilig ist.
Ob hinter der Rolle ein AWS-Konto steht oder mehrere, ändert die Strecke nicht. Es ändert, gegen welche Rolle getauscht wird. Die Entscheidung davor steht in Ein AWS-Konto oder mehrere.
Was wartet, bis es einen Anlass gibt
Die erste Fassung ist absichtlich klein. Diese Dinge lasse ich weg, bis jemand ein konkretes Problem nennt.
- Eine eigene Runner-Flotte. Zuerst wird gemessen, wo die Minuten liegen: doppelte Bauschritte, Caches, Tests ohne Parallelität. Selbstbetriebene Runner ersetzen eine Rechnung durch Betriebsarbeit. Das ist nicht immer der bessere Tausch.
- Canary für einen Dienst mit einer oder zwei Instanzen. Canary setzt voraus, dass sich Verkehr teilen lässt und dass eine kleine Scheibe etwas aussagt. Sonst ist der vorherige Stand als Artefakt der Rückweg, und Blue/Green reicht, wenn zwei Stände nebeneinander laufen können.
- Ein Portal, ein Katalog eigener Actions, eine Policy-Engine. Der zweite Dienst kopiert den Workflow des ersten. Eine gemeinsame Plattform wird fällig, wenn die Kopien aus demselben Grund auseinanderlaufen, nicht wenn der zweite Dienst entsteht.
- Infrastruktur und Anwendung in einem Workflow mit einer Freigabe. Ein Terraform-Plan und ein Release sind zwei Risiken. Sie bekommen zwei Wege. Dieselbe Person darf beide freigeben. Dieselbe Taste sollte es nicht sein.
- Produktion bei jedem Merge. Das wird tragfähig, wenn der Rückweg langweilig geworden ist. Vorher liefert die Automatisierung nur schneller etwas, das niemand zurückholen will.
Vier Argumente, die allein nicht reichen
„Jeder Commit muss in Produktion.“ Das ist eine Entscheidung über die Reichweite eines Fehlers, keine Eigenschaft von CI. Delivery heißt, der Stand könnte hinaus. Deployment heißt, er geht hinaus. Die zweite Entscheidung trifft das Team, wenn der Rückweg geprobt ist.
„Wir brauchen GitOps.“ Ein Pull Request, der ein Artefakt erzeugt, und ein Mensch, der es befördert, sind bereits der Kreis. Ein zweites Werkzeug, das einen Cluster abgleicht, verdient seinen Platz, wenn der Cluster das Problem ist. Für eine normale Anwendung ist der Git-Host die Steuerstelle der Strecke.
„Die Pipeline muss für alle künftigen Dienste passen.“ Der zweite Dienst kopiert den ersten Workflow und ändert die drei Zeilen, die ihm gehören. Eine gemeinsame Vorlage entsteht aus der dritten Kopie, die am selben Punkt gebrochen ist. Vorher ist die Vorlage eine Vermutung über Dienste, die es noch nicht gibt.
„Sicherheit kommt in Phase zwei.“ Die Schlüssel und die unangepinnten Actions sind der Teil, den ein Angreifer vor Phase zwei benutzt. Pinning und OIDC sind klein genug für den ersten Tag. Ein SBOM, eine Organisationsrichtlinie, die das Pinning erzwingt, ein eigener Runner: das ist Phase zwei, und sie hat einen Anlass, nämlich eine Strecke, die schon läuft.
Was die Strecke nicht repariert
Eine Pipeline macht ein großes Release nicht klein. Wenn die Änderung eine Woche Arbeit ist, liefert die Strecke diese Woche nur schneller aus. Kleine Schritte sind eine Arbeitsweise. Die Pipeline macht sie möglich und erzwingt sie nicht.
Eine Prüfung, die nicht rot werden kann, ist eine grüne Lampe. Exit-Code ungleich null muss den Merge aufhalten. Ein Test, der die Ausnahme schluckt und mit Erfolg endet, gehört repariert, bevor ein weiteres Werkzeug in die Strecke kommt.
Und die Pipeline ersetzt niemanden, der den Rückweg kennt. Einmal mit dem Team an einem echten Dienst gegangen, danach liegt der Weg im Repository, nicht in einem Kopf. Das ist der Punkt, an dem ein Deployment den Zeitpunkt verliert und ein Dienstagvormittag reicht.
Die Entscheidung als Tabelle
| Erste Fassung | Später, mit Anlass | |
|---|---|---|
| Prüfung vor dem Merge | ja, unter zehn Minuten | langsame Tests in einer zweiten Stufe |
| Artefakt | eines, wird befördert | dasselbe, kein zweiter Bau |
| Produktion | ein Mensch gibt frei | automatisch, wenn der Rückweg langweilig ist |
| Zugang zur Cloud | OIDC, keine Langzeitschlüssel | dieselbe Rolle, enger geschnitten |
| Fremde Actions | Commit-SHA | als Richtlinie der Organisation erzwungen |
| Rückweg | vorheriges Artefakt, einmal gegangen | Blue/Green oder Canary, wenn der Verkehr es hergibt |
| Runner | die des Anbieters | eigene, wenn die Rechnung das sagt |
| Zweiter Dienst | Workflow kopieren | gemeinsame Vorlage, wenn die Kopien gleich brechen |
Die Frage, mit der ich anfange
Ich frage nicht nach dem CI-Produkt. Ich frage: Welchen Schritt macht heute ein Mensch, weil er der Strecke nicht traut?
„Produktion gibt ein Mensch frei“ kann die gewollte Form sein. Dann ist die Strecke fertig, sobald Prüfung, Artefakt und ein gegangener Rückweg da sind.
„Jemand baut auf dem Laptop und kopiert Dateien“ heißt, die erste Fassung fehlt noch. „Niemand weiß, ob der Rückweg funktioniert“ heißt, es fehlt die Probe, nicht ein weiteres Werkzeug. „Der Durchlauf dauert vierzig Minuten, weil dreimal gebaut wird“ heißt, es fehlt das eine Artefakt.
Die kleinste Strecke, der das Team am Dienstag traut, ist die richtige. Wer sie bauen lässt, findet den Ablauf auf der Seite zum Aufbau einer Deployment-Pipeline: ein Artefakt, Zugänge ohne Langzeitschlüssel, ein Rückweg, der geprobt ist, und danach das Team, das die Strecke ohne mich ändert.
