Artifact in app-ontwikkeling: wat het is, typen en hoe te beheren

Wat is Artifact in ontwikkeling

Artifact (build-artefact) — is het resultaat van het compileren van broncode, klaar voor implementatie of gebruik als afhankelijkheid. Het buildproces zet bronbestanden (Java, Kotlin, Swift, C++ en andere) om in binaire pakketten die kunnen worden uitgevoerd op het doelapparaat of de server.

Het concept van artefact gaat verder dan uitvoerbare bestanden. Bijvoorbeeld JAR-bibliotheek — is een artefact dat als afhankelijkheid in andere projecten wordt gebruikt. Docker-image — een artefact dat de app en zijn omgeving bevat. Zelfs een testdekkingsrapport kan als artefact worden beschouwd in de context van CI/CD.

Moderne ontwikkeling in grote bedrijven omvat het beheer van honderdduizenden artefacten. Google DORA koppelt de volwassenheid van artefactbeheer aan de algehele DevOps-effectiviteit — teams die artefactregisters gebruiken, brengen sneller releases uit en hebben minder vaak problemen bij implementatie.

Levenscyclus van een artefact

Elk artefact doorloopt verschillende fasen: creatie (build, compilatie), validatie (testen, beveiligingscontrole), opslag (artefactregister), distributie (publicatie voor download) en archivering of verwijdering (wanneer een versie verouderd raakt).

Soorten artefacten in mobiele ontwikkeling

Verschillende platforms en technologieën genereren verschillende artefactformaten. Inzicht in formaten is noodzakelijk voor het correct configureren van de CI/CD-pipeline en het kiezen van een opslagsysteem.

Android-artefacten

APK (Android Package Kit) — traditioneel installatiepakketformaat. AAB (Android App Bundle) — modern formaat voor publicatie in Google Play, dat alleen de bronnen bevat die een specifiek apparaat nodig heeft. AAB vermindert de grootte van de geïnstalleerde app met gemiddeld 15-20% in vergelijking met universele APK.

iOS-artefacten

IPA (iOS App Store Package) — archief met code en bronnen voor iOS-apparaten. XCArchive — tussenartefact gemaakt door Xcode, waaruit de definitieve IPA wordt geëxporteerd. dSYM — debugbestand dat nodig is voor het symboliseren van crashlogs.

Artefacten van server- en bibliotheekprojecten

JAR (Java ARchive) — voor Java/Kotlin-bibliotheken. AAR (Android ARchive) — voor Android-bibliotheken met bronnen. Docker-images — containerartefacten voor microservices. Elk type heeft zijn eigen register en regels voor versiebeheer.

Artefacten in CI/CD-pipeline

Artefacten — de verbindende schakel tussen pijplijnfasen. Elke fase verbruikt artefacten van de vorige en produceert nieuwe. Inzicht in deze stroom is cruciaal voor het configureren van effectieve CI/CD.

Stroom van artefacten in de pipeline

Typische stroom omvat: commit → buildserver compileert code en maakt een niet-geoptimaliseerd artefact → testartefact wordt gebruikt voor het uitvoeren van tests → bij succes wordt een release-artefact gemaakt → het wordt ondertekend en gepubliceerd in het artefactregister → uit het register wordt het artefact opgehaald voor implementatie naar staging en productie. Elke overgang tussen fasen gaat gepaard met integriteits- en conformiteitscontrole.

Tussen- en eindartefacten

De pipeline kan meerdere artefacten in verschillende fasen maken. Debug-artefacten bevatten debug-informatie, niet-geoptimaliseerde — worden snel gebouwd voor tests, release-artefacten — definitief, met optimalisatie en obfuscatie. Het CI-systeem moet ze kunnen onderscheiden en geschikte opslagbeleidsregels toepassen voor elk type.

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

Het is belangrijk onderscheid te maken tussen afhankelijkheidscache en build-artefacten. Cache (Gradle cache, CocoaPods cache) versnelt herhaalde builds, maar is niet bedoeld voor implementatie. Artefacten — eindproduct klaar voor distributie. Stel voor cache een TTL in van enkele dagen, voor artefacten — weken of maanden.

Artefactopslagplaatsen

Artefacten mogen niet op de buildserver worden opgeslagen — hiervoor bestaan gespecialiseerde systemen. Repository Manager biedt gecentraliseerde opslag, indexering, toegangscontrole en integratie met CI/CD-tools.

