Artifact nello sviluppo di applicazioni: cos'è, tipi e come gestirlo

Cos'è un Artifact nello sviluppo

Un artifact (artefatto di build) è il risultato della compilazione del codice sorgente, pronto per la distribuzione o l'uso come dipendenza. Il processo di build trasforma i file sorgente (Java, Kotlin, Swift, C++ e altri) in pacchetti binari che possono essere eseguiti su un dispositivo o server target.

Il concetto di artefatto va oltre i file eseguibili. Ad esempio, una libreria JAR è un artefatto utilizzato come dipendenza in altri progetti. Un'immagine Docker è un artefatto che contiene l'applicazione e il suo ambiente. Anche un rapporto di copertura dei test può essere considerato un artefatto nel contesto CI/CD.

Lo sviluppo moderno nelle grandi aziende implica la gestione di centinaia di migliaia di artefatti. Google DORA collega la maturità della gestione degli artefatti all'efficacia complessiva del DevOps — i team che utilizzano registri di artefatti rilasciano versioni più velocemente e incontrano meno problemi di distribuzione.

Ciclo di vita di un artefatto

Ogni artefatto attraversa diverse fasi: creazione (build, compilazione), validazione (test, controlli di sicurezza), archiviazione (registro artefatti), distribuzione (pubblicazione per download) e archiviazione o eliminazione (quando la versione diventa obsoleta).

Tipi di artefatti nello sviluppo mobile

Piattaforme e tecnologie diverse generano formati di artefatti diversi. Comprendere i formati è essenziale per configurare correttamente la pipeline CI/CD e scegliere un sistema di archiviazione.

Artefatti Android

APK (Android Package Kit) è il formato tradizionale di pacchetto di installazione. AAB (Android App Bundle) è un formato moderno per la pubblicazione su Google Play, che contiene solo le risorse necessarie per un dispositivo specifico. AAB riduce le dimensioni dell'applicazione installata in media del 15-20% rispetto a un APK universale.

Artefatti iOS

IPA (iOS App Store Package) è un archivio con codice e risorse per dispositivi iOS. XCArchive è un artefatto intermedio creato da Xcode, dal quale viene esportato l'IPA finale. dSYM è un file di simboli di debug necessario per la simbolizzazione dei registri di crash.

Artefatti di progetti server e librerie

JAR (Java ARchive) — per librerie Java/Kotlin. AAR (Android ARchive) — per librerie Android con risorse. Immagini Docker — artefatti contenitore per microservizi. Ogni tipo ha il proprio registro e regole di gestione delle versioni.

Artefatti nella pipeline CI/CD

Gli artefatti sono il collegamento tra le fasi della pipeline. Ogni fase consuma artefatti della precedente e ne produce di nuovi. Comprendere questo flusso è fondamentale per impostare una pipeline CI/CD efficace.

Flusso degli artefatti nella pipeline

Un flusso tipico include: commit -> il server di build compila il codice e crea un artefatto non ottimizzato -> l'artefatto di test viene utilizzato per eseguire i test -> in caso di successo, viene creato un artefatto di rilascio -> viene firmato e pubblicato nel registro degli artefatti -> l'artefatto viene prelevato dal registro per la distribuzione in staging e produzione. Ogni transizione tra le fasi è accompagnata da un controllo di integrità e conformità ai requisiti.

Artefatti intermedi e finali

La pipeline può creare più artefatti in fasi diverse. Gli artefatti di debug contengono informazioni di debug, quelli non ottimizzati vengono costruiti rapidamente per i test, gli artefatti di rilascio sono finali, con ottimizzazione e offuscamento. Il sistema CI deve essere in grado di distinguerli e applicare politiche di conservazione appropriate per ogni tipo.

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

È importante distinguere tra cache delle dipendenze e artefatti di build. La cache (cache di Gradle, cache di CocoaPods) accelera le build ripetute ma non è destinata alla distribuzione. Gli artefatti sono il prodotto finale, pronti per la distribuzione. Imposta un TTL di diversi giorni per la cache e di settimane o mesi per gli artefatti.

Repository di artefatti

