Artifact i apputveckling: vad det är, typer och hur man hanterar

Vad är Artifact i utveckling

Artifact (byggartefakt) — är resultatet av kompilering av källkod, redo för distribution eller användning som beroende. Byggprocessen omvandlar källfiler (Java, Kotlin, Swift, C++ och andra) till binära paket som kan köras på målenheten eller servern.

Begreppet artefakt sträcker sig bortom körbara filer. Till exempel JAR-bibliotek — är en artefakt som används som beroende i andra projekt. Docker-avbildning — en artefakt som innehåller appen och dess miljö. Även en testtäckningsrapport kan betraktas som en artefakt i CI/CD-sammanhang.

Modern utveckling i stora företag omfattar hantering av hundratusentals artefakter. Google DORA kopplar mognaden av artefakthantering till den övergripande DevOps-effektiviteten — team som använder artefaktregister släpper versioner snabbare och stöter mer sällan på problem vid driftsättning.

En artefakts livscykel

Varje artefakt går igenom flera steg: skapande (bygg, kompilering), validering (testning, säkerhetskontroll), lagring (artefaktregister), distribution (publicering för nedladdning) och arkivering eller borttagning (när en version blir föråldrad).

Typer av artefakter inom mobilutveckling

Olika plattformar och teknologier genererar olika artefaktformat. Förståelse för format är nödvändigt för korrekt konfiguration av CI/CD-pipeline och val av lagringssystem.

Android-artefakter

APK (Android Package Kit) — traditionellt installationspaketformat. AAB (Android App Bundle) — modernt format för publicering i Google Play, som endast innehåller de resurser som en specifik enhet behöver. AAB minskar storleken på den installerade appen med i genomsnitt 15-20% jämfört med universell APK.

iOS-artefakter

IPA (iOS App Store Package) — arkiv med kod och resurser för iOS-enheter. XCArchive — mellanliggande artefakt skapad av Xcode, från vilken den slutliga IPA exporteras. dSYM — felsökningsfil som behövs för symbolisering av krascher.

Artefakter för server- och biblioteksprojekt

JAR (Java ARchive) — för Java/Kotlin-bibliotek. AAR (Android ARchive) — för Android-bibliotek med resurser. Docker-avbildningar — containerartefakter för mikrotjänster. Varje typ har sitt eget register och regler för versionshantering.

Artefakter i CI/CD-pipeline

Artefakter — länken mellan pipeline-stegen. Varje steg förbrukar artefakter från föregående och producerar nya. Att förstå detta flöde är avgörande för att konfigurera effektiv CI/CD.

Flöde av artefakter i pipeline

Typiskt flöde omfattar: commit → byggservern kompilerar koden och skapar en ooptimerad artefakt → testartefakten används för att köra tester → vid framgång skapas en release-artefakt → den signeras och publiceras i artefaktregistret → från registret hämtas artefakten för driftsättning till staging och produktion. Varje övergång mellan steg åtföljs av kontroll av integritet och överensstämmelse med krav.

Mellanliggande och slutliga artefakter

Pipeline kan skapa flera artefakter i olika steg. Debug-artefakter innehåller felsökningsinformation, ooptimerade — byggs snabbt för testning, release-artefakter — slutgiltiga, med optimering och fördunkling. CI-systemet måste kunna skilja på dem och tillämpa lämpliga lagringsprinciper för varje typ.

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

Det är viktigt att skilja på beroendecache och byggartefakter. Cache (Gradle cache, CocoaPods cache) snabbar upp upprepade byggen men är inte avsedd för driftsättning. Artefakter — slutprodukt redo för distribution. För cache, ställ in TTL på några dagar, för artefakter — veckor eller månader.

Artefaktförråd

Artefakter bör inte lagras på byggservern — det finns specialiserade system för detta. Repository Manager tillhandahåller centraliserad lagring, indexering, åtkomstkontroll och integration med CI/CD-verktyg.

