Wo Ihre Builds leben: Warum jedes Artefakt ein Zuhause braucht

Stellen Sie sich vor: Ihre CI-Pipeline zeigt grün. Ein Entwickler fragt: „Welchen Build sollen wir auf Staging deployen?“ Jemand antwortet: „Den von gestern, glaube ich.“ Ein anderer mischt sich ein: „Nein, ich habe ihn heute Morgen lokal neu gebaut. Nimm meinen.“

Diese Unterhaltung kommt häufiger vor, als Teams zugeben möchten. Wenn Artefakte auf Laptops, in CI-Workspace-Ordnern oder auf geteilten Laufwerken liegen, verlieren Sie die Fähigkeit, konsistent zu wissen, was tatsächlich bereit zum Deployen ist. Staging bekommt vielleicht eine Version, Produktion eine andere, und niemand kann zurückverfolgen, welches Artefakt den Incidents um 2 Uhr morgens verursacht hat.

Die Lösung ist konzeptionell einfach, aber in der Praxis entscheidend: Sie brauchen einen einzigen, zentralen Ort, an dem jedes Build-Ergebnis lebt. In DevOps-Begriffen heißt dieser Ort Registry oder Repository Manager.

Artefakte gibt es in verschiedenen Formen

Beginnen wir mit der vertrauten Art von Artefakten: einer JAR-Datei, einem ZIP-Archiv, einer kompilierten Binärdatei oder einem NuGet-Paket. Dies sind Einzeldatei-Artefakte. Tools wie Nexus, Artifactory oder die integrierten Paketregistries Ihres Sprach-Ökosystems (npm Registry, Maven Central, PyPI) handhaben diese gut. Sie speichern die Datei, verfolgen Versionen und lassen Pipelines oder Entwickler die genaue Abhängigkeit abrufen, die sie benötigen.

Betrachten wir nun Container-Images. Ein Container-Image ist keine einzelne Datei. Es ist aus mehreren Schichten aufgebaut, die übereinander gestapelt sind. Sie können ein Container-Image nicht in einem normalen Artefakt-Repository speichern. Es braucht eine Container-Registry: Docker Hub, Amazon ECR, Google Container Registry oder Harbor. Container-Registries verstehen die Schichtstruktur. Wenn Sie ein Image pullen, sendet die Registry nur die Schichten, die auf dem Zielrechner noch nicht vorhanden sind. Das macht Deployments schneller und spart Bandbreite.

Container-Images sind in modernen CI/CD-Pipelines zum häufigsten Artefakttyp geworden. Aber das Prinzip ist unabhängig vom Format dasselbe: Die Registry ist die einzige Quelle der Wahrheit für jedes Artefakt, das Ihren Build und Ihre Tests bestanden hat.

Die Registry ist der Übergabepunkt zwischen CI und CD

Hier ist die wichtigste Funktion einer Registry in einer Pipeline: Sie markiert die Grenze zwischen Continuous Integration und Continuous Delivery.

Das folgende Diagramm stellt den korrekten Ablauf dem fehlerhaften Ablauf gegenüber, der ohne Registry entsteht.

Schauen Sie sich den Ablauf an. Die Aufgabe der CI endet in dem Moment, in dem ein Artefakt mit einem klaren Versions-Tag in der Registry landet. Der Build ist abgeschlossen. Die Tests sind bestanden. Das Artefakt ist gespeichert. Die Verantwortung der CI hört dort auf.

CD beginnt in der Registry. CD baut das Artefakt nicht neu. Es zieht genau dasselbe Artefakt, das CI gespeichert hat, und deployt es in die Zielumgebung. Keine Neukompilierung. Keine anderen Abhängigkeiten. Kein „Ich glaube, das ist derselbe Build.“

Diese Trennung ist nicht nur technisch. Es geht um Verantwortung. CI ist für die Korrektheit des Builds verantwortlich. CD ist für die Korrektheit des Deployments verantwortlich. Wenn in der Produktion etwas kaputt geht, führen Sie die Spur zurück zum genauen Artefakt in der Registry. Sie kennen seine Version, seinen Commit-Hash, seinen Build-Zeitstempel. Es gibt kein Rätselraten.

