4-5 · Kapitel 4 · 5 Min. Lesezeit

Warum Ihre Pipeline eine durchdachte Artefakt-Speicherstrategie braucht

Erfahren Sie, warum eine durchdachte Artefakt-Speicherstrategie für CI/CD-Pipelines entscheidend ist – von Versionierung über Metadaten bis zur Deployment-Sicherheit.

Warum Ihre Pipeline eine durchdachte Artefakt-Speicherstrategie braucht

Sie haben gerade Ihre Anwendung gebaut. Alle Tests bestanden. Sicherheitsscans fanden nichts. Das Build-Log zeigt einen sauberen grünen Haken. Jetzt ist es Zeit für das Deployment. Aber wenn Sie das Deployment-Dashboard öffnen, stellen Sie fest, dass Sie keine Ahnung haben, welches Artefakt Sie verwenden sollen. Der Build-Server hat seinen Workspace bereits bereinigt. Der Entwickler, der den Build ausgeführt hat, ist im Urlaub. Übrig bleibt nur eine vage Erinnerung, dass „der Build erfolgreich war“.

Dieses Szenario ist häufiger, als die meisten Teams zugeben. Der Build funktioniert, aber das Artefakt verschwindet. Oder schlimmer: Die Deployment-Pipeline baut das Artefakt in der Produktion von Grund auf neu, verwendet dabei eine andere Version einer Abhängigkeit und produziert etwas, das nie getestet wurde.

Das Problem ist nicht der Build. Das Problem ist, dass das Artefakt wie eine temporäre Datei behandelt wurde, nicht wie ein verifiziertes Deliverable, das gespeichert, gekennzeichnet und nachverfolgt werden muss.

Was Packen und Veröffentlichen eigentlich bedeuten

Wenn Ihre Pipeline Tests und Scans abgeschlossen hat, tritt sie in eine Phase ein, die viele Teams überstürzen: das Packen und Veröffentlichen. Diese beiden Schritte machen aus einem erfolgreichen Build ein wiederverwendbares Asset.

Packen ist der Prozess, Ihren verifizierten Code in ein Format zu überführen, das in Ihrer Zielumgebung ausgeführt werden kann. Das Format hängt davon ab, was Sie bauen:

Bei containerbasierten Anwendungen bedeutet Packen das Erstellen eines Container-Images.
Bei Java-Anwendungen bedeutet es die Erstellung einer JAR- oder WAR-Datei.
Bei JavaScript- oder Python-Bibliotheken bedeutet es die Erstellung eines Pakets, das npm oder pip installieren kann.
Bei Infrastruktur kann es die Generierung eines validierten Terraform-Moduls oder CloudFormation-Templates bedeuten.

Veröffentlichen ist der Akt, dieses gepackte Artefakt an eine Registry oder ein Repository zu senden, wo es später von Deployment-Pipelines abgerufen werden kann. Eine Registry ist nicht nur ein Storage-Bucket. Es ist ein strukturiertes System, das Ihre Artefakte organisiert, versioniert und auffindbar hält.

Hier ist ein minimales YAML-Snippet, das zeigt, wie eine CI-Pipeline ein Container-Image packt und mit einem eindeutigen Versionstag veröffentlicht:

- name: Build and tag Docker image
  run: |
    docker build -t myregistry.com/myapp:1.0.0-b20240315-a1b2c3d .

- name: Push image to registry
  run: |
    docker push myregistry.com/myapp:1.0.0-b20240315-a1b2c3d

Container-Images gehen in Container-Registries wie Docker Hub, Amazon ECR oder Harbor. Anwendungspakete gehen in Artefakt-Repositories wie Nexus, Artifactory oder GitHub Packages. Infrastruktur-Module gehen in Modul-Registries oder Git-Repositories mit ordentlichem Tagging.

Die eine Sache, die diese Phase zum Erfolg oder Misserfolg führt

Versionierung ist nicht optional. Jedes Artefakt, das Sie veröffentlichen, muss eine eindeutige, nachvollziehbare Version haben. Es geht nicht darum, semantische Versionierung zu verwenden, weil es professionell aussieht. Es geht darum, eine Frage beantworten zu können: „Was läuft genau gerade in der Produktion?“

Wenn Ihr Artefakt mit latest oder stable gekennzeichnet ist, können Sie diese Frage nicht beantworten. Diese Labels ändern sich im Laufe der Zeit. Sie sagen nichts über die darin enthaltenen Codeänderungen aus. Wenn ein Fehler in der Produktion auftritt und Sie ihn auf den Commit zurückführen müssen, der ihn eingeführt hat, gibt Ihnen ein Label wie latest null Informationen.

Ein guter Versionsstring kombiniert eine semantische Version mit Build-Metadaten. So etwas wie 1.2.3-b20240315-a1b2c3d verrät Ihnen die Release-Nummer, das Build-Datum und den Commit-Hash. Das reicht aus, um das Artefakt auf den genauen Quellcode, den genauen Build-Job und die genauen Testergebnisse zurückzuverfolgen.

