Jobs parallelisieren und Build-Zeiten optimieren

Jobs parallelisieren und Build-Zeiten optimieren

0:00 Zum Abschluss des ersten Tages die Frage, die über die Akzeptanz einer Pipeline entscheidet: Wie lange dauert sie? Eine Pipeline, auf die niemand wartet, wird benutzt. Eine, die zwanzig Minuten braucht, wird umgangen — dann laufen Prüfungen eben nur noch vor dem Release, und der ganze Zweck ist dahin. Wir sehen uns drei Ebenen der Nebenläufigkeit an: Jobs, die ohnehin parallel laufen, Matrix Builds, die aus einem Job viele machen, und seit Juni 2026 auch Schritte, die innerhalb eines Jobs nebeneinander laufen.

0:31 Dazu die Gegenrichtung: Concurrency Groups, die Läufe bewusst bremsen, wo Parallelität schadet.

Jobs parallelisieren und Build-Zeiten optimieren

0:37 Letztes Modul des ersten Tages. Wir gehen von grob nach fein: erst die Abhängigkeiten zwischen Jobs und die Matrix, dann die Steuerung gleichzeitiger Läufe, zuletzt die parallelen Schritte innerhalb eines Jobs. Am Ende prüfen Sie die Beetkarte über mehrere Node-Versionen und Betriebssysteme — und messen, ob es tatsächlich schneller geworden ist.

Abhängigkeiten und Matrix Builds

0:57 Beginnen wir mit der Ebene, die Ihnen GitHub geschenkt hat: Jobs laufen von sich aus gleichzeitig. Die Kunst besteht darin, nur dort zu bremsen, wo es wirklich nötig ist. Die Voreinstellung ist Parallelität — Jobs laufen gleichzeitig, bis Sie etwas anderes sagen. Erst wenn ein Job einen anderen als Abhängigkeit führt, wartet er, und dann sieht er auch dessen Ausgaben, wie wir im letzten Modul gesehen haben.

1:21 Die Matrix geht in die andere Richtung: Aus Wertelisten erzeugt sie automatisch je eine Kombination — dieselbe Prüfung über drei Node-Versionen und zwei Betriebssysteme, das sind sechs Jobs aus einem Block YAML. Denken Sie an eine Tabelle mit Zeilen und Spalten: Jedes Feld wird zu einem eigenen Lauf auf einer eigenen Maschine.

1:40 Drei Listen, zwei Ausnahmen, vier gleichzeitige Jobs — hier steckt viel Steuerung in wenigen Zeilen. Zwei Entscheidungen lohnen einen Blick. Die eine schaltet das schnelle Abbrechen ab: Standardmäßig reißt der erste rote Job alle anderen mit, und Sie erfahren nie, ob der Fehler nur eine Kombination betrifft oder alle. Für eine Übersicht wollen Sie das ausschalten, für schnelles Feedback anlassen.

2:02 Die andere begrenzt, wie viele Jobs gleichzeitig laufen — sinnvoll, wenn Sie sich die Runner mit anderen Teams teilen und nicht die ganze Warteschlange belegen wollen. Vier Schalter, und jeder beantwortet eine andere Frage. Die ersten beiden formen die Menge der Kombinationen: Der eine ergänzt Sonderfälle — etwa eine Kombination mit einem zusätzlichen Flag —, der andere entfernt Paarungen, die keinen Erkenntnisgewinn bringen.

2:27 Die letzten beiden steuern das Verhalten. Merken Sie sich vor allem die Voreinstellung beim Abbruchverhalten: Sie steht auf aktiv. Wer eine vollständige Fehlerübersicht will, muss das ausdrücklich abschalten — sonst sehen Sie immer nur den ersten Fehler und rätseln über den Rest. Der erste Punkt ist eine Multiplikation, die schnell außer Kontrolle gerät: Drei Listen zu je vier Werten sind vierundsechzig Jobs — und wenn jeder davon fünf Minuten braucht, verbrennen Sie über fünf Stunden Rechenzeit für einen Commit.

