3-3 · Kapitel 3 · 4 Min. Lesezeit

Warum jedes Artefakt einen Namen und eine Nummer braucht

Ohne klares Naming und Versionierung wird aus jedem Deployment ein Ratespiel. Erfahre, warum semantische Versionierung und Immutability die Grundlage für zuverlässige Releases sind.

Warum jedes Artefakt einen Namen und eine Nummer braucht

Dein Team baut jeden Tag Code. Bis Freitag liegen sieben verschiedene Artefakte im Repository. Niemand erinnert sich, welches getestet wurde, welches den Hotfix enthält und welches in Produktion soll. Jemand fragt: „Welchen Build deployen wir?“ – und die Antwort ist ein Achselzucken.

In diesem Moment wird klar: Artefakte ohne klare Benennung sind keine Artefakte. Sie sind nur Dateien. Ohne ein vernünftiges Namens- und Nummerierungssystem produziert deine Pipeline Rauschen statt Gewissheit.

Das Problem unbenannter Artefakte

Wenn Artefakte keine eindeutige Identität haben, wird jedes Deployment zum Ratespiel. Teams verlassen sich auf Zeitstempel, Ordnernamen oder Erinnerungen. „Ich glaube, der Build von Dienstagnachmittag hatte den Fix.“ Diese Denkweise ist gefährlich. Sie führt dazu, die falsche Version auszurollen, auf etwas zurückzusetzen, das nie getestet wurde, oder – noch schlimmer – ein kaputtes Artefakt zu deployen, weil niemand sagen konnte, welches das aktuellste war.

Das Kernproblem ist einfach: Wenn du ein Artefakt nicht eindeutig identifizieren kannst, kannst du es nicht zuverlässig deployen. Und wenn du nicht zuverlässig deployen kannst, kannst du nicht selbstbewusst releasen.

Was ein Artefakt identifizierbar macht

Jedes Artefakt braucht zwei Dinge: einen Namen und eine Nummer. Der Name sagt dir, was das Artefakt ist. Die Nummer sagt dir, welche Version davon es ist. Zusammen ergeben sie eine eindeutige Kennung, auf die sich alle im Team ohne Missverständnisse beziehen können.

Der Name ist in der Regel der Anwendungs- oder Komponentenname. Die Nummer ist die Version. Wenn du beides kombinierst, erhältst du so etwas wie payment-service-2.1.3. Dieser String verweist auf genau ein Artefakt. Nicht auf das von letzter Woche. Nicht auf das mit dem ähnlichen Namen. Nur auf dieses eine.

Versionierung ist nicht nur für die Show

Versionierung ist das System, das dem Nummernteil deiner Artefaktkennung Bedeutung verleiht. Es ist nicht nur ein Zähler, der hochgeht. Ein gutes Versionierungsschema verrät dir etwas über das Artefakt selbst. Es kommuniziert die Art der Änderung, das Risikoniveau und die Beziehung zu früheren Versionen.

Das am weitesten verbreitete System ist Semantic Versioning. Es verwendet drei durch Punkte getrennte Zahlen: MAJOR.MINOR.PATCH. Jede Zahl hat eine spezifische Bedeutung.

MAJOR erhöht sich bei Änderungen, die die Abwärtskompatibilität brechen. Wenn bestehende Nutzer ihren Code oder Workflow anpassen müssen, ist das ein Major-Version-Sprung.
MINOR erhöht sich bei neuen Funktionen, die weiterhin mit der alten Vorgehensweise funktionieren. Nutzer können upgraden, ohne etwas zu brechen.
PATCH erhöht sich bei Fehlerbehebungen, die keine neuen Funktionen einführen oder bestehende Funktionalität brechen.

Wenn du Version 2.1.3 siehst, weißt du, dass die Anwendung zwei größere breaking changes, eine Feature-Erweiterung und drei Bugfixes durchlaufen hat. Das ist eine Menge Information, verpackt in einen kleinen String.

Immutability beginnt mit Versionierung

Die Versionsnummer ist nicht nur ein Label. Sie ist ein Vertrag. Sobald ein Artefakt gebaut und mit einer Version getaggt ist, sollte sich diese Version nie ändern. Wenn du denselben Code neu baust, solltest du dasselbe Artefakt erhalten. Wenn sich etwas ändert, muss sich die Version ändern.

