Artifact in der App-Entwicklung: Was es ist, Typen und wie man es verwaltet

Was ist ein Artifact in der Entwicklung

Ein Artifact (Build-Artefakt) ist das Ergebnis der Kompilierung von Quellcode, bereit zur Bereitstellung oder Verwendung als Abhängigkeit. Der Build-Prozess wandelt Quelldateien (Java, Kotlin, Swift, C++ und andere) in Binärpakete um, die auf einem Zielgerät oder Server ausgeführt werden können.

Das Konzept eines Artefakts geht über ausführbare Dateien hinaus. Beispielsweise ist eine JAR-Bibliothek ein Artefakt, das als Abhängigkeit in anderen Projekten verwendet wird. Ein Docker-Image ist ein Artefakt, das die Anwendung und ihre Umgebung enthält. Selbst ein Testabdeckungsbericht kann im CI/CD-Kontext als Artefakt betrachtet werden.

Die moderne Entwicklung in großen Unternehmen umfasst die Verwaltung von Hunderttausenden von Artefakten. Google DORA verknüpft die Reife der Artefaktverwaltung mit der allgemeinen DevOps-Effektivität — Teams, die Artefakt-Registries verwenden, veröffentlichen schneller Releases und haben weniger Bereitstellungsprobleme.

Lebenszyklus eines Artefakts

Jedes Artefakt durchläuft mehrere Phasen: Erstellung (Build, Kompilierung), Validierung (Tests, Sicherheitsprüfungen), Speicherung (Artefakt-Registry), Verteilung (Veröffentlichung zum Download) und Archivierung oder Löschung (wenn die Version veraltet ist).

Artefakttypen in der mobilen Entwicklung

Verschiedene Plattformen und Technologien erzeugen unterschiedliche Artefaktformate. Die Formate zu verstehen ist für die korrekte Konfiguration der CI/CD-Pipeline und die Wahl eines Speichersystems unerlässlich.

Android-Artefakte

APK (Android Package Kit) ist das traditionelle Installationspaketformat. AAB (Android App Bundle) ist ein modernes Format für die Veröffentlichung bei Google Play, das nur die für ein bestimmtes Gerät benötigten Ressourcen enthält. AAB reduziert die Größe der installierten Anwendung im Durchschnitt um 15-20% im Vergleich zu einer universellen APK.

iOS-Artefakte

IPA (iOS App Store Package) ist ein Archiv mit Code und Ressourcen für iOS-Geräte. XCArchive ist ein von Xcode erstelltes Zwischenartefakt, aus dem das endgültige IPA exportiert wird. dSYM ist eine Debug-Symbol-Datei, die für die Symbolisierung von Crash-Logs erforderlich ist.

Artefakte von Server- und Bibliotheksprojekten

JAR (Java ARchive) — für Java/Kotlin-Bibliotheken. AAR (Android ARchive) — für Android-Bibliotheken mit Ressourcen. Docker-Images — Container-Artefakte für Microservices. Jeder Typ hat seine eigene Registry und Versionsverwaltungsregeln.

Artefakte in der CI/CD-Pipeline

Artefakte sind das Bindeglied zwischen den Pipeline-Stufen. Jede Stufe verbraucht Artefakte der vorherigen und produziert neue. Das Verständnis dieses Flusses ist entscheidend für die Einrichtung einer effektiven CI/CD-Pipeline.

Artefaktfluss in der Pipeline

Ein typischer Fluss umfasst: Commit -> Build-Server kompiliert den Code und erstellt ein nicht optimiertes Artefakt -> das Test-Artefakt wird zum Ausführen von Tests verwendet -> bei Erfolg wird ein Release-Artefakt erstellt -> es wird signiert und in der Artefakt-Registry veröffentlicht -> das Artefakt wird aus der Registry zur Bereitstellung in Staging und Produktion abgerufen. Jeder Übergang zwischen den Stufen wird von einer Integritätsprüfung und Anforderungskonformitätsprüfung begleitet.

Zwischen- und Endartefakte

Die Pipeline kann in verschiedenen Phasen mehrere Artefakte erstellen. Debug-Artefakte enthalten Debug-Informationen, nicht optimierte werden schnell für Tests gebaut, Release-Artefakte sind endgültig, mit Optimierung und Verschleierung. Das CI-System muss in der Lage sein, zwischen ihnen zu unterscheiden und für jeden Typ geeignete Aufbewahrungsrichtlinien anzuwenden.

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

Cache vs. Artifact

Es ist wichtig, zwischen Abhängigkeits-Cache und Build-Artefakten zu unterscheiden. Cache (Gradle-Cache, CocoaPods-Cache) beschleunigt wiederholte Builds, ist aber nicht für die Bereitstellung gedacht. Artefakte sind das Endprodukt, bereit zur Verteilung. Setzen Sie einen TTL von mehreren Tagen für Cache und Wochen oder Monate für Artefakte.

Artefakt-Repositories

Artefakte sollten nicht auf dem Build-Server gespeichert werden — für diesen Zweck gibt es spezialisierte Systeme. Ein Repository-Manager bietet zentrale Speicherung, Indexierung, Zugriffskontrolle und Integration mit CI/CD-Tools.

