Die kleinste CI/CD-Pipeline, die wöchentliche Releases trägt

Freitag, 16 Uhr, und fünf Leute schauen auf Slack

Der letzte Ticket-Merge ist durch, jemand startet das Deploy-Skript, und das halbe Team starrt zwanzig Minuten lang in einen Kanal, um zu sehen, ob etwas brennt.

Das ist keine Pipeline. Das ist ein Ritual mit einem Rollback-Plan aus Hoffnung.

Continuous Integration heißt: Jeder Push führt Ihre Tests automatisch aus. Continuous Deployment heißt: Code, der diese Tests bestanden hat, landet in Produktion, ohne dass jemand einen Befehl tippt. Ein Fünferteam mit wöchentlichem Release braucht beides und erstaunlich wenig darüber hinaus.

Genau diese zweite Hälfte fehlt in den meisten Texten zum Thema. Die Gattung wird von Plattformteams in Unternehmen mit Plattformteams geschrieben und setzt stillschweigend voraus, dass Sie eine Person für den Betrieb abstellen können.

Können Sie nicht. Eine CI/CD-Pipeline aufbauen heißt bei fünf Personen deshalb etwas anderes als in der Literatur: die kleinste Version, die trägt, fertig an einem Nachmittag, ohne dass in irgendeiner Stellenbezeichnung das Wort “Platform” vorkommt.

Wöchentlich ist Mittelfeld, und das ist völlig in Ordnung

Die DORA-Benchmarks sind seit Jahren stabil. Der Bericht von 2024 ordnet Teams, die zwischen täglich und wöchentlich ausliefern, dem oberen Feld zu und wöchentlich bis monatlich dem Mittelfeld. Wöchentlich ist die Grenze zwischen beidem.

Die DORA-Ausgabe 2025 widmet sich KI-gestützter Entwicklung und sortiert die Befragten in sieben Team-Profile, die Felder oben stammen also aus dem Bericht von 2024 und bleiben die Zahlen, an denen sich ein Fünferteam ausrichten kann.

Die brauchbare Lesart davon: Wöchentliche Releases sind kein Mangel, den man mit mehr Werkzeugen repariert. Und die Pipeline, die Sie von wöchentlich auf täglich bringt, ist dieselbe Pipeline, nur öfter ausgeführt.

Das Ziel ist also keine ausgefeilte Pipeline. Das Ziel ist eine Pipeline, die langweilig genug ist, dass niemand zögert, sie zu benutzen.

CI/CD Best Practices, die sich bei fünf Entwicklern rechnen

Sechs Stück. Alles andere wartet, bis etwas Konkretes schiefgeht.

1. Tests laufen auf dem Merge Request, nicht nach dem Merge. Ein roter Build auf main bedeutet, dass eine Person main repariert, während vier warten. Ein Branch-Schutz, der den Merge-Button bei fehlgeschlagenen Checks sperrt, kostet Sie ein Häkchen.
2. main ist jederzeit deploybar, und Deployen ist genau eine Aktion. Wenn zum Ausliefern ein Runbook gehört, eine Reihenfolge oder eine Person, die die Reihenfolge kennt, haben Sie einen Bus-Faktor von eins.
3. Liefern Sie das Artefakt aus, das Sie getestet haben. Einmal bauen, denselben Container durch Staging nach Produktion befördern. Wer in jeder Stufe neu baut, hat in Produktion etwas laufen, das nie getestet wurde.
4. Secrets liegen im Secret Store des Anbieters und sonst nirgends. Nicht im Repository, nicht in einer .env, die jemand per Chat verschickt, nicht im Deploy-Skript. Einen geleakten Schlüssel zu rotieren ist ein schlechter Nachmittag; einen zu rotieren, dessen Kopien Sie nicht alle finden, ist eine schlechte Woche.
5. Halten Sie einen Rollback bereit, den eine müde Person um 22 Uhr auslöst. Ein Befehl oder ein Knopf zurück auf das vorige Release. Falls Ihre Antwort “Commit zurücknehmen und neu deployen” lautet: Stoppen Sie das einmal mit der Uhr und prüfen Sie, ob Ihnen die Antwort dann noch gefällt.
6. Die gesamte Pipeline bleibt unter zehn Minuten. Darüber warten die Leute nicht mehr, sondern sammeln Änderungen, und damit sind Sie wieder am Anfang. Parallelisieren Sie die Testsuite, bevor Sie irgendetwas anderes optimieren.

Beachten Sie, was fehlt. Keine Umgebungen jenseits von Staging, kein Freigabe-Workflow, kein Dashboard.

