Artifact az alkalmazásfejlesztésben: mi ez, típusok és hogyan kezeljük

Mi az Artifact a fejlesztésben

Artifact (build artefaktum) — a forráskód fordításának eredménye, készen áll a telepítésre vagy függőségként való használatra. A build folyamat a forrásfájlokat (Java, Kotlin, Swift, C++ és mások) bináris csomagokká alakítja, amelyek a céleszközön vagy szerveren futtathatók.

Az artefaktum fogalma túlmutat a futtatható fájlokon. Például a JAR könyvtár — egy artefaktum, amelyet függőségként használnak más projektekben. A Docker-kép — egy artefaktum, amely az alkalmazást és környezetét tartalmazza. Még a teszteredményekről szóló jelentés is artefaktumnak tekinthető a CI/CD kontextusában.

A modern fejlesztés nagyvállalatoknál több százezer artefaktum kezelését foglalja magában. A Google DORA összekapcsolja az artefaktumkezelés érettségét az általános DevOps hatékonysággal — a verziókezelő rendszereket használó csapatok gyorsabban adnak ki verziókat és ritkábban találkoznak telepítési problémákkal.

Az artefaktum életciklusa

Minden artefaktum több szakaszon megy keresztül: létrehozás (build, fordítás), validáció (tesztelés, biztonsági ellenőrzés), tárolás (artefaktum regiszter), terjesztés (közzététel letöltésre) és archiválás vagy törlés (amikor a verzió elavulttá válik).

Artefaktum típusok mobil fejlesztésben

A különböző platformok és technológiák eltérő artefaktum formátumokat hoznak létre. A formátumok megértése szükséges a CI/CD pipeline helyes konfigurálásához és a tárolórendszer kiválasztásához.

Android artefaktumok

APK (Android Package Kit) — hagyományos telepítőcsomag formátum. AAB (Android App Bundle) — modern formátum a Google Play-ben történő közzétételhez, amely csak az adott eszköz számára szükséges erőforrásokat tartalmazza. Az AAB csökkenti a telepített alkalmazás méretét átlagosan 15-20%-kal az univerzális APK-hoz képest.

iOS artefaktumok

IPA (iOS App Store Package) — kódot és erőforrásokat tartalmazó archívum iOS eszközökhöz. XCArchive — köztes artefaktum, amelyet az Xcode hoz létre, és amelyből a végleges IPA exportálásra kerül. dSYM — hibakeresési fájl, amely a crash naplók szimbolizálásához szükséges.

Szerver és könyvtár projektek artefaktumai

JAR (Java ARchive) — Java/Kotlin könyvtárakhoz. AAR (Android ARchive) — Android könyvtárakhoz erőforrásokkal. Docker-képek — konténer artefaktumok mikroszolgáltatásokhoz. Minden típusnak saját regisztere és verziókezelési szabályai vannak.

Artefaktumok a CI/CD pipeline-ban

Az artefaktumok — összekötő kapocs a pipeline szakaszai között. Minden szakasz felhasználja az előző artefaktumait és újakat hoz létre. Ennek a folyamatnak a megértése kritikus a hatékony CI/CD konfigurálásához.

Artefaktumok áramlása a pipeline-ban

A tipikus áramlás a következő: commit → a build szerver lefordítja a kódot és létrehoz egy nem optimalizált artefaktumot → a teszt artefaktumot a tesztek futtatásához használják → siker esetén létrejön a kiadási artefaktum → aláírásra kerül és közzéteszik az artefaktum regiszterben → a regiszterből az artefaktumot kihozzák telepítésre staging és production környezetbe. Minden szakaszok közötti átmenetet integritás- és követelmény-ellenőrzés kísér.

Köztes és végleges artefaktumok

A pipeline több artefaktumot is létrehozhat különböző szakaszokban. Debug artefaktumok hibakeresési információkat tartalmaznak, nem optimalizáltak — gyorsan épülnek a tesztekhez, a kiadási artefaktumok — véglegesek, optimalizálással és obfuszkációval. A CI rendszernek meg kell különböztetnie őket, és megfelelő tárolási szabályzatot kell alkalmaznia minden típusra.

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

Fontos különbséget tenni a függőségi gyorsítótár és a build artefaktumok között. A gyorsítótár (Gradle cache, CocoaPods cache) felgyorsítja az ismételt build-eket, de nem telepítésre szolgál. Az artefaktumok — a terjesztésre kész végtermék. A gyorsítótárhoz állítson be néhány napos TTL-t, az artefaktumokhoz heteket vagy hónapokat.

Artefaktum tárolók

Az artefaktumokat nem szabad a build szerveren tárolni — erre specializált rendszerek léteznek. A Repository Manager központosított tárolást, indexelést, hozzáférés-ellenőrzést és CI/CD eszközökkel való integrációt biztosít.