2:56 Der zweite ist das eben besprochene Abbruchverhalten. Der dritte ist eine unschöne Wechselwirkung mit dem nächsten Modul: Wenn der Cache-Schlüssel die Kombination nicht enthält, überschreiben sich die Jobs gegenseitig. Und der vierte trifft alle, die Bedingungen und Abhängigkeiten mischen: Ein Job wartet auf einen, der bei diesem Ereignis gar nicht startet.

Nebenläufigkeit steuern

3:15 Jetzt die Gegenrichtung. Es gibt Stellen, an denen zwei gleichzeitige Läufe nicht doppelt so schnell, sondern doppelt so gefährlich sind — vor allem beim Ausrollen. Eine Concurrency Group ist ein Namensschild, das Sie an Läufe oder Jobs hängen. Alle mit demselben Schild bilden eine Gruppe, und in der Gruppe ist immer nur einer aktiv.

3:35 Was mit dem Rest passiert, entscheiden Sie: Entweder der neue bricht den alten ab, oder die weiteren stellen sich in eine Warteschlange. Und wenn Sie nichts davon sagen, wird ein zweiter Lauf schlicht abgewiesen. Das ist einer der wenigen Mechanismen, die man wirklich verstehen muss, bevor man sie einsetzt — die falsche Wahl fällt erst im Ernstfall auf.

3:55 Zwei Konfigurationen, die auf den ersten Blick ähnlich aussehen und genau gegenteilige Absichten haben. Oben: der Prüflauf am Branch. Wenn Sie dreimal hintereinander pushen, interessiert nur der letzte Stand — die Vorgänger dürfen abgebrochen werden, das spart Zeit und Kapazität. Unten: das Deployment auf die Produktion. Hier wäre ein Abbruch verheerend, weil eine halb ausgerollte Umgebung schlimmer ist als eine, die noch wartet.

4:22 Deshalb reihen sich weitere Läufe hier ein. Achten Sie auf den Schlüssel der Gruppe: Oben enthält er den Branch, unten bewusst nicht. Die Faustregel ist einfach: Alles, was nur informiert, darf abgebrochen werden. Alles, was etwas verändert, nicht. Prüfläufe informieren — der vorletzte Stand ist uninteressant. Deployments verändern, und ein abgebrochenes Deployment hinterlässt einen Zustand, den kein Lauf beschreibt.

4:47 Dazu gehört ein Zeitlimit je Job, sonst blockiert ein hängender Lauf die ganze Gruppe auf unbestimmte Zeit. Und der Gruppenschlüssel entscheidet über alles: Zu grob gefasst blockieren sich unbeteiligte Läufe gegenseitig, zu fein gefasst schützt die Gruppe niemanden. Der erste Punkt ist besonders ärgerlich, weil er unsichtbar bleibt: Wenn der Schlüssel etwas enthält, das je Lauf eindeutig ist — etwa die Laufnummer —, ist jede Gruppe einelementig, und der Mechanismus wirkt nie.

5:16 Der zweite ist der gefährlichste dieses Moduls: Das Abbrechen steht am Deployment und zerreißt ein laufendes Ausrollen. Der dritte betrifft das fehlende Zeitlimit. Und der vierte ist eine Denkfalle: Die Gruppe wird pro Workflow gebildet, obwohl zwei verschiedene Workflows dieselbe Umgebung anfassen — dann schützt sie genau vor dem Fall nicht, für den sie gedacht war.

Parallele Schritte im Job

5:36 Und jetzt zu etwas, das noch recht neu ist. Bis Mitte 2026 galt: Schritte laufen streng der Reihe nach. Seitdem gibt es auch hier Nebenläufigkeit. Seit Juni 2026 können Schritte innerhalb eines Jobs nebeneinander laufen. Fünf Schlüsselwörter regeln das: Einer startet einen Schritt und geht sofort weiter, zwei warten auf benannte oder auf alle Hintergrundschritte, einer beendet einen laufenden geordnet, und einer führt eine ganze Gruppe gemeinsam aus.

6:05 Der praktisch wichtigste Fall ist der Hintergrunddienst: Sie starten eine Datenbank oder einen Testserver, führen die abhängige Arbeit aus und räumen danach sauber ab — alles in einem Job, ohne den Umweg über einen zweiten. Diese vier Ebenen zusammen sind Ihr Werkzeugkasten für Laufzeit. Ganz oben regeln Sie, wie viele Läufe gleichzeitig existieren dürfen.

