Wohin mit deinem Build? Das fehlende Glied zwischen Code und Produktion

Du hast gerade deine Anwendung gebaut. Der Build war erfolgreich, die Tests liefen durch, und jetzt liegt ein glänzendes neues Artefakt in einem Ordner auf deinem Laptop. Und jetzt?

Wenn du wie die meisten Teams bist, die ihre erste Pipeline aufsetzen, liegt der nächste Schritt nahe: ausrollen. Aber es gibt ein Problem, das direkt vor der Nase liegt. Dieses Artefakt auf deinem Laptop ist für den Produktionsserver in einem Rechenzentrum oder einer Cloud-Region völlig nutzlos. Er kann nicht in deinen lokalen Ordner greifen und die Datei holen. Selbst wenn der Build auf einer dedizierten CI-Maschine lief, kann das Deployment-Ziel nicht auf Dateien zugreifen, die auf der lokalen Festplatte dieser Maschine liegen.

Hier trifft das meiste Pipeline-Design auf seine erste echte Hürde. Du brauchst einen Ort, an dem du das Artefakt ablegen kannst, den sowohl der Build-Prozess als auch das Deployment-Ziel erreichen können.

Das Problem des gemeinsamen Speichers

Stell dir vor, du kochst für eine Party. Du lässt das Essen nicht in der Küche und erwartest, dass die Gäste hereinkommen und sich vom Herd bedienen. Du stellst das Essen auf einen Tisch, den jeder erreichen kann.

Mit Artefakten ist es genauso. Der Build-Prozess erstellt das Artefakt. Der Deployment-Prozess muss es abrufen. Diese beiden Prozesse können auf verschiedenen Maschinen, in verschiedenen Netzwerken und zu verschiedenen Zeiten laufen. Sie brauchen einen gemeinsamen Ort, auf den beide über das Netzwerk zugreifen können.

Dieser gemeinsame Ort heißt Artifact Registry oder Artefakt-Repository. Seine Aufgabe ist einfach: Artefakte speichern und eine Möglichkeit bieten, sie abzurufen. Jedes Mal, wenn ein Build fertig ist, schiebt er das Artefakt in diese Registry. Später, wenn ein Deployment startet, zieht der Zielserver das Artefakt aus der Registry und führt es aus.

Das folgende Diagramm zeigt den grundlegenden Ablauf:

So schiebst du ein Artefakt nach einem Build und ziehst es auf einem Deployment-Ziel:

# Auf der Build-Maschine: Artefakt in die Registry schieben
curl -X POST \
  -F "file=@myapp-v1.2.3.jar" \
  https://registry.example.com/upload

# Auf dem Deployment-Ziel: Artefakt aus der Registry ziehen
curl -O https://registry.example.com/artifacts/myapp-v1.2.3.jar
flowchart TD A[Build-Maschine] -->|Artefakt schieben| B[Artifact Registry] B -->|Artefakt ziehen| C[Deployment-Ziel] D[Anderes Netzwerk] -.-> A E[Anderes Netzwerk] -.-> C F[Anderer Zeitpunkt] -.-> A G[Anderer Zeitpunkt] -.-> C

Mehr als nur ein Dateiserver

Eine Registry macht mehr, als nur Dateien zu speichern. Sie bewahrt auch Metadaten zu jedem Artefakt auf: Versionsnummer, Erstellungszeitstempel und oft den Git-Commit-Hash, der es erzeugt hat. Diese Metadaten werden kritisch, wenn in der Produktion etwas schiefgeht.

Stell dir vor, du rollst Version 2.3.1 aus und Benutzer sehen Fehler. Du musst genau wissen, welche Code-Änderungen in dieses Artefakt eingeflossen sind. Ohne Metadaten, die das Artefakt mit seinem Quell-Commit verknüpfen, rätst du nur. Damit kannst du den Diff prüfen, das Problem identifizieren und entscheiden, ob du zurückrollen oder vorwärts reparieren solltest.

Manche Registries unterstützen auch Labels oder Tags. Du könntest ein Artefakt als "staging-validiert" taggen, nachdem es die Integrationstests bestanden hat, oder als "produktionsbereit" nach einer manuellen Freigabe. Diese Tags helfen dabei zu automatisieren, welche Artefakte in welche Umgebung ausgerollt werden.

Die Konnektivitätsfalle

Hier ist ein Fehler, der viele Teams erwischt: Sie richten eine Registry in der Cloud ein, aber ihre Produktionsserver laufen in einem privaten Netzwerk, das keinen Zugang zum öffentlichen Internet hat. Der Build schiebt die Artefakte erfolgreich, aber wenn das Deployment sie ziehen will, schlägt es mit einem Connection Timeout fehl.

