Artifact ve vývoji aplikací: co to je, typy a jak spravovat

Co je Artifact ve vývoji

Artifact (artefakt sestavení) — je výsledek kompilace zdrojového kódu, připravený k nasazení nebo použití jako závislost. Proces sestavení převádí zdrojové soubory (Java, Kotlin, Swift, C++ a další) na binární balíčky, které lze spustit na cílovém zařízení nebo serveru.

Pojem artefakt přesahuje rámec spustitelných souborů. Například knihovna JAR — je artefakt používaný jako závislost v jiných projektech. Obraz Docker — artefakt obsahující aplikaci a její prostředí. Dokonce i zpráva o pokrytí testy může být považována za artefakt v kontextu CI/CD.

Moderní vývoj ve velkých společnostech zahrnuje správu statisíců artefaktů. Google DORA spojuje vyspělost správy artefaktů s celkovou efektivitou DevOps — týmy používající registry artefaktů vydávají verze rychleji a méně často narážejí na problémy při nasazování.

Životní cyklus artefaktu

Každý artefakt prochází několika fázemi: vytvoření (sestavení, kompilace), validace (testování, bezpečnostní kontrola), ukládání (registr artefaktů), distribuce (zveřejnění ke stažení) a archivace nebo odstranění (když verze zastará).

Typy artefaktů v mobilním vývoji

Různé platformy a technologie generují různé formáty artefaktů. Porozumění formátům je nezbytné pro správnou konfiguraci CI/CD pipeline a výběr úložného systému.

Artefakty Android

APK (Android Package Kit) — tradiční formát instalačního balíčku. AAB (Android App Bundle) — moderní formát pro publikaci v Google Play, obsahující pouze zdroje potřebné pro konkrétní zařízení. AAB snižuje velikost instalované aplikace v průměru o 15-20% ve srovnání s univerzálním APK.

Artefakty iOS

IPA (iOS App Store Package) — archiv s kódem a zdroji pro zařízení iOS. XCArchive — mezilehlý artefakt vytvořený Xcode, ze kterého se exportuje finální IPA. dSYM — soubor pro ladění nezbytný pro symbolizaci crash logů.

Artefakty serverových a knihovních projektů

JAR (Java ARchive) — pro knihovny Java/Kotlin. AAR (Android ARchive) — pro knihovny Android se zdroji. Obrazy Docker — kontejnerové artefakty pro mikroslužby. Každý typ má svůj registr a pravidla správy verzí.

Artefakty v CI/CD pipeline

Artefakty — spojovací článek mezi fázemi pipeline. Každá fáze spotřebovává artefakty předchozí a vytváří nové. Pochopení tohoto toku je klíčové pro konfiguraci efektivního CI/CD.

Tok artefaktů v pipeline

Typický tok zahrnuje: commit → build server zkompiluje kód a vytvoří neoptimalizovaný artefakt → testovací artefakt se použije pro spuštění testů → při úspěchu se vytvoří release artefakt → podepíše se a zveřejní v registru artefaktů → z registru se artefakt vyzvedne pro nasazení do staging a produkce. Každý přechod mezi fázemi je doprovázen ověřením integrity a souladu s požadavky.

Mezilehlé a finální artefakty

Pipeline může vytvářet několik artefaktů v různých fázích. Debug artefakty obsahují ladicí informace, neoptimalizované — rychle se sestavují pro testování, release artefakty — konečné, s optimalizací a obfuskací. CI systém je musí umět rozlišovat a aplikovat vhodné zásady ukládání pro každý 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

Je důležité rozlišovat mezipaměť závislostí a artefakty sestavení. Mezipaměť (Gradle cache, CocoaPods cache) urychluje opakovaná sestavení, ale není určena k nasazení. Artefakty — konečný produkt připravený k distribuci. Pro mezipaměť nastavte TTL na několik dní, pro artefakty — týdny nebo měsíce.

Úložiště artefaktů

