Artifact w tworzeniu aplikacji: co to jest, typy i jak zarządzać

Czym jest Artifact w tworzeniu aplikacji

Artifact (artefakt kompilacji) — to wynik kompilacji kodu źródłowego, gotowy do wdrożenia lub użycia jako zależność. Proces kompilacji przekształca pliki źródłowe (Java, Kotlin, Swift, C++ i inne) w pakiety binarne, które można uruchomić na urządzeniu docelowym lub serwerze.

Pojęcie artefaktu wykracza poza pliki wykonywalne. Na przykład biblioteka JAR — to artefakt używany jako zależność w innych projektach. Obraz Docker — artefakt zawierający aplikację i jej środowisko. Nawet raport pokrycia testami może być uważany za artefakt w kontekście CI/CD.

Nowoczesne tworzenie oprogramowania w dużych firmach obejmuje zarządzanie setkami tysięcy artefaktów. Google DORA łączy dojrzałość zarządzania artefaktami z ogólną efektywnością DevOps — zespoły korzystające z rejestrów artefaktów szybciej wydają wydania i rzadziej napotykają problemy podczas wdrożeń.

Cykl życia artefaktu

Każdy artefakt przechodzi kilka etapów: tworzenie (kompilacja), walidacja (testowanie, kontrola bezpieczeństwa), przechowywanie (rejestr artefaktów), dystrybucja (publikacja do pobrania) oraz archiwizacja lub usunięcie (gdy wersja staje się przestarzała).

Typy artefaktów w tworzeniu aplikacji mobilnych

Różne platformy i technologie generują różne formaty artefaktów. Znajomość formatów jest niezbędna do prawidłowej konfiguracji pipeline CI/CD i wyboru systemu przechowywania.

Artefakty Android

APK (Android Package Kit) — tradycyjny format pakietu instalacyjnego. AAB (Android App Bundle) — nowoczesny format do publikacji w Google Play, zawierający tylko te zasoby, które są potrzebne konkretnemu urządzeniu. AAB zmniejsza rozmiar instalowanej aplikacji średnio o 15-20% w porównaniu z uniwersalnym APK.

Artefakty iOS

IPA (iOS App Store Package) — archiwum z kodem i zasobami dla urządzeń iOS. XCArchive — pośredni artefakt tworzony przez Xcode, z którego eksportowany jest finalny IPA. dSYM — plik debugowania niezbędny do symbolizacji crash-logów.

Artefakty projektów serwerowych i bibliotecznych

JAR (Java ARchive) — dla bibliotek Java/Kotlin. AAR (Android ARchive) — dla bibliotek Androida z zasobami. Obrazy Docker — artefakty kontenerowe dla mikrousług. Każdy typ ma swój rejestr i zasady zarządzania wersjami.

Artefakty w pipeline CI/CD

Artefakty — łącznik między etapami pipeline. Każdy etap zużywa artefakty poprzedniego i produkuje nowe. Zrozumienie tego przepływu jest kluczowe dla konfiguracji efektywnego CI/CD.

Przepływ artefaktów w pipeline

Typowy przepływ obejmuje: commit → serwer kompilacji kompiluje kod i tworzy niezoptymalizowany artefakt → artefakt testowy jest używany do uruchomienia testów → po sukcesie tworzony jest artefakt wydaniowy → jest podpisywany i publikowany w rejestrze artefaktów → z rejestru artefakt jest pobierany do wdrożenia na staging i produkcję. Każdemu przejściu między etapami towarzyszy weryfikacja integralności i zgodności z wymaganiami.

Artefakty pośrednie i końcowe

Pipeline może tworzyć kilka artefaktów na różnych etapach. Artefakty debug zawierają informacje debugowania, niezoptymalizowane — są kompilowane szybko do testów, artefakty wydaniowe — końcowe, z optymalizacją i zaciemnianiem. System CI musi umieć je rozróżniać i stosować odpowiednie polityki przechowywania dla każdego typu.

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

Ważne jest rozróżnienie pamięci podręcznej zależności i artefaktów kompilacji. Pamięć podręczna (Gradle cache, CocoaPods cache) przyspiesza wielokrotne kompilacje, ale nie jest przeznaczona do wdrożenia. Artefakty — końcowy produkt gotowy do dystrybucji. Dla pamięci podręcznej ustawiaj TTL na kilka dni, dla artefaktów — tygodnie lub miesiące.

Repozytoria artefaktów