Die Registry muss von jedem Server erreichbar sein, der deployen muss. Wenn deine Produktionsumgebung isoliert ist, muss deine Registry in demselben Netzwerk sein, oder du brauchst einen Mechanismus, um Artefakte über Netzwerkgrenzen hinweg zu synchronisieren. Manche Teams betreiben einen lokalen Proxy oder Mirror, der Artefakte aus einer zentralen Registry zwischenspeichert. Andere nutzen eine Registry, die private Netzwerkendpunkte unterstützt.

Das klingt offensichtlich, wenn du es liest, aber es ist leicht zu übersehen, wenn du dich darauf konzentrierst, die Pipeline durchgängig zum Laufen zu bringen. Prüfe die Konnektivität, bevor du deinen gesamten Deployment-Prozess um eine Registry herum aufbaust, die deine Server nicht erreichen können.

Unveränderlichkeit ist wichtig

Eine gute Registry verhindert, dass Artefakte nach dem Speichern verändert werden. Diese Eigenschaft heißt Unveränderlichkeit (Immutability). Sie bedeutet, dass das heute gespeicherte Artefakt mit dem identisch ist, das du in sechs Monaten abrufst.

Warum ist das wichtig? Ohne Unveränderlichkeit kannst du nicht vertrauen, was du ausrollst. Jemand könnte ein Artefakt verändern, nachdem es die Tests bestanden hat. Ein Fehler, der im Staging abgefangen wurde, könnte in der Produktion wieder auftauchen, weil sich das Artefakt zwischen den Umgebungen geändert hat. Das Debuggen wird zum Albtraum, weil du nie sicher bist, ob das in der Produktion laufende Artefakt dem getesteten entspricht.

Unveränderlichkeit erzwingt einen sauberen Workflow: Jede Änderung erzeugt ein neues Artefakt mit einer neuen Version. Es gibt kein "Aktualisieren an Ort und Stelle" für Artefakte. Wenn du etwas reparieren musst, baust du neu und erstellst eine neue Version. Diese Disziplin macht Deployments vorhersagbar und Rollbacks einfach.

Build und Deployment entkoppeln

Mit einer Registry an Ort und Stelle werden Build und Deployment zu zwei getrennten Prozessen, die unabhängig voneinander laufen können. Der Build wird fertig, schiebt das Artefakt und macht weiter. Das Deployment kann Minuten, Stunden oder Tage später stattfinden. Das Artefakt liegt sicher in der Registry und wartet darauf, abgerufen zu werden.

Diese Entkopplung ist mächtig. Du kannst ein Artefakt morgens bauen und testen, es nachmittags von einem Senior Engineer prüfen lassen und es nachts in die Produktion ausrollen, wenn der Traffic niedrig ist. Jeder Schritt erfolgt nach seinem eigenen Zeitplan, aber alle beziehen sich auf dasselbe unveränderliche Artefakt.

Es bedeutet auch, dass du dasselbe Artefakt in mehreren Umgebungen neu ausrollen kannst. Das Artefakt, das die Staging-Tests bestanden hat, ist genau dasselbe Artefakt, das in die Produktion geht. Keine Neukompilierung, keine umgebungsspezifischen Builds, keine "bei mir hat's funktioniert"-Überraschungen.

Eine kurze praktische Checkliste

Wenn du deine Artifact Registry einrichtest, überprüfe diese Punkte:

  • Erreichbarkeit: Kann jeder Server, der deployen muss, die Registry über das Netzwerk erreichen?
  • Unveränderlichkeit: Verhindert die Registry die Änderung gespeicherter Artefakte?
  • Metadaten: Trägt jedes Artefakt Versionsnummer, Zeitstempel und Quell-Commit-Informationen?
  • Aufbewahrung: Wie lange behältst du alte Artefakte? Hast du eine Bereinigungsrichtlinie?
  • Authentifizierung: Wer kann Artefakte schieben? Wer kann sie ziehen? Werden Anmeldedaten rotiert?

Das Fazit

Dein Build-Output braucht ein Zuhause, das sowohl der Build-Prozess als auch die Deployment-Ziele erreichen können. Eine Artifact Registry bietet diesen gemeinsamen Speicher, bewahrt Metadaten für die Rückverfolgbarkeit, erzwingt Unveränderlichkeit, damit du dem Ausgerollten vertrauen kannst, und entkoppelt Build von Deployment, sodass jeder Schritt in seinem eigenen Tempo erfolgen kann. Ohne sie ist deine Pipeline nur ein Build, der mit einer Datei auf einer Maschine endet, die niemand erreichen kann.