Populära artefaktregister

JFrog Artifactory — universell hanterare som stöder Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — open-source-alternativ med stöd för de viktigaste formaten. GitHub Packages — inbyggt register i GitHub, bekvämt för team som redan använder GitHub. GitLab Container Registry — för Docker-avbildningar.

Kriterier för val av register

Huvudfaktorer: stödda format, licensmodell (open-source/enterprise), integration med befintlig CI/CD, möjlighet till replikering mellan regioner, förekomst av policyer för automatisk rensning av gamla versioner och efterlevnadsrapporter.

// Jenkins pipeline — publicering av APK i 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)

Versionhantering och namngivning

En korrekt versionshanteringsstrategi för artefakter är avgörande för reproducerbarhet av byggen och spårning av ändringar. Utan versionshantering är det omöjligt att fastställa vilken kodversion som orsakade ett problem i produktion.

Semantic Versioning (SemVer)

Standard MAJOR.MINOR.PATCH: MAJOR ändras vid inkompatibla API-ändringar, MINOR — vid tillägg av bakåtkompatibel funktionalitet, PATCH — vid bakåtkompatibla korrigeringar. För CI/CD läggs byggmetadata till versionen: 2.4.1+build.20260703.1. Detta gör det möjligt att exakt fastställa vilken commit som genererade en specifik artefakt och när den skapades.

Spårbarhet — koppling till Git

Varje artefakt bör innehålla metadata om sitt ursprung: commit SHA, CI-byggnummer, grennamn, byggdatum. Denna information registreras i artefaktens manifest och gör det möjligt att när som helst rekonstruera sammanhanget för dess skapelse. Utan spårbarhet blir arbetet med artefakter gissning av versioner, vilket är oacceptabelt för produktionssystem med revisionskrav.

Namngivning av artefakter

Namnkonvention: {project}-{module}-{version}.{ext}. Till exempel: `messaging-sdk-2.4.1.aar` eller `app-release-2.4.1.apk`. Byggservern kan automatiskt generera en version baserat på Git-tagg eller CI-byggnummer.

• Använd Git-tagg som versionskälla — detta kopplar artefakten till ett specifikt kodtillstånd
• Lägg till commit SHA i metadata för exakt identifiering vid felsökning
• Konfigurera en bevarandepolicy — behåll de senaste N versionerna, arkivera resten

Snapshot vs Release

I Maven/Gradle artefaktregister skiljer man på release-versioner (fasta, oföränderliga) och snapshot-versioner (aktuell utveckling, kan skrivas över). I CI/CD-pipelines är snapshot-artefakter praktiska för utveckling, men i produktion ska endast release-versioner användas.

Säkerhet för artefakter

Artefakter — en nyckeldel i programvaruleveranskedjan (software supply chain). Kompromettering av en artefakt kan leda till att skadlig kod tar sig in i produktion. Säkerhet för artefakter omfattar flera skyddsnivåer.

Signering av artefakter

APK-filer signeras med jarsigner eller apksigner; IPA — med Apple-certifikat; Docker-avbildningar — med Content Trust (Notary) från Docker. Signering garanterar integritet och bekräftar artefaktens upphovsman. CI/CD-pipelinen bör inkludera verifiering av signaturer för alla tredjepartsberoenden.

Sårbarhetsskanning

Före publicering kontrolleras artefakten av automatiska skannrar: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. De analyserar inkluderade beroenden, versioner av använda bibliotek och kända CVE-sårbarheter. Vid upptäckt av en kritisk sårbarhet blockeras releasen omedelbart tills den åtgärdats av utvecklare.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — säkerhetsramverk som definierar förtroendenivåer från SLSA 1 (grundläggande) till SLSA 4 (maximal). Byggservern måste generera provenance attestation — ett kryptografiskt signerat intyg om hur och från vilken kod artefakten byggdes.