Abhängigkeiten, Caches und Artefakte

Abhängigkeiten, Caches und Artefakte

0:00 Willkommen zum zweiten Tag. Gestern haben wir eine Pipeline gebaut, die läuft. Heute machen wir daraus eine, die liefert. Der Einstieg ist ein Thema, das oft in einen Topf geworfen wird und in zwei gehört: Caches und Artefakte. Beide speichern Dateien zwischen Jobs, aber sie haben gegensätzliche Zusagen. Ein Cache darf jederzeit fehlen, ohne dass etwas kaputtgeht — das ist seine Definition.

0:24 Ein Artefakt muss ankommen, sonst scheitert der nachfolgende Job zu Recht. Wer beides verwechselt, baut eine Pipeline, die meistens funktioniert — und das ist in der Automatisierung das schlechteste aller Ergebnisse.

Abhängigkeiten, Caches und Artefakte

0:38 Der zweite Tag dreht sich um professionelle Build- und Delivery-Pipelines. Wir beginnen mit Caches und Artefakten, gehen dann zu Tests und Qualitätsprüfungen, bauen Container-Images und Releases, lagern wiederkehrende Teile in wiederverwendbare Bausteine aus und entwickeln zum Abschluss eine eigene Action. Am Ende des Tages produziert die Beetkarte ein veröffentlichtes Image aus einer Pipeline, die sich in anderen Projekten wiederverwenden lässt.

Abhängigkeiten reproduzierbar installieren und cachen

1:03 Beginnen wir mit dem größten vermeidbaren Zeitfresser in fast jeder Pipeline: dem Installieren der Abhängigkeiten, das bei jedem Lauf von vorn beginnt. Ein Cache ist eine Abkürzung, kein Transportweg. Er verwahrt ein Verzeichnis zwischen Läufen, und ob Sie ihn wiederfinden, entscheidet der Schlüssel. Gibt es keinen exakten Treffer, kommen die Wiederherstellungsschlüssel ins Spiel: Sie suchen nach der jüngsten teilweisen Übereinstimmung.

1:29 Denken Sie an ein Regal im Baumarkt — beim genauen Artikel greifen Sie direkt zu, sonst nehmen Sie das Ähnlichste aus derselben Reihe. Und die wichtigste Regel: Ein fehlender Cache darf niemals einen Lauf scheitern lassen. Er macht ihn langsamer, mehr nicht. Das Muster ist überall gleich, egal ob npm, Maven oder Gradle. Der Schlüssel enthält einen Hash der Sperrdatei — und das ist der Kern der Sache: Ändern sich die Abhängigkeiten, ändert sich der Hash, und der alte Cache wird nicht mehr getroffen.

1:58 Genau so soll es sein, denn sonst arbeiten Sie ewig mit veralteten Ständen weiter. Der Wiederherstellungsschlüssel darunter greift, wenn der exakte Treffer fehlt — dann bekommen Sie wenigstens die meisten Pakete und laden nur die Differenz nach. Und in einer Matrix gehört das Betriebssystem in den Schlüssel, sonst überschreiben sich die Läufe.

2:18 Diese Tabelle ist die wichtigste des Moduls. Sehen Sie sich vor allem die zweite Zeile an: Ein Cache darf fehlen, ein Artefakt muss da sein. Alles andere folgt daraus. Zwei Zahlen zum Merken: Caches verschwinden, wenn sieben Tage niemand auf sie zugegriffen hat, und pro Repository stehen standardmäßig zehn Gigabyte zur Verfügung.

2:37 Ist das Kontingent voll, löscht GitHub die am längsten ungenutzten zuerst — Sie müssen also nicht aufräumen, sollten aber wissen, dass Ihr Cache jederzeit verschwinden kann, ohne dass jemand etwas getan hätte. Die ersten beiden Punkte sind die zwei Extreme desselben Fehlers: Enthält der Schlüssel den Hash nicht, bekommen Sie ewig alte Stände; ist er bei jedem Lauf neu, gibt es nie einen Treffer und der Cache kostet nur Zeit.