Népszerű artefaktum regiszterek

JFrog Artifactory — univerzális menedzser, amely támogatja a Maven, Gradle, Docker, NuGet, npm, APT, YUM rendszereket. Sonatype Nexus — nyílt forráskódú alternatíva a fő formátumok támogatásával. GitHub Packages — beépített regiszter a GitHub-ban, kényelmes a már GitHub-ot használó csapatok számára. GitLab Container Registry — Docker-képekhez.

A regiszter kiválasztásának szempontjai

Fő tényezők: támogatott formátumok, licencmodell (open-source/enterprise), integráció a meglévő CI/CD-vel, régiók közötti replikáció lehetősége, automatikus régi verziók tisztítási szabályzatának megléte és megfelelőségi jelentések.

// Jenkins pipeline — APK közzététele az Artifactory-ban
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)

Verziókezelés és elnevezés

A megfelelő verziókezelési stratégia kritikus a build-ek reprodukálhatóságához és a változások nyomon követéséhez. Verziókezelés nélkül lehetetlen meghatározni, hogy a kód mely verziója okozott problémát élesben.

Semantic Versioning (SemVer)

MAJOR.MINOR.PATCH szabvány: a MAJOR inkompatibilis API-változásoknál változik, a MINOR — visszafelé kompatibilis funkciók hozzáadásakor, a PATCH — visszafelé kompatibilis javításoknál. CI/CD esetén build metaadatok kerülnek a verzióhoz: 2.4.1+build.20260703.1. Ez lehetővé teszi annak pontos meghatározását, hogy melyik commit hozta létre az adott artefaktumot és mikor készült.

Visszakövethetőség — kapcsolat a Git-tel

Minden artefaktumnak tartalmaznia kell metaadatokat a származásáról: commit SHA, CI build szám, ág neve, build dátuma. Ezek az információk az artefaktum manifestjében kerülnek rögzítésre, és lehetővé teszik a létrehozás kontextusának bármikori rekonstruálását. Visszakövethetőség nélkül az artefaktumokkal való munka verzió-találgatássá válik, ami elfogadhatatlan az auditkövetelményekkel rendelkező éles rendszerek esetében.

Artefaktumok elnevezése

Név konvenció: {project}-{module}-{version}.{ext}. Például: `messaging-sdk-2.4.1.aar` vagy `app-release-2.4.1.apk`. A build szerver automatikusan generálhat verziót a Git tag vagy a CI build szám alapján.

• Használjon Git tag-et verzióforrásként — ez összeköti az artefaktumot a kód adott állapotával
• Adjon hozzá commit SHA-t a metaadatokhoz a pontos azonosításhoz hibakereséskor
• Állítson be adatmegőrzési szabályzatot — tárolja az utolsó N verziót, a többit archiválja

Snapshot vs Release

A Maven/Gradle artefaktum regiszterekben megkülönböztetjük a release verziókat (rögzített, megváltoztathatatlan) és a snapshot verziókat (aktuális fejlesztés, felülírható). A CI/CD pipeline-okban a snapshot artefaktumok kényelmesek a fejlesztéshez, de élesben csak release verziókat szabad használni.

Artefaktumok biztonsága

Az artefaktumok — a szoftverellátási lánc (software supply chain) kulcselemei. Az artefaktum kompromittálódása rosszindulatú kód bejutásához vezethet az éles környezetbe. Az artefaktumok biztonsága több védelmi szintet foglal magában.

Artefaktumok aláírása

Az APK fájlokat jarsigner vagy apksigner írja alá; az IPA-t — Apple tanúsítvány; a Docker-képeket — Content Trust (Notary) a Dockertől. Az aláírás garantálja az integritást és megerősíti az artefaktum szerzőjét. A CI/CD pipeline-nak tartalmaznia kell az összes harmadik féltől származó függőség aláírásának ellenőrzését.

Sebezhetőségi vizsgálat

A közzététel előtt az artefaktumot automatikus szkennerek ellenőrzik: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Ezek elemzik a bevont függőségeket, a használt könyvtárak verzióit és az ismert CVE sebezhetőségeket. Kritikus sebezhetőség észlelése esetén a kiadás azonnal blokkolásra kerül a fejlesztők általi javításig.

Ellátási lánc szintek

SLSA (Supply chain Levels for Software Artifacts) — biztonsági keretrendszer, amely a bizalmi szinteket határozza meg SLSA 1 (alap) és SLSA 4 (maximális) között. A build szervernek provenance attestation-t — kriptográfiailag aláírt tanúsítványt kell generálnia arról, hogyan és milyen kódból épült az artefaktum.