Das macht ein Artefakt unveränderlich (immutable). Version 2.1.3 bezieht sich immer auf dasselbe Binary, dasselbe Container-Image, dasselbe Paket. Egal, ob du es heute, nächste Woche oder sechs Monate später herunterlädst – das Artefakt ist identisch. Diese Gewissheit ermöglicht es dir, etwas im Staging zu testen und dann exakt dasselbe in Produktion zu deployen, ohne Überraschungen.

Versionierung und Release sind unterschiedliche Dinge

Ein häufiger Fehler ist es, Versionierung und Release als dasselbe Konzept zu behandeln. Das sind sie nicht. Versionierung betrifft die Kennzeichnung des Artefakts. Release betrifft die Entscheidung, dieses Artefakt für Nutzer verfügbar zu machen.

Du kannst Version 2.2.0-beta bauen und zum Testen im Staging deployen. Diese Version existiert als Artefakt, ist aber kein Release. Nach dem Testen könntest du sie zu 2.2.0 befördern und in Produktion releasen. Oder du findest Probleme und baust stattdessen eine 2.2.1.

Diese Trennung gibt dir Flexibilität. Du kannst Artefakte häufig bauen und versionieren, aber nur releasen, wenn du sicher bist. Die Versionsnummer verfolgt die Identität des Artefakts. Die Release-Entscheidung verfolgt seine Bereitschaft.

Praktische Auswirkungen auf deine Pipeline

Sobald du ein klares Namens- und Versionierungssystem hast, werden mehrere Dinge einfacher.

Rückverfolgbarkeit wird automatisch. Wenn ein Bug in Produktion gemeldet wird, schaust du dir die Version an, die in dieser Umgebung läuft. Du prüfst, welche Änderungen in diese Version eingeflossen sind. Du vergleichst sie mit der vorherigen stabilen Version. All das ist möglich, weil jedes Artefakt eine eindeutige Kennung hat, die zurück zum Quellcode und Build-Prozess führt.

Rollbacks werden präzise. Du rätst nicht, welche Version vorher funktioniert hat. Du weißt genau, welche Version letzte Woche lief, und du kannst genau dasselbe Artefakt erneut deployen. Weil das Artefakt unveränderlich ist, deployest du exakt dasselbe Binary, keinen Neubau, der sich möglicherweise anders verhält.

Kommunikation wird klarer. Statt „deploye den neuesten Build“ sagst du „deploye payment-service 2.1.3 in Produktion“. Jeder weiß genau, was das bedeutet. Der DBA weiß, welche Datenbankmigration zu erwarten ist. Das QA-Team weiß, welche Tests gelaufen sind. Das Operations-Team weiß, was zu überwachen ist.

Eine einfache Checkliste für die Artefaktbenennung

Wenn du die Artefaktbenennung zum ersten Mal einrichtest, hier eine kurze Checkliste für den Start:

Jedes Artefakt hat einen Namen, der dem Anwendungs- oder Komponentennamen entspricht.
Jedes Artefakt hat eine Versionsnummer, die einem konsistenten Schema folgt.
Die Versionsnummer wird zur Build-Zeit vergeben und danach nie geändert.
Das Artefakt-Repository speichert Artefakte nach Name und Version, nicht nach Zeitstempel oder Ordner.
Das Team versteht den Unterschied zwischen Versionierung (Kennzeichnung) und Release (Bereitstellung).
Das Versionierungsschema kommuniziert die Art der Änderungen (Major, Minor, Patch).

Das Fazit

Artefaktbenennung und Versionierung sind keine bürokratische Übung. Sie sind die Grundlage für zuverlässiges Deployment. Ohne sie produziert deine Pipeline Unsicherheit. Mit ihr hat jedes Artefakt eine klare Identität, jedes Deployment ein klares Ziel und jeder Rollback ein klares Ziel. Gib deinen Artefakten Namen. Nummeriere sie konsistent. Mache sie unveränderlich. Dann kannst du mit Zuversicht deployen.