Was bei fünf Personen schlicht zu früh kommt

In der DevOps-Debatte gelten die folgenden Punkte als Grundausstattung. Für fünf Personen mit wöchentlichem Release ist jeder einzelne Aufwand ohne passenden Gegenwert.

Kubernetes. Es löst Scheduling über viele Maschinen und viele Services. Sie haben einen Service und eine Maschine. Eine verwaltete Plattform oder ein einzelner Docker-Host erledigt dasselbe mit ungefähr keiner Betriebsoberfläche.

Canary- und Blue-Green-Deployments. Beide begrenzen den Schadensradius bei Lastmengen, in denen ein schlechtes Release Tausende Nutzer erreicht, bevor ein Mensch etwas bemerkt. Bei wöchentlicher Frequenz und einem geprobten Rollback bemerken Sie es zuerst.

GitOps-Controller. ArgoCD und Flux gleichen deklarierten Zustand über viele Cluster ab. Mit einem Cluster betreiben Sie eine Abgleichsschleife, um eine Anwendung auszuliefern, für die ein Webhook gereicht hätte.

Eine Feature-Flag-Plattform. Flags selbst sind nützlich, und ein Boolean in Ihrer Konfiguration ist bereits ein Flag. Das Abo, das SDK und die Abrechnung pro Sitz sind für Teams gedacht, die Experimente über mehrere Squads fahren.

Mehrstufige Freigaben. Freigabestufen kodieren organisatorisches Misstrauen. In einem Team, in dem alle die Merge Requests der anderen prüfen, fügt eine zweite Stufe nach dem Review nur Wartezeit hinzu.

Eine vollständige End-to-End-Browsersuite. Langsam, wackelig und teuer in der Pflege. Decken Sie die zwei oder drei Abläufe ab, die Umsatz erzeugen, und überlassen Sie den Rest den Integrationstests.

Eine Rufbereitschaft. Fünf Personen tragen keine echte Rotation. Alarmieren Sie in einen gemeinsamen Kanal, klären Sie, wer zuerst schaut, und sprechen Sie erneut darüber, wenn Sie zwölf sind.

Jeder Punkt auf dieser Liste ist für irgendjemanden richtig. Nur eben nicht für Sie, nicht jetzt.

GitHub Actions oder GitLab CI: Die langweilige Antwort stimmt trotzdem

Nehmen Sie das Werkzeug, bei dem Ihr Code ohnehin liegt.

Diese Antwort enttäuscht viele, deshalb die Begründung. Beide Produkte führen dieselben Stufen aus Lint, Test, Build und Deploy gegen dieselben Container-Images aus, beide sind bei kleinem Volumen kostenlos, und die Konzepte lassen sich direkt übertragen. Eine funktionierende Pipeline zu migrieren kostet eine Woche Aufmerksamkeit und liefert am Ende eine Pipeline, die dasselbe tut wie die alte.

Die Unterschiede, die bei fünf Personen tatsächlich auffallen, betreffen die Form, nicht den Funktionsumfang.

GitHub Actions verteilt die Konfiguration über mehrere Workflow-Dateien und stützt sich stark auf einen Marktplatz fertiger Actions. Dieser Marktplatz ist der größte Vorteil im Angebot und zugleich die größte Lieferketten-Angriffsfläche Ihrer Pipeline: Pinnen Sie fremde Actions auf einen Commit-Hash statt auf ein bewegliches Tag.

GitLab CI legt alles in eine .gitlab-ci.yml und bringt Container-Registry, Umgebungen und Review Apps im selben Produkt mit. Weniger bewegliche Teile, ein kleineres Ökosystem und eine Konfigurationsdatei, die jenseits einiger hundert Zeilen wirklich unhandlich wird.

Für deutsche Teams kommt ein dritter Punkt dazu, den die englischsprachige Diskussion selten erwähnt. Ihr Runner sieht Ihren Quellcode und meist auch Produktions-Secrets, und wer eigene Runner betreibt, bestimmt deren Standort selbst. Bei GitLab misst das Compute-Kontingent nur die von GitLab selbst betriebenen Instance-Runner, ein eigener Runner zählt also nicht dagegen, was eine Maschine bei einem deutschen Hoster doppelt attraktiv macht.

Was die drei großen Anbieter tatsächlich kosten

Die Form des Preismodells ist wichtiger als der Listenpreis, denn die Form entscheidet, welches Wachstumsmuster Sie überrascht.

Die Zahlen sind Stand 2026 und werden von den Anbietern regelmäßig angepasst, prüfen Sie sie vor der Budgetplanung nach.

