Artifact у развоју апликација: шта је то, врсте и како управљати

Шта је Artifact у развоју

Artifact (артефакт изградње) — резултат компајлирања изворног кода, спреман за распоређивање или коришћење као зависност. Процес изградње претвара изворне датотеке (Java, Kotlin, Swift, C++ и друге) у бинарне пакете који се могу покренути на циљном уређају или серверу.

Појам артефакта превазилази оквире извршних датотека. На пример, JAR библиотека — артефакт који се користи као зависност у другим пројектима. Docker слика — артефакт који садржи апликацију и њено окружење. Чак и извештај о покривености тестовима може се сматрати артефактом у контексту CI/CD.

Савремени развој у великим компанијама укључује управљање стотинама хиљада артефаката. Google DORA повезује зрелост управљања артефактима са укупном ефикасношћу DevOps-а — тимови који користе регистре артефаката брже објављују издања и ређе се сусрећу са проблемима при распоређивању.

Животни циклус артефакта

Сваки артефакт пролази кроз неколико фаза: креирање (изградња, компајлирање), валидација (тестирање, провера безбедности), складиштење (регистар артефаката), дистрибуција (објављивање за преузимање) и архивирање или брисање (када верзија застари).

Врсте артефаката у мобилном развоју

Различите платформе и технологије генеришу различите формате артефаката. Разумевање формата неопходно је за правилно подешавање CI/CD пајплајна и избор система за складиштење.

Android артефакти

APK (Android Package Kit) — традиционални формат инсталационог пакета. AAB (Android App Bundle) — модерни формат за објављивање у Google Play-у, који садржи само ресурсе потребне одређеном уређају. AAB смањује величину инсталиране апликације у просеку за 15-20% у поређењу са универзалним APK-ом.

iOS артефакти

IPA (iOS App Store Package) — архива са кодом и ресурсима за iOS уређаје. XCArchive — међуартефакт који креира Xcode, из кога се извози финални IPA. dSYM — датотека за отклањање грешака неопходна за символизацију crash логова.

Артефакти серверских и библиотечких пројеката

JAR (Java ARchive) — за Java/Kotlin библиотеке. AAR (Android ARchive) — за Android библиотеке са ресурсима. Docker слике — контејнерски артефакти за микросервисе. Сваки тип има свој регистар и правила управљања верзијама.

Артефакти у CI/CD пајплајну

Артефакти — спона између фаза пајплајна. Свака фаза троши артефакте претходне и производи нове. Разумевање овог тока је кључно за подешавање ефикасног CI/CD-а.

Ток артефаката у пајплајну

Типичан ток укључује: commit → сервер за изградњу компајлира код и креира неоптимизовани артефакт → тест артефакт се користи за покретање тестова → при успеху се креира релизни артефакт → потписује се и објављује у регистру артефаката → из регистра се артефакт преузима за распоређивање на staging и production. Сваки прелаз између фаза прати провера интегритета и усклађености са захтевима.

Међуартефакти и финални артефакти

Пајплајн може креирати више артефаката у различитим фазама. Debug артефакти садрже информације за отклањање грешака, неоптимизовани — брзо се склапају за тестове, релизни артефакти — коначни, са оптимизацијом и обфускацијом. CI систем мора да их разликује и примењује одговарајуће политике складиштења за сваки тип.

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

Важно је разликовати кеш зависности и артефакте изградње. Кеш (Gradle cache, CocoaPods cache) убрзава поновне изградње, али није намењен за распоређивање. Артефакти — коначни производ спреман за дистрибуцију. За кеш поставите TTL од неколико дана, за артефакте — недеље или месеце.

Складишта артефаката

Артефакти не би требало да се чувају на серверу за изградњу — за то постоје специјализовани системи. Repository Manager обезбеђује централизовано складиштење, индексирање, контролу приступа и интеграцију са CI/CD алатима.

Популарни регистри артефаката

JFrog Artifactory — универзални менаџер који подржава Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — open-source алтернатива са подршком за главне формате. GitHub Packages — уграђени регистар у GitHub-у, погодан за тимове који већ користе GitHub. GitLab Container Registry — за Docker слике.

Критеријуми за избор регистра

Главни фактори: подржани формати, модел лиценцирања (open-source/enterprise), интеграција са постојећим CI/CD, могућност репликације између региона, постојање политика аутоматског чишћења старих верзија и compliance извештаја.

// Jenkins pipeline — објављивање APK-а у 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)

Верзионисање и именовање

Правилна стратегија верзионисања артефаката је кључна за репродуцибилност изградњи и праћење промена. Без верзионисања немогуће је утврдити која верзија кода је изазвала проблем у продукцији.

Semantic Versioning (SemVer)

Стандард MAJOR.MINOR.PATCH: MAJOR се мења при некомпатибилним променама API-ја, MINOR — при додавању уназад компатибилне функционалности, PATCH — при уназад компатибилним исправкама. За CI/CD верзији се додају метаподаци изградње: 2.4.1+build.20260703.1. Ово омогућава прецизно одређивање који commit је створио одређени артефакт и када је направљен.

Повезивање са Git-ом (Traceability)

Сваки артефакт треба да садржи метаподатке о свом пореклу: commit SHA, број CI изградње, име гране, датум изградње. Ове информације се уписују у манифест артефакта и омогућавају да се у било ком тренутку реконструише контекст његовог настанка. Без traceability-ja рад са артефактима постаје погађање верзија, што је неприхватљиво за продукционе системе са захтевима за ревизију.

Именовање артефаката

Конвенција имена: {project}-{module}-{version}.{ext}. На пример: `messaging-sdk-2.4.1.aar` или `app-release-2.4.1.apk`. Сервер за изградњу може аутоматски генерисати верзију на основу Git tag-а или броја CI изградње.

• Користите Git tag као извор верзије — то повезује артефакт са одређеним стањем кода
• Додајте commit SHA у метаподатке за прецизну идентификацију у фази отклањања грешака
• Подесите политику задржавања — чувајте последњих N верзија, остало архивирајте

Snapshot vs Release

У регистрима артефаката Maven/Gradle разликују се release верзије (фиксне, непроменљиве) и snapshot верзије (тренутни развој, могу се преписивати). У CI/CD пајплајновима snapshot артефакти су погодни за развој, али у продукцији треба користити само release верзије.

Безбедност артефаката

Артефакти — кључни елемент ланца снабдевања софтвером (software supply chain). Компромитација артефакта може довести до уношења злонамерног кода у продукцију. Безбедност артефаката укључује неколико нивоа заштите.

Потписивање артефаката

APK датотеке се потписују са jarsigner или apksigner; IPA — Apple сертификатом; Docker слике — Content Trust (Notary) од Docker-а. Потпис гарантује интегритет и потврђује аутора артефакта. CI/CD пајплајн треба да укључује проверу потписа свих спољних зависности.

Скенирање рањивости

Пре објављивања, артефакт се проверава аутоматским скенерима: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Они анализирају укључене зависности, верзије коришћених библиотека и познате CVE рањивости. При откривању критичне рањивости, издање се одмах блокира до њеног отклањања од стране програмера.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — безбедносни оквир који дефинише нивое поверења од SLSA 1 (основни) до SLSA 4 (максимални). Сервер за изградњу мора да генерише provenance attestation — криптографски потписано сведочанство о томе како и из ког кода је направљен артефакт.