Artifact în dezvoltarea aplicațiilor: ce este, tipuri și cum să gestionăm

Ce este Artifact în dezvoltare

Artifact (artefact de compilare) — este rezultatul compilării codului sursă, gata pentru implementare sau utilizare ca dependență. Procesul de compilare transformă fișierele sursă (Java, Kotlin, Swift, C++ și altele) în pachete binare care pot fi rulate pe dispozitivul țintă sau server.

Conceptul de artefact depășește limitele fișierelor executabile. De exemplu, biblioteca JAR — este un artefact utilizat ca dependență în alte proiecte. Imaginea Docker — un artefact care conține aplicația și mediul său. Chiar și un raport de acoperire a testelor poate fi considerat un artefact în contextul CI/CD.

Dezvoltarea modernă în companiile mari include gestionarea a sute de mii de artefacte. Google DORA leagă maturitatea gestionării artefactelor de eficiența generală DevOps — echipele care utilizează registre de artefacte lansează versiuni mai rapid și se confruntă mai rar cu probleme la implementare.

Ciclul de viață al unui artefact

Fiecare artefact trece prin mai multe etape: creare (compilare), validare (testare, verificare securitate), stocare (registru de artefacte), distribuire (publicare pentru descărcare) și arhivare sau ștergere (când versiunea devine învechită).

Tipuri de artefacte în dezvoltarea mobilă

Diferite platforme și tehnologii generează formate variate de artefacte. Înțelegerea formatelor este necesară pentru configurarea corectă a pipeline-ului CI/CD și alegerea sistemului de stocare.

Artefacte Android

APK (Android Package Kit) — formatul tradițional de pachet de instalare. AAB (Android App Bundle) — formatul modern pentru publicarea în Google Play, care conține doar resursele necesare unui anumit dispozitiv. AAB reduce dimensiunea aplicației instalate în medie cu 15-20% comparativ cu APK-ul universal.

Artefacte iOS

IPA (iOS App Store Package) — arhivă cu cod și resurse pentru dispozitive iOS. XCArchive — artefact intermediar creat de Xcode, din care se exportă IPA-ul final. dSYM — fișier de depanare necesar pentru simbolizarea logurilor de crash.

Artefacte ale proiectelor server și biblioteci

JAR (Java ARchive) — pentru biblioteci Java/Kotlin. AAR (Android ARchive) — pentru biblioteci Android cu resurse. Imaginile Docker — artefacte container pentru microservicii. Fiecare tip are propriul registru și reguli de gestionare a versiunilor.

Artefacte în pipeline-ul CI/CD

Artefactele — veriga de legătură între etapele pipeline-ului. Fiecare etapă consumă artefactele celei anterioare și produce altele noi. Înțelegerea acestui flux este critică pentru configurarea unui CI/CD eficient.

Fluxul artefactelor în pipeline

Fluxul tipic include: commit → serverul de compilare compilează codul și creează un artefact neoptimizat → artefactul de test este utilizat pentru rularea testelor → la succes se creează un artefact de lansare → este semnat și publicat în registrul de artefacte → din registru artefactul este preluat pentru implementare în staging și producție. Fiecare tranziție între etape este însoțită de verificarea integrității și conformității cu cerințele.

Artefacte intermediare și finale

Pipeline-ul poate crea mai multe artefacte la diferite etape. Artefactele Debug conțin informații de depanare, neoptimizate — sunt compilate rapid pentru teste, artefactele de lansare — finale, cu optimizare și ofuscare. Sistemul CI trebuie să le poată diferenția și să aplice politici de stocare corespunzătoare pentru fiecare tip.

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

Este important să se facă distincția între cache-ul dependențelor și artefactele de compilare. Cache-ul (Gradle cache, CocoaPods cache) accelerează compilările repetate, dar nu este destinat implementării. Artefactele — produsul final gata de distribuire. Pentru cache setați TTL de câteva zile, pentru artefacte — săptămâni sau luni.

Depozite de artefacte