Der macOS-Faktor erwischt die meisten Teams. Eine Linux-Minute auf GitHubs Standard-Runner mit zwei Kernen kostet den Bruchteil eines Cents, eine macOS-Minute etwa das Zehnfache, und ein Mobile-Team mit Build-Matrix über beide Systeme erfährt davon aus der Rechnung statt aus einem Merge Request.

Bei GitLab liegt die Kante woanders. Der Minutentopf hängt am obersten Namespace, fünf Personen und fünfzig Personen starten also vom selben Kontingent, und 400 Minuten sind weg, sobald mehr als ein Projekt pusht. Härter trifft die Nutzergrenze: Private Free-Namespaces mit mehr als fünf Mitgliedern gehen in einen Nur-Lese-Zustand.

CircleCIs Credit-Modell ist das flexibelste und das am wenigsten vorhersagbare. Laufzeit wird in Credits umgerechnet, abhängig von der gewählten Ressourcenklasse, und Zusatzfunktionen rechnen obendrauf ab. Die Frage “Was hat dieser Durchlauf gekostet?” beantwortet man dort mit einer Rechnung statt mit einem Blick.

Nichts davon sollte bei fünf Personen die Auswahl bestimmen. Alles davon sollte bestimmen, ob Sie es vor der Rechnung merken.

Was zuerst kaputtgeht, ist nicht der Anbieter

Es ist die Testsuite.

Der Klassiker: Ein Viererteam baut an einem Nachmittag eine saubere Pipeline, und sie funktioniert. Ein halbes Jahr später fallen drei Tests sporadisch aus Gründen um, die niemand verfolgt hat, also hat das Team gelernt, den Job neu zu starten. Zwei Monate weiter ist der Neustart Reflex, und damit blockiert die Pipeline nichts mehr.

Das ist eine tote Pipeline, die weiterhin grün anzeigt. Am Werkzeug liegt es nicht. Das Signal ist weg.

Die Reparatur ist unspektakulär: Quarantäne für den wackeligen Test an dem Tag, an dem er zum zweiten Mal umfällt, Ticket anlegen, und die Quarantäneliste so führen, dass sie tatsächlich jemand liest. Vierzig verlässliche Tests schlagen vierhundert, denen niemand glaubt.

Die Laufzeit verrottet nach demselben Muster. Aus zehn Minuten werden vierzehn, aus vierzehn fünfundzwanzig, und die Leute bündeln drei Tage Arbeit in einen Merge. Genau das Release-Risiko also, das CI beseitigen sollte.

Wenn die Repository-Struktur mitschuldig ist, lohnt der eigene Blick. Monorepo-Pipelines, die bei jedem Push alle Tests ausführen, machen aus zehn Minuten Build vierzig, was wir in Monorepo oder Multirepo für kleine Teams durchgerechnet haben.

CI/CD-Pipeline aufbauen: das Programm für die erste Woche

Vier Schritte, in dieser Reihenfolge:

1. Bringen Sie die Testsuite auf jeden Merge Request und aktivieren Sie den Branch-Schutz, damit ein roter Build den Merge blockiert. Hören Sie eine Woche lang hier auf, falls Sie nicht weiterkommen. Das ist die Hälfte, die Fehler fängt.
2. Ergänzen Sie einen Deploy-Job, der beim Merge auf main auslöst. Wohin deployt wird, ist eine eigene Entscheidung, und die realistischen Optionen ohne Kubernetes haben wir in Coolify, Kamal oder einfach Cloud Run gegeneinandergestellt.
3. Verschieben Sie jedes Secret in den Secret Store des Anbieters und löschen Sie die Kopien. Proben Sie danach einen Rollback, solange nichts brennt, und notieren Sie den Befehl dort, wo ihn ein Team ohne Rufbereitschaft nachts findet.
4. Schalten Sie automatische Abhängigkeits-Updates ein und leiten Sie fehlgeschlagene Builds in den Kanal, den die Leute ohnehin lesen. Wie schnell Sie bekannte Lücken schließen sollten, steht mit konkreten Zeitfenstern in unserem IT-Sicherheitskonzept für den Mittelstand.

Liefern Sie wöchentlich aus. Halten Sie die Pipeline langweilig. Die ausgefeilten Teile kommen an dem Tag dazu, an dem ein Vorfall beweist, dass Sie sie brauchen, und keinen Sprint früher.

Gehört zum Deployment bei Ihnen immer noch das gemeinsame Starren in einen Chat-Kanal? Sprechen wir darüber. Wir schauen uns an, was Sie ausliefern, wie oft, und was sich zuerst zu automatisieren lohnt.