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.

Потік артефактів у пайплайні

Типовий потік включає: комміт -> build-сервер компілює код і створює неоптимізований артефакт -> тестовий артефакт використовується для прогону тестів -> при успіху створюється релізний артефакт -> він підписується і публікується в артефактному реєстрі -> з реєстру артефакт забирається для деплою в staging та production. Кожен перехід між етапами супроводжується перевіркою цілісності та відповідності вимогам.

Проміжні та фінальні артефакти

Пайплайн може створювати кілька артефактів на різних етапах. Debug-артефакти містять налагоджувальну інформацію, unoptimized — збираються швидко для тестів, release-артефакти — фінальні, з оптимізацією та обфускацією. 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 у кілька днів, для артефактів — тижні або місяці.

Сховища артефактів

Артефакти не повинні зберігатися на build-сервері — для цього існують спеціалізовані системи. 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 до версії додають build-метадані: 2.4.1+build.20260703.1. Це дозволяє точно визначити, який комміт породив конкретний артефакт і коли він був створений.

Traceability зв'язок з Git

Кожен артефакт повинен містити метадані про його походження: commit SHA, номер CI-збірки, ім'я гілки, дату збірки. Ця інформація записується в маніфест артефакту і дозволяє в будь-який момент відновити контекст його створення. Без traceability робота з артефактами перетворюється на вгадування версій, що неприпустимо для production-систем з вимогами до аудиту.

Іменування артефактів

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

• Використовуйте Git tag як джерело версії — це пов'язує артефакт з конкретним станом коду
• Додавайте commit SHA в метадані для точної ідентифікації на етапі налагодження
• Налаштуйте політику retention — зберігайте останні 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 (максимальний). Build-сервер повинен генерувати provenance attestation — криптографічно підписане свідчення про те, як і з якого коду було зібрано артефакт.