3:01 Der dritte ist bei Node besonders relevant — wer das Modulverzeichnis statt des Paketmanager-Verzeichnisses cacht, transportiert plattformabhängige Binärdateien zwischen Systemen, und das geht schief. Und der vierte ist der grundsätzliche: Sobald der Lauf ohne Cache scheitert, ist es kein Cache mehr, sondern eine unausgesprochene Abhängigkeit.

Artefakte zwischen Jobs übertragen

3:20 Jetzt der andere Weg — der, bei dem die Zusage gilt. Artefakte sind der Transportweg für alles, was zwischen Jobs oder über den Lauf hinaus erhalten bleiben soll. Ein Artefakt ist ein Satz Dateien, den ein Job hochlädt und ein anderer Job desselben Laufs wieder herunterlädt — oder ein Mensch, Tage später, aus der Oberfläche.

3:41 Damit lösen wir das Problem aus Modul eins: Der Build erzeugt genau ein Paket, und alle folgenden Prüfungen arbeiten auf diesem Paket. Erst dadurch bekommt der Satz "einmal bauen, überall ausrollen" eine technische Grundlage. Ohne Artefakte müsste jeder Job neu bauen — und würde damit etwas anderes prüfen als das, was am Ende ausgeliefert wird.

4:01 Zwei Schritte, ein Name — mehr braucht es nicht. Interessant ist die Aufbewahrungszeit: Die Voreinstellung liegt bei neunzig Tagen, und die brauchen Prüfartefakte fast nie. Wenn Sie bei jedem Pull Request ein Bundle ablegen, summiert sich das erstaunlich schnell zu echtem Speicherverbrauch. Sieben Tage reichen für den Zweck, den das Artefakt hier hat.

4:21 Bei einem Release-Artefakt sieht die Rechnung anders aus. Der zweite Schritt läuft im Testjob und lädt genau die Dateien, die der Build erzeugt hat — nicht neu gebaute, sondern dieselben. Vier Kandidaten, und der letzte Punkt ist der wichtigste, weil er begrenzt. Das gebaute Bundle lohnt sich immer, denn es sichert die Identität zwischen Prüfung und Auslieferung.

4:43 Testberichte und Coverage-Daten lohnen sich, weil sie ein rotes Ergebnis später belegbar machen — auch wenn das Log längst abgelaufen ist. Screenshots gescheiterter Oberflächentests sparen Ihnen viel Raten. Aber alles, was schneller neu gebaut als übertragen ist, gehört nicht dazu: Hoch- und Herunterladen kosten Zeit, und bei großen Dateien kann das den Gewinn auffressen.

5:05 Der erste Punkt ist ein echter Sicherheitsvorfall im Kleinen: Wer ein ganzes Verzeichnis hochlädt, lädt womöglich die Umgebungsdatei mit — und Artefakte kann jeder herunterladen, der das Repository lesen darf. Der zweite trifft alle, die Matrix und Artefakte kombinieren: Gleiche Namen führen zu Konflikten, der Name braucht die Kombination. Der dritte ist eine Frage der Größe.

5:27 Und der vierte macht die ganze Übung sinnlos — wenn der Deployment-Job doch wieder neu baut, war der Transport umsonst.

Risiken, Laufzeiten und Kosten

5:34 Bleiben zwei Themen, die selten zusammen genannt werden und doch zusammengehören: Was ein Cache mit Sicherheit zu tun hat — und wo die Laufzeit tatsächlich hängt. Jetzt ein Punkt, der überrascht: Caches sind über Branchgrenzen hinweg lesbar. Ein Lauf sieht die Caches seines Elternbranches. Das ist praktisch, hat aber eine unangenehme Kehrseite.

5:54 Wer auf einem beliebigen Nebenbranch einen Cache mit passendem Schlüssel erzeugt, kann dessen Inhalt in spätere Läufe der Hauptlinie tragen — Cache Poisoning nennt sich das. Der Cache ist eben beschreibbarer Speicher, den ein Pull Request befüllen kann. Deshalb gilt: Aus einem Cache wird wiederhergestellt, was schnell sein soll, nicht was ungeprüft ausgeführt wird.