Populaire artefactregisters

JFrog Artifactory — universele manager die Maven, Gradle, Docker, NuGet, npm, APT, YUM ondersteunt. Sonatype Nexus — open-source alternatief met ondersteuning voor de belangrijkste formaten. GitHub Packages — ingebouwd register in GitHub, handig voor teams die al GitHub gebruiken. GitLab Container Registry — voor Docker-images.

Criteria voor registerkeuze

Belangrijkste factoren: ondersteunde formaten, licentiemodel (open-source/enterprise), integratie met bestaande CI/CD, replicatiemogelijkheid tussen regio's, aanwezigheid van automatisch opschoningsbeleid voor oude versies en compliancerapporten.

// Jenkins pipeline — publicatie van APK 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)

Versiebeheer en naamgeving

Een juiste strategie voor versiebeheer van artefacten is cruciaal voor reproduceerbaarheid van builds en het volgen van wijzigingen. Zonder versiebeheer is het onmogelijk te bepalen welke codeversie een probleem in productie heeft veroorzaakt.

Semantic Versioning (SemVer)

Standaard MAJOR.MINOR.PATCH: MAJOR verandert bij incompatibele API-wijzigingen, MINOR — bij toevoeging van achterwaarts compatibele functionaliteit, PATCH — bij achterwaarts compatibele fixes. Voor CI/CD worden build-metadata aan de versie toegevoegd: 2.4.1+build.20260703.1. Dit maakt het mogelijk om precies te bepalen welke commit een specifiek artefact heeft gegenereerd en wanneer het is gemaakt.

Traceerbaarheid — koppeling met Git

Elk artefact moet metadata bevatten over zijn oorsprong: commit SHA, CI-buildnummer, branchnaam, builddatum. Deze informatie wordt vastgelegd in het manifest van het artefact en maakt het mogelijk om op elk moment de context van zijn creatie te reconstrueren. Zonder traceerbaarheid wordt werken met artefacten een gokwerk, wat onacceptabel is voor productiesystemen met auditeisen.

Naamgeving van artefacten

Naamconventie: {project}-{module}-{version}.{ext}. Bijvoorbeeld: `messaging-sdk-2.4.1.aar` of `app-release-2.4.1.apk`. De buildserver kan automatisch een versie genereren op basis van een Git-tag of CI-buildnummer.

• Gebruik Git-tag als versiebron — dit koppelt het artefact aan een specifieke codestatus
• Voeg commit SHA toe aan metadata voor nauwkeurige identificatie tijdens debuggen
• Configureer een bewaarbeleid — bewaar de laatste N versies, archiveer de rest

Snapshot vs Release

In Maven/Gradle artefactregisters wordt onderscheid gemaakt tussen release-versies (vast, onveranderlijk) en snapshot-versies (huidige ontwikkeling, kunnen worden overschreven). In CI/CD-pipelines zijn snapshot-artefacten handig voor ontwikkeling, maar in productie mogen alleen release-versies worden gebruikt.

Beveiliging van artefacten

Artefacten — een sleutelelement van de software supply chain. Compromittering van een artefact kan leiden tot het binnendringen van kwaadaardige code in productie. De beveiliging van artefacten omvat verschillende beschermingsniveaus.

Ondertekening van artefacten

APK-bestanden worden ondertekend met jarsigner of apksigner; IPA — met Apple-certificaat; Docker-images — met Content Trust (Notary) van Docker. Ondertekening garandeert integriteit en bevestigt de auteur van het artefact. De CI/CD-pipeline moet verificatie van alle externe afhankelijkheden omvatten.

Kwetsbaarheidsscanning

Voor publicatie wordt het artefact gecontroleerd door automatische scanners: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Ze analyseren opgenomen afhankelijkheden, versies van gebruikte bibliotheken en bekende CVE-kwetsbaarheden. Bij detectie van een kritieke kwetsbaarheid wordt de release onmiddellijk geblokkeerd totdat deze door ontwikkelaars is verholpen.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — beveiligingsraamwerk dat vertrouwensniveaus definieert van SLSA 1 (basis) tot SLSA 4 (maximaal). De buildserver moet provenance attestation genereren — een cryptografisch ondertekend bewijs van hoe en uit welke code het artefact is gebouwd.