Metadaten sind Ihr Sicherheitsnetz

Ein Versionsstring allein ist nützlich, aber nicht ausreichend. Jedes veröffentlichte Artefakt sollte Metadaten enthalten, die Folgendes aufzeichnen:

Den Commit-Hash, der den Build ausgelöst hat
Den Branch-Namen
Die Build-Nummer
Die Zusammenfassung der Testergebnisse
Wer den Build ausgelöst hat

Bei Container-Images werden diese Metadaten in Labels abgelegt. Bei Paketdateien werden sie im Manifest oder in einer begleitenden Metadatendatei gespeichert. Diese Metadaten verwandeln Ihr Artefakt von einer Blackbox in ein dokumentiertes Asset. Wenn jemand fragt: „Hat dieses Artefakt alle erforderlichen Tests bestanden?“, können Sie auf die Metadaten verweisen und beweisen, dass es das hat.

Warum das für die Deployment-Sicherheit wichtig ist

Sobald Ihr Artefakt gepackt, versioniert und mit Metadaten veröffentlicht ist, kann Ihre Deployment-Pipeline es mit Vertrauen abrufen. Der Deployment-Schritt wird zu einer einfachen Operation: Nimm Artefakt-Version X, deploye sie in Umgebung Y.

Ohne diese Grundlage wird das Deployment zum Ratespiel. Teams bauen Artefakte in Produktionsumgebungen neu, weil die ursprüngliche Build-Ausgabe verschwunden ist. Das Neubauen in der Produktion ist gefährlich. Der Build könnte eine andere Abhängigkeitsversion, einen anderen Compiler oder ein anderes Basis-Image verwenden. Das Ergebnis ist ein Artefakt, das nie getestet wurde und in einer Umgebung läuft, in der Fehler am meisten wehtun.

Ein ordnungsgemäß gespeichertes Artefakt eliminiert dieses Risiko. Das Artefakt, das alle Tests bestanden hat, ist genau dasselbe Artefakt, das deployed wird. Keine Neubauten. Keine Überraschungen.

Gängige Registry-Optionen

Sie brauchen keine teure Enterprise-Lösung, um das richtig zu machen. Wichtig ist, eine Registry zu wählen, die zu Ihrem Stack passt, und sie konsequent zu nutzen.

Container-Images: Docker Hub, Amazon ECR, Google Artifact Registry, Harbor oder jede OCI-konforme Registry.
Anwendungspakete: Nexus, Artifactory, GitHub Packages, GitLab Package Registry oder sprachspezifische Registries wie npm oder PyPI.
Infrastruktur-Module: Terraform Cloud, Git mit semantischen Tags oder eine dedizierte Modul-Registry.

Die Registry selbst ist weniger wichtig als die Art, wie Sie sie nutzen. Eine einfache Registry mit strenger Versionierung und Metadaten ist besser als eine ausgeklügelte, bei der jeder Artefakte mit zufälligen Labels pusht.

Eine kurze Checkliste für Ihre Pipeline

Wenn Sie Ihre Packaging- und Publishing-Phase einrichten oder überprüfen, gehen Sie diese Punkte durch:

Jedes Artefakt hat eine eindeutige Version, die einen Commit-Hash oder eine Build-Nummer enthält.
Kein Artefakt wird für die Produktion mit einem Label wie latest veröffentlicht.
Metadaten (Commit-Hash, Branch, Build-Nummer, Teststatus) sind an jedem veröffentlichten Artefakt angebracht.
Der Build-Server bereinigt Artefakte nicht sofort nach Build-Ende.
Die Deployment-Pipeline zieht Artefakte aus der Registry, baut sie nie neu.
Die Registry hat Aufbewahrungsrichtlinien, die das versehentliche Löschen von Produktionsartefakten verhindern.

Was als Nächstes kommt

Mit Ihrem sicher gespeicherten und nachvollziehbaren Artefakt ist der nächste Schritt das Deployment. Aber bevor Sie weitermachen, nehmen Sie sich einen Moment Zeit, um zu überprüfen, ob Ihre Registry gut genug organisiert ist, um Rollbacks zu unterstützen. Wenn Sie zu einer vorherigen Version zurückkehren müssen, können Sie das genaue Artefakt aus dem Deployment der letzten Woche finden? Wenn die Antwort nein ist, hat Ihre Speicherstrategie noch Lücken.

Ein gut gespeichertes Artefakt ist die Grundlage für wiederholbare, vertrauenswürdige Deployments. Ohne es birgt jedes Deployment ein verstecktes Risiko. Mit ihm können Sie deployen und wissen, dass das, was Sie ausführen, genau das ist, was Sie getestet haben.