6:16 Vier Beobachtungen, und die erste zählt am meisten: Wartezeit auf einen freien Runner fühlt sich für das Team an wie Laufzeit, taucht aber in keiner Messung des Jobs auf. Der zweite Punkt ist der häufigste vermeidbare Anteil — Installation von Abhängigkeiten, genau das Thema dieses Moduls. Der dritte ist ein Denkfehler beim Optimieren: Ein serieller Job in der Mitte macht jede Parallelität davor wertlos.

6:39 Und der vierte gilt für die Matrix: Nicht der Durchschnitt bestimmt das Ergebnis, sondern der langsamste Job. Der rote Faden dieser fünf Schritte ist: messen, nicht raten. Erst die Laufzeit je Job aus der Ansicht ablesen — Sie werden überrascht sein, wo die Zeit tatsächlich liegt. Dann den größten Posten angehen, nicht den, der am meisten stört. Cache einführen und den Treffer im Log nachweisen, denn ein eingerichteter Cache ist noch kein wirksamer.

7:06 Unnötige Läufe abstellen — das ist die Verbindung zu Modul drei und fünf. Und dann erneut messen. Ohne Vorher-Nachher-Zahl bleibt jede Optimierung eine Behauptung, die im nächsten Meeting niemand belegen kann. Der erste Punkt greift das Sicherheitsthema wieder auf: Was aus einem Cache kommt, sollte man nicht ungeprüft ausführen.

7:26 Der zweite passiert leicht, wenn im gecachten Verzeichnis auch Konfigurationsdateien liegen — die überdauern dann den Lauf. Der dritte ist der ehrlichste: Eine Pipeline lässt sich immer beschleunigen, indem man weniger prüft; das ist aber keine Optimierung, sondern eine Kürzung. Und der vierte begegnet uns in Modul sechzehn wieder — Kosten fallen typischerweise erst auf, wenn das Kontingent aufgebraucht ist und plötzlich nichts mehr läuft.

Übung

7:51 In der Übung richten Sie beides ein — und weisen für beides nach, dass es tut, was es soll. Der interessanteste Teil ist der Lauf mit geleertem Cache. Drei Nachweise, und jeder prüft etwas anderes. Der Cache-Treffer im Log zeigt, dass die Beschleunigung tatsächlich greift — viele Pipelines haben einen Cache, der nie trifft.

8:11 Der Testjob auf dem hochgeladenen Bundle zeigt, dass geprüft wird, was gebaut wurde. Und der dritte Nachweis ist der wichtigste: Ein Lauf mit geleertem Cache muss weiterhin grün durchlaufen. Sobald das nicht mehr stimmt, ist aus der Abkürzung eine Abhängigkeit geworden. Zur Vertiefung legen Sie den Coverage-Bericht als Artefakt ab — mit einer bewussten Entscheidung zur Aufbewahrungszeit.

8:35 Die ersten drei Schritte gehören zum Cache, die letzten beiden zum Artefakt. Achten Sie im dritten Schritt darauf, die eingesparte Zeit tatsächlich zu notieren — das ist die Zahl, mit der Sie später begründen, warum sich der Aufwand gelohnt hat. Beim Artefakt ist der fünfte Schritt der, den man gern überspringt: einmal in das hochgeladene Paket hineinsehen.

8:55 Es ist erstaunlich, was da manchmal mitreist — Umgebungsdateien, Zugangsdaten aus lokalen Tests, ganze Modulverzeichnisse. Der erste Punkt ist die häufigste Nachlässigkeit: Der Cache-Treffer wird angenommen statt geprüft. Der zweite ist eine Größenfrage — ein Artefakt mit dem kompletten Modulverzeichnis kann größer sein als die gesamte Anwendung.

9:16 Der dritte macht die Kette kaputt, weil im Testjob doch wieder gebaut wird. Und der vierte ist eine Kostenfalle, die schleichend wächst: Die Voreinstellung für die Aufbewahrung bleibt stehen, obwohl täglich mehrere Artefakte anfallen. Im nächsten Modul füllen wir diese Pipeline dann mit echten Prüfungen.