CI/CD
Wer seine Releases in die Nacht legt und den Freitag meidet, hat keine Terminfrage, sondern ein Vertrauensproblem: Die Strecke, die den Code in Produktion bringt, ist die am wenigsten geprüfte Software im Haus. Sie ist gewachsen, sie hat einen Autor, der nicht mehr da ist, und sie hält Zugangsschlüssel, die niemand mehr zählt. Das lässt sich reparieren, und zwar ohne Werkzeugwechsel.
Bestandsaufnahme und Zielbild als abgegrenztes Zwei- bis Vier-Wochen-Mandat, Umsetzung danach nach Umfang. Betrieb und Bereitschaft bleiben bei Ihrem Team, dafür ist die Übergabe Teil der Arbeit.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
In fast jedem gewachsenen System ist die Auslieferungsstrecke der Teil mit den schwächsten Regeln. Kein Review, keine Tests, keine Versionierung der Schritte, dafür Zugriff auf Produktion und auf alle Zugangsdaten, die dort gebraucht werden. Das Ergebnis ist ein Bau je Stufe statt eines Artefakts für alle: Was in der Abnahme geprüft wurde, ist nicht das, was in Produktion läuft, sondern ein zweiter Bau mit denselben Zutaten und einem anderen Zeitpunkt. Genau darin steckt der Grund, warum niemand freitags deployen will.
Der zweite Punkt ist ein Sicherheitsproblem, das wie Bequemlichkeit aussieht: hinterlegte Langzeitschlüssel. Ein AWS-Zugriffsschlüssel im Secret-Speicher der Pipeline gilt, bis ihn jemand dreht, und niemand dreht ihn. Was daraus folgt, wurde in den letzten achtzehn Monaten mehrfach vorgeführt. Im März 2025 bogen Angreifer die Versions-Tags einer weit verbreiteten Action (tj-actions/changed-files, über 23.000 Repositories, CVE-2025-30066) auf einen eigenen Commit um; der las Secrets aus dem Speicher des Runners und schrieb sie in die Logs, die bei öffentlichen Projekten jeder lesen kann. 2026 lief dasselbe Muster zweimal über npm-Pakete: gekaperte Release-Workflows, Tokens aus dem Speicher des Runners, weitergetragen über die Pipelines der nächsten Projekte. Kein einziger dieser Angriffe brauchte eine Lücke in Ihrem Code.
Der dritte Punkt ist der Rückweg. Fast jede Pipeline hat einen dokumentierten Rollback, und fast keine hat einen geprobten. Der Unterschied zeigt sich an der Datenbank: Eine Migration, die eine Spalte umbenennt, macht das Zurückrollen der Anwendung unmöglich, egal was im Runbook steht. Wer den Rückweg wirklich will, baut Schemaänderungen in zwei Schritten und probt einmal, was passiert, wenn er gebraucht wird. Danach ist ein Release eine Routine und kein Ereignis.
Kommt Ihnen etwas davon bekannt vor?Was ich mache
Es entsteht genau ein Artefakt je Commit – ein Container-Abbild oder ein Paket – und dasselbe Artefakt geht durch Abnahme und Produktion. Damit ist geprüft, was ausgeliefert wird, und nicht etwas mit denselben Zutaten. Die Stufen unterscheiden sich nur in Konfiguration und Freigabe, nicht im Inhalt.
Die Pipeline holt sich Rechte zur Laufzeit über OIDC: GitHub Actions oder GitLab CI tauschen ein kurzlebiges Token gegen eine AWS-Rolle, gebunden an Repository, Zweig und Umgebung. Damit gibt es keinen Schlüssel mehr, den man stehlen könnte, und die Rechte der Produktionsstufe hängen nicht mehr an einem Wert im Secret-Speicher.
Fremde Actions werden auf einen vollen Commit-SHA gepinnt statt auf ein Tag, das sich umbiegen lässt – die Empfehlung stammt von GitHub selbst und ist seit August 2025 als Organisationsrichtlinie erzwingbar. Dazu Artifact Attestations, damit nachweisbar bleibt, aus welchem Lauf ein Abbild stammt, und Abhängigkeits-Aktualisierungen als Pull Request statt als Überraschung.
Blue/Green oder Canary, je nachdem was die Anwendung erlaubt, dazu Schemaänderungen in zwei Schritten: erst additiv ausrollen, dann die Anwendung, dann aufräumen. Anschließend wird der Rückweg einmal wirklich gegangen, an einem echten Dienst, mit Ihrem Team dabei. Ein ungeprobter Rollback ist eine Behauptung.
Gemessen wird, wo die Minuten liegen: doppelte Bauschritte, Caches, die nichts sparen, Tests ohne Parallelität, Container-Abbilder ohne Schichtenordnung. Selbstverwaltete Runner kommen erst danach in Frage und nur, wenn sie sich rechnen – sie ersetzen eine Rechnung durch Betriebsarbeit, und das ist nicht immer der bessere Tausch.
Die Pipeline liegt als Code im Repository, mit Kommentaren an den Stellen, an denen jemand später eine Entscheidung treffen muss. Dazu ein Runbook für den Rückweg, eine Notiz zu Freigaben und Zuständigkeiten, und eine Übergabesitzung. Danach ändert Ihr Team die Strecke ohne Rückfrage bei mir.
Wann war Ihr letztes Deployment am Freitagnachmittag?
Schreiben Sie mir, wie Ihre Strecke heute aussieht und was beim letzten Release schiefgegangen ist. Sie bekommen eine Einschätzung, bevor Sie etwas beauftragen.
Ablauf
Vier Schritte, und nach dem zweiten steht das Zielbild samt Aufwand. Kein Schritt setzt voraus, dass Sie den nächsten beauftragen.
Ich lese die Pipeline, die Freigabewege und die Vorfallshistorie der letzten Releases. Ergebnis ist eine Liste: wo hängen Langzeitschlüssel, welche Schritte bauen doppelt, welche Actions sind ungepinnt, wo fehlt der Rückweg.
Welche Stufen es geben soll, wer freigibt, wie das Artefakt befördert wird, wie zurückgerollt wird. Dazu die Reihenfolge nach Nutzen: Was zuerst umgesetzt wird, ist das, was das nächste Release ruhiger macht.
Nicht am Beispielprojekt, sondern an einem Dienst, der wirklich ausgeliefert wird – klein genug für einen Anfang, echt genug als Beweis. Die alte Strecke bleibt daneben stehen, bis die neue zweimal ohne Zwischenfall gelaufen ist.
Ein geprobter Rückweg, ein Durchlauf im Beisein Ihres Teams, dann die Übergabe. Danach übertragen Sie das Muster auf die übrigen Dienste, wenn Sie mögen ohne mich.
Das Ergebnis
Wenn der Rückweg geprobt ist und ein Artefakt durch alle Stufen geht, verliert der Zeitpunkt seine Bedeutung. Das ist der eigentliche Gewinn, und er ist an der Laune des Teams messbar.
Was nicht existiert, kann nicht abfließen. Mit OIDC gibt es im Secret-Speicher keine Zugangsdaten für die Cloud mehr, sondern nur noch kurzlebige Tokens, die an Repository und Umgebung gebunden sind.
Gepinnte Actions, nachweisbare Herkunft der Abbilder und Secrets mit engem Geltungsbereich. Die Angriffe von 2025 und 2026 hätten in einer so gebauten Strecke nichts gefunden.
Ein Bau statt drei, Caches, die wirklich greifen, Tests parallel. Das spart Minuten je Lauf und Stunden je Woche, und es senkt die Rechnung für die Laufzeit gleich mit.
Eingesetzte Technologien
Aus der Praxis
Ein Zahlungssystem für über 6 Mio. Nutzer, bei dem jeder Ausfall unmittelbar Umsatz ist. Die Auslieferung wurde umgebaut, während sie lief: kleinere Schnitte, ein Artefakt je Änderung, ein Rückweg für jeden Schritt. Danach dauerte ein Deployment ein Viertel der Zeit – und war der unauffälligste Teil des Tages.
Case Study lesenEbenfalls aus echten Projekten
Gewachsener Code, manuelle Deployments mit Checkliste, regelmäßige Incidents. Testnetz, Pipeline und Infrastruktur als Code entstanden zusammen; danach lagen die Incidents 90 Prozent niedriger, bei null Tagen Ausfall während des Umbaus.
Case Study lesenMigration auf PHP 8 und Kubernetes bei täglich erscheinenden Inhalten. Möglich war das nur, weil jeder Schritt einzeln ausrollbar und einzeln zurückdrehbar war – die Pipeline war hier Voraussetzung, nicht Nebenprodukt.
Case Study lesen
Mit wem Sie es zu tun haben
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, und die riskantesten Deployments waren nie die häufigen. Es waren die seltenen, die niemand mehr geübt hatte. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Häufige Fragen
Das, wo Ihr Code schon liegt. Beide Systeme können alles, was hier beschrieben ist: kurzlebige Tokens über OIDC, Umgebungen mit Freigaben, Matrixläufe, selbstverwaltete Runner. Der Unterschied zwischen ihnen ist YAML-Syntax und Abrechnung, und der ist klein gegenüber dem Unterschied zwischen einer geprüften und einer gewachsenen Strecke. Deshalb heißt diese Seite nach dem Vorhaben und nicht nach einem Werkzeug: Ein Wechsel ist selten die Lösung, und wenn er es ist, dann aus einem anderen Grund als der Pipeline.
Ja, aber den mechanischen Teil sollten Sie nicht bezahlen: GitHub liefert dafür ein eigenes kostenloses Werkzeug, den Actions Importer. Es übersetzt GitLab-Pipelines in Workflows, kann das als Trockenlauf, und es prognostiziert sogar den künftigen Verbrauch. Was es nicht kann, ist der Rest – und der ist die Arbeit: Secrets neu ordnen, Rechte über OIDC statt über hinterlegte Schlüssel vergeben, Freigaben und Vier-Augen-Regeln nachbauen, selbstverwaltete Runner ersetzen oder umziehen, und am Ende beweisen, dass der Rückweg noch funktioniert. Wenn Sie nur die Übersetzung brauchen, verweise ich Sie auf das Werkzeug und schreibe keine Rechnung.
Abgerechnet wird nach Aufwand, Bestandsaufnahme und Zielbild als abgegrenztes Zwei- bis Vier-Wochen-Mandat. Die Größenordnung nenne ich im Erstgespräch, sobald klar ist, wie viele Dienste ausgeliefert werden und wie die Freigaben aussehen. Anders als bei den Upgrade-Seiten gibt es hier bewusst kein Festpreispaket: Zwischen „wir haben keine Pipeline" und „wir haben eine, aber niemand traut ihr" liegt zu unterschiedliche Arbeit, um sie in eine Lieferung zu pressen.
Nein, und das ist eine Festlegung, keine Kapazitätsfrage. Eine Auslieferungsstrecke, die von einem Externen betrieben wird, macht genau das Wissen extern, das im Zweifelsfall am Freitagabend intern gebraucht wird. Ich baue sie auf, probe sie mit Ihnen und übergebe sie. Was danach bleibt, sind Fragen, nicht Zuständigkeiten.
Meistens nicht am Anfang. Sie sind richtig, wenn Läufe in ein privates Netz müssen, wenn Sie große Caches oder besondere Hardware brauchen, oder wenn der Verbrauch so hoch ist, dass sich der Betrieb rechnet. Sie sind falsch als erste Antwort auf lange Laufzeiten: Die liegen fast immer an doppelten Bauschritten und wirkungslosen Caches, und ein eigener Runner macht denselben Umweg nur auf eigener Hardware. Dazu kommt, dass ein selbstverwalteter Runner die Sicherheitsfrage verschärft – er hält Zugänge und überlebt den Lauf.
Keine. Die neue Strecke entsteht neben der alten und wird an einem echten Dienst zweimal durchgespielt, bevor umgeschaltet wird. Bis dahin ist der alte Weg der gültige. Das ist dieselbe Vorgehensweise wie bei einer Migration: zwei Wege parallel, Vergleich, dann Abschaltung.
Ja, und meistens wird es dabei besser dokumentiert als vorher. Freigaben sitzen in beiden Systemen als Umgebung mit Genehmigern, und weil jeder Lauf protokolliert ist, entsteht die Nachweiskette von selbst: wer hat was freigegeben, welches Artefakt ging in Produktion, aus welchem Commit stammt es. Artifact Attestations machen den letzten Punkt kryptografisch prüfbar statt nur behauptet.
In einem Projekt mit mir ja – dort entstehen Tests, Pipeline und Infrastruktur mit, nicht danach. Diese Seite ist für den anderen Fall: Das System läuft, das Team ist da, und nur die Strecke in Produktion ist der Teil, dem niemand traut. Dann braucht es keine Backend-Entwicklung, sondern zwei bis vier Wochen an genau dieser Stelle.
Weitere Leistungen
Backends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahrenWenn die AWS-Umgebung nur noch per Hand administrierbar ist: Bestand erfassen und importieren, State sauber aufbauen, Drift beseitigen, reproduzierbare Umgebungen.
Mehr erfahrenDamit ein einzelner Fehler nicht die ganze Anwendung mitnimmt: Abhängigkeiten und Single Points of Failure gefunden, Wiederanlauf geprobt statt dokumentiert, Änderungen als Terraform.
Mehr erfahren