Artefakty nie powinny być przechowywane na serwerze kompilacji — do tego istnieją wyspecjalizowane systemy. Repository Manager zapewnia scentralizowane przechowywanie, indeksację, kontrolę dostępu i integrację z narzędziami CI/CD.

Popularne rejestry artefaktów

JFrog Artifactory — uniwersalny menedżer obsługujący Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — alternatywa open-source z obsługą głównych formatów. GitHub Packages — wbudowany rejestr w GitHub, wygodny dla zespołów już korzystających z GitHub. GitLab Container Registry — dla obrazów Docker.

Kryteria wyboru rejestru

Główne czynniki: obsługiwane formaty, model licencjonowania (open-source/enterprise), integracja z istniejącym CI/CD, możliwość replikacji między regionami, obecność polityk automatycznego czyszczenia starych wersji i raportów compliance.

// Pipeline Jenkinsa — publikacja APK w 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)

Wersjonowanie i nazewnictwo

Prawidłowa strategia wersjonowania artefaktów jest kluczowa dla odtwarzalności kompilacji i śledzenia zmian. Bez wersjonowania nie można określić, która wersja kodu spowodowała problem na produkcji.

Semantic Versioning (SemVer)

Standard MAJOR.MINOR.PATCH: MAJOR zmienia się przy niekompatybilnych zmianach API, MINOR — przy dodawaniu wstecznie kompatybilnej funkcjonalności, PATCH — przy wstecznie kompatybilnych poprawkach. Dla CI/CD do wersji dodaje się metadane kompilacji: 2.4.1+build.20260703.1. Pozwala to dokładnie określić, który commit wygenerował konkretny artefakt i kiedy został utworzony.

Traceability — powiązanie z Git

Każdy artefakt powinien zawierać metadane o swoim pochodzeniu: commit SHA, numer kompilacji CI, nazwę gałęzi, datę kompilacji. Te informacje są zapisywane w manifeście artefaktu i pozwalają w dowolnym momencie odtworzyć kontekst jego utworzenia. Bez traceability praca z artefaktami zamienia się w zgadywanie wersji, co jest niedopuszczalne dla systemów produkcyjnych z wymogami audytu.

Nazewnictwo artefaktów

Konwencja nazwy: {project}-{module}-{version}.{ext}. Na przykład: `messaging-sdk-2.4.1.aar` lub `app-release-2.4.1.apk`. Serwer kompilacji może automatycznie generować wersję na podstawie taga Git lub numeru kompilacji CI.

• Używaj taga Git jako źródła wersji — łączy to artefakt z konkretnym stanem kodu
• Dodawaj commit SHA do metadanych dla precyzyjnej identyfikacji podczas debugowania
• Skonfiguruj politykę retention — przechowuj ostatnie N wersji, resztę archiwizuj

Snapshot vs Release

W rejestrach artefaktów Maven/Gradle rozróżnia się wersje release (stałe, niezmienne) i wersje snapshot (bieżący rozwój, mogą być nadpisywane). W pipeline CI/CD artefakty snapshot są wygodne do tworzenia, ale na produkcji powinny być używane tylko wersje release.

Bezpieczeństwo artefaktów

Artefakty — kluczowy element łańcucha dostaw oprogramowania (software supply chain). Kompromitacja artefaktu może prowadzić do przedostania się złośliwego kodu na produkcję. Bezpieczeństwo artefaktów obejmuje kilka poziomów ochrony.

Podpisywanie artefaktów

Pliki APK są podpisywane za pomocą jarsigner lub apksigner; IPA — certyfikatem Apple; obrazy Docker — Content Trust (Notary) od Docker. Podpis gwarantuje integralność i potwierdza autora artefaktu. Pipeline CI/CD powinien obejmować weryfikację podpisów wszystkich zależności zewnętrznych.

Skanowanie w poszukiwaniu podatności

Przed publikacją artefakt jest sprawdzany przez automatyczne skanery: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Analizują one dołączone zależności, wersje używanych bibliotek i znane podatności CVE. W przypadku wykrycia krytycznej podatności wydanie wydania jest natychmiast blokowane do czasu jej usunięcia przez programistów.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — framework bezpieczeństwa określający poziomy zaufania od SLSA 1 (podstawowy) do SLSA 4 (maksymalny). Serwer kompilacji musi generować provenance attestation — kryptograficznie podpisane świadectwo tego, jak i z jakiego kodu został zbudowany artefakt.