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 и продукция. Всеки преход между етапите е съпроводен с проверка на цялостността и съответствието с изискванията.

Междинни и крайни артефакти

Пайплайнът може да създава множество артефакти на различни етапи. 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 — алтернатива с отворен код с поддръжка на основните формати. GitHub Packages — вграден регистър в GitHub, удобен за екипи, които вече използват GitHub. GitLab Container Registry — за Docker образи.

Критерии за избор на регистър

Основни фактори: поддържани формати, модел на лицензиране (open-source/enterprise), интеграция със съществуващия CI/CD, възможност за репликация между региони, наличие на политики за автоматично почистване на стари версии и отчети за съответствие.

// 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

Всеки артефакт трябва да съдържа метаданни за своя произход: commit SHA, номер на CI компилация, име на клон, дата на компилация. Тази информация се записва в манифеста на артефакта и позволява по всяко време да се реконструира контекстът на неговото създаване. Без проследимост работата с артефакти се превръща в познаене на версии, което е недопустимо за продукционни системи с изисквания за одит.

Именуване на артефакти

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

• Използвайте Git таг като източник на версия — това свързва артефакта с конкретно състояние на кода
• Добавете 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 уязвимости. При откриване на критична уязвимост пускането на версията се блокира незабавно до отстраняването ѝ от разработчиците.

Нива на веригата за доставка

SLSA (Supply chain Levels for Software Artifacts) — рамка за сигурност, която определя нива на доверие от SLSA 1 (основно) до SLSA 4 (максимално). Сървърът за компилация трябва да генерира provenance attestation — криптографски подписано свидетелство за това как и от какъв код е компилиран артефактът.