6:26 Darunter laufen Jobs von selbst parallel, solange keine Abhängigkeit sie ordnet. Die Matrix vervielfacht einen Job. Und seit 2026 kommt die unterste Ebene dazu. Wichtig ist die Reihenfolge beim Optimieren: Fangen Sie oben an. Ein Job, der gar nicht hätte laufen müssen, ist die billigste Einsparung überhaupt — deutlich billiger als jede Parallelisierung innerhalb eines Jobs.

6:50 Die Tabelle zeigt, wofür die fünf Schlüssel im Alltag taugen. Der typische Ablauf: Dienst im Hintergrund starten, warten bis er nutzbar ist, Test laufen lassen, Dienst beenden. Achten Sie auf einen Punkt in der Fußzeile, der beim Debuggen wichtig wird: Die Ausgabe eines Hintergrundschritts erscheint erst, wenn er abgeschlossen ist.

7:09 Sie sehen also während des Laufs nicht, was dieser Schritt gerade tut — was die Fehlersuche bei einem hängenden Dienst unangenehm macht. Planen Sie deshalb eine Bereitschaftsprüfung ein, statt sich auf das Log zu verlassen. Der erste und der zweite Punkt gehören zusammen und sind die häufigsten Fehler bei Hintergrunddiensten: Der Dienst wird nie beendet, und der Job läuft in sein Zeitlimit — oder der Test beginnt, bevor der Dienst bereit ist.

7:34 Denn gestartet heißt nicht betriebsbereit; darauf müssen Sie ausdrücklich warten. Der dritte betrifft geteilte Ressourcen: Parallele Schritte laufen im selben Verzeichnis und auf denselben Ports. Und der vierte ist eine Nebenwirkung des Erfolgs — wenn alles parallel läuft, ist schwerer zu erkennen, welcher Schritt die Laufzeit eigentlich bestimmt.

Übung

7:53 In der Übung wird die Beetkarte breiter geprüft und trotzdem nicht langsamer. Wichtig dabei: Wir messen vorher und nachher — ohne Zahlen ist jede Optimierung nur ein Gefühl. Der Zusatz im Titel ist der eigentliche Anspruch. Eine Pipeline schneller zu machen, indem man Prüfungen weglässt, kann jeder. Hier geht es darum, mehr zu prüfen — drei Node-Versionen, zwei Betriebssysteme — und dabei nicht länger zu brauchen.

8:19 Dazu kommt eine begründete Ausnahme in der Matrix: Nicht jede Kombination trägt Erkenntnis, und die Entscheidung sollen Sie benennen können. Und die Concurrency Group, damit ein neuer Push den Vorgänger desselben Branches abbricht. Notieren Sie die Laufzeit vor der Änderung — sonst fehlt Ihnen am Ende der Vergleich. Die vier Eingriffe bauen aufeinander auf. Erst die Matrix, dann die Ausnahme mit Begründung — schreiben Sie die tatsächlich auf, das ist Teil der Übung.

8:46 Dann das Abbruchverhalten abschalten, damit alle Kombinationen ihr Ergebnis melden; sonst sehen Sie beim ersten roten Job den Rest gar nicht. Und zum Schluss die Concurrency Group je Branch. Der Zusatz mit dem Zeitlimit ist keine Nebensache: Ohne ihn kann ein einzelner hängender Job Ihre gerade eingerichtete Gruppe für Stunden blockieren.

9:06 Der erste Punkt ist die Ironie dieser Übung: Eine zu breite Matrix macht die Pipeline langsamer, weil die Wartezeit auf freie Runner steigt — mehr Parallelität ist nicht automatisch mehr Tempo. Der zweite trifft Sie erst später: Wenn eine Prüfung als Voraussetzung für den Merge hinterlegt ist, ändert die Matrix möglicherweise deren Namen.

9:25 Der dritte ist ein Versehen mit Folgen — die Gruppe umfasst den Deployment-Workflow gleich mit. Und der vierte ist der ehrlichste: Wenn die Laufzeit sinkt, weil etwas nicht mehr geprüft wird, haben Sie nichts gewonnen. Morgen geht es weiter mit Caches und Artefakten.