Skip to content
IRC-Coding IRC-Coding
Artefakt Binärartefakt SBOM Signatur Semver Container Image

Artefakte & Binärartefakte: Repository, Versionierung, SBOM und Signaturen

Artefakt vs. Binärartefakt: Build-Ergebnisse (JAR/DLL/EXE/Container-Image), Unveränderlichkeit, Release vs Snapshot, Checksummen/Signaturen, SBOM, Promotion Dev→Prod und prüfungsrelevante Fragen.

S

schutzgeist

2 min read

Binärartefakte und Artefakte

Dieser Beitrag ist eine Begriffserklärung zu Artefakten und Binärartefakten – inklusive Prüfungsfragen, Kernkomponenten und Tags.

In a Nutshell

  • Ein Artefakt ist jedes Projektergebnis (Doku, Modell, Testprotokoll, Code).
  • Ein Binärartefakt ist das maschinenlesbare Produkt eines Builds (Executable, Bibliothek, Paket, Container-Image).

Kompakte Fachbeschreibung

Binärartefakte entstehen durch Kompilieren/Linken/Paketieren/Image-Builds, z.B.:

  • JAR, DLL, EXE
  • NPM-Paket, Python Wheel
  • Docker/OCI Image

Sie werden versioniert in einem Artefakt-Repository abgelegt – mit Metadaten (Version, Commit, Buildnummer), Prüfsummen und idealerweise Signaturen.

Wichtige Prinzipien:

  • Unveränderlichkeit: Releases nicht überschreiben.
  • Build once, promote: dasselbe Artefakt wandert Dev → Staging → Prod.
  • Supply-Chain-Security: SBOM, Scans, Attestierungen.

Prüfungsrelevante Stichpunkte

  • Artefakt vs Binärartefakt sauber trennen
  • Release vs Snapshot
  • Semantische Versionierung
  • Checksummen/Signaturen/SBOM als Nachweise
  • Reproduzierbare Builds (Lockfiles, feste Toolchain)
  • Policies vor Deployment (Scans, Signaturprüfung)
  • Retention/Archivierung (Compliance)

Kernkomponenten

  1. Quellartefakte (Code, IaC, Doku)
  2. Buildsystem/Packager/Image Builder
  3. Binärartefakt-Formate
  4. Metadaten (Version/Commit)
  5. Qualitätsberichte (Tests/Coverage/Linter)
  6. Security (SBOM/Scan/Signatur)
  7. Artefakt-Repository/Registry
  8. Promotion-Pfad
  9. Konsum (Paketmanager/Lockfiles)
  10. Governance (Retention/ACL)

Praxisbeispiel (Container-Release)

1) CI baut JAR + Container-Image v1.4.0
2) SBOM erzeugen + SHA256 + Signatur
3) Push in Registry/Artefakt-Repo
4) Deploy nach Staging, Tests
5) Freigabe -> Promotion nach Prod (gleiches Artefakt)
6) Release Notes + Retention (z.B. 12 Monate)

Vorteile und Nachteile

Vorteile

  • Nachvollziehbarkeit + Reproduzierbarkeit
  • Security durch Signaturen/SBOM
  • saubere Releases + Rollbacks

Nachteile

  • Storage- und Governance-Aufwand
  • Tool-Komplexität bei vielen Formaten

Typische Prüfungsfragen (mit Kurzantwort)

  1. Artefakt vs Binärartefakt? Artefakt = jedes Ergebnis; Binärartefakt = Build-Produkt.
  2. Warum immutable Releases? Reproduzierbarkeit und Sicherheit.
  3. Wozu SBOM? Komponenten-/Lizenz-/Vulnerability-Transparenz.

Wichtigste Quellen

  1. https://reproducible-builds.org
  2. https://semver.org/lang/de
Zurück zum Blog
Share:

Ähnliche Beiträge