Gli artefatti non dovrebbero essere memorizzati sul server di build — esistono sistemi specializzati per questo scopo. Un Repository Manager fornisce archiviazione centralizzata, indicizzazione, controllo degli accessi e integrazione con strumenti CI/CD.

Registri di artefatti popolari

JFrog Artifactory — un gestore universale che supporta Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — un'alternativa open source che supporta i formati principali. GitHub Packages — un registro integrato in GitHub, comodo per i team che già utilizzano GitHub. GitLab Container Registry — per immagini Docker.

Criteri di selezione del registro

Fattori chiave: formati supportati, modello di licenza (open source/enterprise), integrazione con CI/CD esistente, capacità di replica tra regioni, disponibilità di politiche di pulizia automatica delle versioni vecchie e report di conformità.

// Pipeline Jenkins — pubblicazione APK in 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)

Versionamento e nomenclatura

Una strategia adeguata di versionamento degli artefatti è fondamentale per la riproducibilità delle build e il tracciamento delle modifiche. Senza versionamento, è impossibile determinare quale versione del codice ha causato un problema in produzione.

Versionamento Semantico (SemVer)

Lo standard MAJOR.MINOR.PATCH: MAJOR cambia con modifiche API incompatibili, MINOR con aggiunte di funzionalità retrocompatibili, PATCH con correzioni di bug retrocompatibili. Per CI/CD, vengono aggiunti metadati di build alla versione: 2.4.1+build.20260703.1. Ciò consente di determinare esattamente quale commit ha prodotto un artefatto specifico e quando è stato creato.

Tracciabilità — collegamento Git

Ogni artefatto dovrebbe contenere metadati sulla sua origine: SHA del commit, numero di build CI, nome del ramo, data di build. Queste informazioni vengono registrate nel manifesto dell'artefatto e consentono di ricostruire il contesto della sua creazione in qualsiasi momento. Senza tracciabilità, lavorare con gli artefatti diventa un'indovinare le versioni, il che è inaccettabile per i sistemi di produzione con requisiti di audit.

Nomenclatura degli artefatti

Convenzione di denominazione: {project}-{module}-{version}.{ext}. Ad esempio: messaging-sdk-2.4.1.aar o app-release-2.4.1.apk. Il server di build può generare automaticamente una versione basata su un tag Git o sul numero di build del sistema CI.

• Usa il tag Git come fonte della versione — questo collega l'artefatto a uno specifico stato del codice
• Aggiungi SHA del commit ai metadati per un'identificazione precisa durante il debug
• Configura la politica di conservazione — mantieni le ultime N versioni, archivia il resto

Snapshot vs Release

Nei registri di artefatti Maven/Gradle, si distinguono versioni di rilascio (fisse, immutabili) e versioni snapshot (sviluppo corrente, possono essere sovrascritte). Nelle pipeline CI/CD, gli artefatti snapshot sono comodi per lo sviluppo, ma in produzione dovrebbero essere utilizzate solo versioni di rilascio.

Sicurezza degli artefatti

Gli artefatti sono un elemento chiave della catena di fornitura del software. La compromissione di un artefatto può portare all'introduzione di codice dannoso in produzione. La sicurezza degli artefatti include diversi livelli di protezione.

Firma degli artefatti

I file APK vengono firmati con jarsigner o apksigner; gli IPA vengono firmati con un certificato Apple; le immagini Docker vengono firmate con Content Trust (Notary) di Docker. La firma garantisce l'integrità e conferma l'autore dell'artefatto. La pipeline CI/CD dovrebbe includere la verifica delle firme di tutte le dipendenze di terze parti.

Scansione delle vulnerabilità

Prima della pubblicazione, l'artefatto viene verificato da scanner automatici: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Analizzano le dipendenze incluse, le versioni delle librerie utilizzate e le vulnerabilità CVE note. Se viene rilevata una vulnerabilità critica, il rilascio viene immediatamente bloccato fino alla sua correzione da parte degli sviluppatori.

Livelli di catena di fornitura

SLSA (Supply chain Levels for Software Artifacts) è un framework di sicurezza che definisce livelli di fiducia da SLSA 1 (base) a SLSA 4 (massimo). Il server di build deve generare un'attestazione di provenienza — una dichiarazione firmata crittograficamente su come e da quale codice l'artefatto è stato costruito.