Artefakty by neměly být ukládány na build serveru — k tomu existují specializované systémy. Repository Manager poskytuje centralizované ukládání, indexování, kontrolu přístupu a integraci s nástroji CI/CD.

Populární registry artefaktů

JFrog Artifactory — univerzální správce podporující Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — open-source alternativa s podporou hlavních formátů. GitHub Packages — vestavěný registr v GitHubu, vhodný pro týmy již používající GitHub. GitLab Container Registry — pro obrazy Docker.

Kritéria výběru registru

Hlavní faktory: podporované formáty, licenční model (open-source/enterprise), integrace se stávajícím CI/CD, možnost replikace mezi regiony, existence zásad automatického čištění starých verzí a zpráv o shodě.

// Jenkins pipeline — publikace APK v 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)

Verzování a pojmenovávání

Správná strategie verzování artefaktů je klíčová pro reprodukovatelnost sestavení a sledování změn. Bez verzování nelze určit, která verze kódu způsobila problém v produkci.

Semantic Versioning (SemVer)

Standard MAJOR.MINOR.PATCH: MAJOR se mění při nekompatibilních změnách API, MINOR — při přidání zpětně kompatibilní funkcionality, PATCH — při zpětně kompatibilních opravách. Pro CI/CD se k verzi přidávají metadata sestavení: 2.4.1+build.20260703.1. To umožňuje přesně určit, který commit vytvořil konkrétní artefakt a kdy byl vytvořen.

Traceovatelnost — propojení s Git

Každý artefakt by měl obsahovat metadata o svém původu: commit SHA, číslo CI sestavení, název větve, datum sestavení. Tyto informace se zapisují do manifestu artefaktu a umožňují kdykoli rekonstruovat kontext jeho vytvoření. Bez traceovatelnosti se práce s artefakty mění v hádání verzí, což je nepřijatelné pro produkční systémy s požadavky na audit.

Pojmenovávání artefaktů

Konvence názvu: {project}-{module}-{version}.{ext}. Například: `messaging-sdk-2.4.1.aar` nebo `app-release-2.4.1.apk`. Build server může automaticky generovat verzi na základě Gitu tagu nebo čísla CI sestavení.

• Používejte Git tag jako zdroj verze — spojuje artefakt s konkrétním stavem kódu
• Přidávejte commit SHA do metadat pro přesnou identifikaci při ladění
• Nastavte zásady uchovávání — uchovávejte posledních N verzí, zbytek archivujte

Snapshot vs Release

V registrech artefaktů Maven/Gradle se rozlišují release verze (pevné, neměnné) a snapshot verze (aktuální vývoj, lze přepsat). V CI/CD pipeline jsou snapshot artefakty vhodné pro vývoj, ale v produkci by se měly používat pouze release verze.

Bezpečnost artefaktů

Artefakty — klíčový prvek dodavatelského řetězce softwaru (software supply chain). Kompromitace artefaktu může vést k proniknutí škodlivého kódu do produkce. Bezpečnost artefaktů zahrnuje několik úrovní ochrany.

Podepisování artefaktů

Soubory APK se podepisují pomocí jarsigner nebo apksigner; IPA — certifikátem Apple; obrazy Docker — Content Trust (Notary) od Dockeru. Podpis zaručuje integritu a potvrzuje autora artefaktu. CI/CD pipeline by měl zahrnovat ověření podpisů všech závislostí třetích stran.

Skenování zranitelností

Před zveřejněním je artefakt kontrolován automatickými skenery: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Analyzují zahrnuté závislosti, verze použitých knihoven a známé zranitelnosti CVE. Při detekci kritické zranitelnosti je vydání okamžitě blokováno, dokud není opraveno vývojáři.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — bezpečnostní rámec definující úrovně důvěry od SLSA 1 (základní) po SLSA 4 (maximální). Build server musí generovat provenance attestation — kryptograficky podepsané osvědčení o tom, jak a z jakého kódu byl artefakt sestaven.