Promotion ohne Modifikation

Eine gute Registry ermöglicht auch Artefakt-Promotion. Promotion ist der Prozess, ein bestimmtes Artefakt als bereit für die nächste Umgebung zu markieren. Sie modifizieren das Artefakt selbst nicht. Sie fügen Metadaten hinzu.

Zum Beispiel produziert Ihre CI ein Artefakt mit dem Tag 1.2.3-build.45. Dieses Artefakt liegt in der Registry. Wenn es die Staging-Tests besteht, fügen Sie ein Tag hinzu: staging. Wenn es die Produktionsvalidierung besteht, fügen Sie ein weiteres Tag hinzu: production. Das zugrunde liegende Artefakt ist identisch. Nur sein Status ändert sich.

Das ist wichtig, weil es eine saubere Prüfspur hinterlässt. Sie können immer sehen, welche Version wann in welche Umgebung promoviert wurde. Ohne diesen Mechanismus bauen Teams für jede Umgebung neu und führen subtile Unterschiede zwischen dem Getesteten und dem in der Produktion laufenden Code ein.

Was passiert ohne eine Registry

Teams, die keine ordentliche Registry einrichten, stoßen immer wieder auf dieselben Probleme:

• Entwickler fragen sich gegenseitig, welchen Build sie deployen sollen.
• Staging läuft mit einer anderen Version als die Produktion.
• Rollbacks werden zum Ratespiel, weil niemand weiß, was vorher tatsächlich lief.
• Sicherheitsscans laufen auf manchen Builds, aber nicht auf anderen, weil es kein zentrales Inventar gibt.
• Compliance-Audits werden zu manuellen E-Mail-Ketten, die versuchen zu rekonstruieren, was vor sechs Monaten deployed wurde.

Eine Registry eliminiert all das. Sie ist kein Luxus. Sie ist die Grundlage, die disziplinierte Pipelines möglich macht.

Praktische Checkliste für die Einrichtung Ihrer Registry

Wenn Sie zum ersten Mal eine Registry einrichten oder Ihre aktuelle Konfiguration überprüfen, hier eine kurze Checkliste:

• Wählen Sie den richtigen Typ: Container-Registry für Images, Artefakt-Repository für Binärdateien und Pakete. Einige Tools wie Harbor oder Artifactory handhaben beides.
• Erzwingen Sie Unveränderlichkeit: Sobald ein Artefakt mit einem Versions-Tag gespeichert ist, erlauben Sie keine Überschreibungen. Ein neuer Build bekommt eine neue Version.
• Legen Sie Aufbewahrungsrichtlinien fest: Nicht jeder Build muss ewig leben. Behalten Sie die letzten N Builds oder Builds der letzten M Tage. Archivieren oder löschen Sie den Rest.
• Kontrollieren Sie den Zugriff: Pipelines sollten Schreibzugriff haben. Entwickler und CD-Pipelines sollten Lesezugriff haben. Verwenden Sie IAM-Rollen oder Tokens, keine gemeinsamen Passwörter.
• Taggen Sie Promotions explizit: Verwenden Sie Metadaten oder Tags, um zu markieren, welche Artefakte sich in Staging, Produktion oder zurückgesetzt befinden. Automatisieren Sie dies in Ihrer CD-Pipeline.

Die konkrete Erkenntnis

Eine Registry ist nicht nur Speicher. Sie ist der Vertrag zwischen Ihrem Build-Prozess und Ihrem Deployment-Prozess. Sie stellt sicher, dass das, was gebaut wurde, genau das ist, was deployed wird. Sie gibt Ihrem Team einen einzigen Ort, an den es sich wenden kann, wenn etwas schiefgeht. Sie macht Promotion nachvollziehbar und Rollbacks zuverlässig.

Richten Sie Ihre Registry ein, bevor Sie das nächste Deployment durchführen. Ihr zukünftiges Ich, das um Mitternacht einen Incident debuggt, wird es Ihnen danken.