Artefactele nu trebuie stocate pe serverul de compilare — pentru aceasta există sisteme specializate. Repository Manager asigură stocarea centralizată, indexarea, controlul accesului și integrarea cu instrumentele CI/CD.

Registre populare de artefacte

JFrog Artifactory — manager universal care suportă Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — alternativă open-source cu suport pentru formatele principale. GitHub Packages — registru încorporat în GitHub, convenabil pentru echipele care utilizează deja GitHub. GitLab Container Registry — pentru imagini Docker.

Criterii de selecție a registrului

Factorii principali: formatele suportate, modelul de licențiere (open-source/enterprise), integrarea cu CI/CD existent, posibilitatea de replicare între regiuni, prezența politicilor de curățare automată a versiunilor vechi și rapoartelor de conformitate.

// Pipeline Jenkins — publicare APK în 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)

Versionare și denumire

O strategie corectă de versionare a artefactelor este critică pentru reproductibilitatea compilărilor și urmărirea modificărilor. Fără versionare este imposibil de determinat ce versiune de cod a cauzat o problemă în producție.

Semantic Versioning (SemVer)

Standardul MAJOR.MINOR.PATCH: MAJOR se schimbă la modificări incompatibile ale API, MINOR — la adăugarea de funcționalități compatibile cu versiunile anterioare, PATCH — la remedieri compatibile cu versiunile anterioare. Pentru CI/CD se adaugă metadate de compilare la versiune: 2.4.1+build.20260703.1. Acest lucru permite determinarea exactă a commit-ului care a generat un anumit artefact și când a fost creat.

Traceabilitate — legătura cu Git

Fiecare artefact trebuie să conțină metadate despre originea sa: commit SHA, numărul compilării CI, numele ramurii, data compilării. Aceste informații sunt înregistrate în manifestul artefactului și permit reconstituirea contextului creării sale în orice moment. Fără traceabilitate, lucrul cu artefacte se transformă în ghicirea versiunilor, ceea ce este inacceptabil pentru sistemele de producție cu cerințe de audit.

Denumirea artefactelor

Convenția de denumire: {project}-{module}-{version}.{ext}. De exemplu: `messaging-sdk-2.4.1.aar` sau `app-release-2.4.1.apk`. Serverul de compilare poate genera automat versiunea pe baza tag-ului Git sau a numărului compilării CI.

• Utilizați tag-ul Git ca sursă a versiunii — acesta leagă artefactul de o stare specifică a codului
• Adăugați commit SHA la metadate pentru identificare precisă în etapa de depanare
• Configurați o politică de retenție — păstrați ultimele N versiuni, restul arhivați

Snapshot vs Release

În registrele de artefacte Maven/Gradle se face distincția între versiunile release (fixe, imutabile) și versiunile snapshot (dezvoltare curentă, pot fi suprascrise). În pipeline-urile CI/CD, artefactele snapshot sunt convenabile pentru dezvoltare, dar în producție trebuie utilizate doar versiunile release.

Securitatea artefactelor

Artefactele — element cheie al lanțului de aprovizionare software (software supply chain). Compromiterea unui artefact poate duce la introducerea de cod malițios în producție. Securitatea artefactelor include mai multe niveluri de protecție.

Semnarea artefactelor

Fișierele APK sunt semnate cu jarsigner sau apksigner; IPA — cu certificat Apple; imaginile Docker — cu Content Trust (Notary) de la Docker. Semnătura garantează integritatea și confirmă autorul artefactului. Pipeline-ul CI/CD trebuie să includă verificarea semnăturilor tuturor dependențelor terțe.

Scanarea vulnerabilităților

Înainte de publicare, artefactul este verificat de scanere automate: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Acestea analizează dependențele incluse, versiunile bibliotecilor utilizate și vulnerabilitățile CVE cunoscute. La detectarea unei vulnerabilități critice, lansarea este blocată imediat până la remedierea acesteia de către dezvoltatori.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — cadru de securitate care definește nivelurile de încredere de la SLSA 1 (de bază) la SLSA 4 (maxim). Serverul de compilare trebuie să genereze provenance attestation — o dovadă criptografic semnată despre cum și din ce cod a fost construit artefactul.