Beliebte Artefakt-Registries

JFrog Artifactory — ein universeller Manager, der Maven, Gradle, Docker, NuGet, npm, APT, YUM unterstützt. Sonatype Nexus — eine Open-Source-Alternative, die wichtige Formate unterstützt. GitHub Packages — eine integrierte Registry in GitHub, praktisch für Teams, die bereits GitHub nutzen. GitLab Container Registry — für Docker-Images.

Auswahlkriterien für die Registry

Wichtige Faktoren: unterstützte Formate, Lizenzierungsmodell (Open-Source/Enterprise), Integration mit bestehendem CI/CD, Replikationsfähigkeiten zwischen Regionen, Verfügbarkeit von automatischen Bereinigungsrichtlinien für alte Versionen und Compliance-Berichte.

// Jenkins Pipeline — APK-Veröffentlichung in Artifactory
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

Versionierung und Benennung

Eine geeignete Strategie zur Versionierung von Artefakten ist entscheidend für die Reproduzierbarkeit von Builds und die Nachverfolgung von Änderungen. Ohne Versionierung ist es unmöglich zu bestimmen, welche Codeversion ein Problem in der Produktion verursacht hat.

Semantische Versionierung (SemVer)

Der MAJOR.MINOR.PATCH-Standard: MAJOR ändert sich bei inkompatiblen API-Änderungen, MINOR bei abwärtskompatiblen Funktionserweiterungen, PATCH bei abwärtskompatiblen Fehlerbehebungen. Für CI/CD werden der Version Build-Metadaten hinzugefügt: 2.4.1+build.20260703.1. Dies ermöglicht es, genau zu bestimmen, welcher Commit ein bestimmtes Artefakt erzeugt hat und wann es erstellt wurde.

Rückverfolgbarkeit — Git-Verknüpfung

Jedes Artefakt sollte Metadaten über seine Herkunft enthalten: Commit-SHA, CI-Build-Nummer, Zweigname, Build-Datum. Diese Informationen werden im Artefakt-Manifest aufgezeichnet und ermöglichen es, den Kontext seiner Erstellung jederzeit zu rekonstruieren. Ohne Rückverfolgbarkeit wird die Arbeit mit Artefakten zum Erraten von Versionen, was für Produktionssysteme mit Audit-Anforderungen inakzeptabel ist.

Benennung von Artefakten

Namenskonvention: {project}-{module}-{version}.{ext}. Zum Beispiel: messaging-sdk-2.4.1.aar oder app-release-2.4.1.apk. Der Build-Server kann automatisch eine Version basierend auf einem Git-Tag oder der Build-Nummer des CI-Systems generieren.

• Verwenden Sie Git-Tags als Versionsquelle — dies verknüpft das Artefakt mit einem bestimmten Codezustand
• Fügen Sie Commit-SHA zu den Metadaten hinzu für eine genaue Identifizierung während des Debuggings
• Konfigurieren Sie eine Aufbewahrungsrichtlinie — behalten Sie die letzten N Versionen, archivieren Sie den Rest

Snapshot vs. Release

In Maven/Gradle-Artefakt-Registries werden Release-Versionen (fest, unveränderlich) und Snapshot-Versionen (aktuelle Entwicklung, überschreibbar) unterschieden. In CI/CD-Pipelines sind Snapshot-Artefakte für die Entwicklung praktisch, aber in der Produktion sollten nur Release-Versionen verwendet werden.

Sicherheit von Artefakten

Artefakte sind ein Schlüsselelement der Software-Lieferkette. Die Kompromittierung eines Artefakts kann dazu führen, dass schädlicher Code in die Produktion gelangt. Die Sicherheit von Artefakten umfasst mehrere Schutzebenen.

Signierung von Artefakten

APK-Dateien werden mit jarsigner oder apksigner signiert; IPA-Dateien werden mit einem Apple-Zertifikat signiert; Docker-Images werden mit Content Trust (Notary) von Docker signiert. Die Signierung gewährleistet Integrität und bestätigt den Autor des Artefakts. Die CI/CD-Pipeline sollte die Signaturprüfung aller Drittanbieter-Abhängigkeiten umfassen.

Schwachstellenscan

Vor der Veröffentlichung wird das Artefakt von automatisierten Scannern überprüft: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Sie analysieren die enthaltenen Abhängigkeiten, die Versionen der verwendeten Bibliotheken und bekannte CVE-Schwachstellen. Wenn eine kritische Schwachstelle entdeckt wird, wird der Release sofort blockiert, bis sie von den Entwicklern behoben ist.

Lieferketten-Ebenen

SLSA (Supply chain Levels for Software Artifacts) ist ein Sicherheitsframework, das Vertrauensstufen von SLSA 1 (grundlegend) bis SLSA 4 (maximal) definiert. Der Build-Server muss einen Provenance-Nachweis erstellen — eine kryptografisch signierte Aussage darüber, wie und aus welchem Code das Artefakt erstellt wurde.