Artifact no desenvolvimento de aplicações: o que é, tipos e como gerir

O que é um Artifact no desenvolvimento

Um artifact (artefacto de compilação) é o resultado da compilação do código fonte, pronto para implementação ou uso como dependência. O processo de compilação transforma ficheiros fonte (Java, Kotlin, Swift, C++ e outros) em pacotes binários que podem ser executados num dispositivo ou servidor alvo.

O conceito de artefacto vai além de ficheiros executáveis. Por exemplo, uma biblioteca JAR é um artefacto usado como dependência noutros projetos. Uma imagem Docker é um artefacto que contém a aplicação e o seu ambiente. Até um relatório de cobertura de testes pode ser considerado um artefacto no contexto de CI/CD.

O desenvolvimento moderno em grandes empresas envolve a gestão de centenas de milhares de artefactos. Google DORA liga a maturidade da gestão de artefactos à eficácia geral do DevOps — equipas que usam registos de artefactos lançam versões mais rápido e encontram menos problemas de implementação.

Ciclo de vida do artefacto

Cada artefacto passa por várias etapas: criação (compilação), validação (testes, verificações de segurança), armazenamento (registo de artefactos), distribuição (publicação para descarga) e arquivo ou eliminação (quando a versão se torna obsoleta).

Tipos de artefactos no desenvolvimento móvel

Diferentes plataformas e tecnologias geram diferentes formatos de artefactos. Compreender os formatos é essencial para configurar corretamente o pipeline CI/CD e escolher um sistema de armazenamento.

Artefactos Android

APK (Android Package Kit) é o formato tradicional de pacote de instalação. AAB (Android App Bundle) é um formato moderno para publicação no Google Play, contendo apenas os recursos necessários para um dispositivo específico. AAB reduz o tamanho da aplicação instalada em média 15-20% em comparação com um APK universal.

Artefactos iOS

IPA (iOS App Store Package) é um arquivo com código e recursos para dispositivos iOS. XCArchive é um artefacto intermédio criado pelo Xcode, a partir do qual o IPA final é exportado. dSYM é um ficheiro de símbolos de depuração necessário para a simbolização de registos de falhas.

Artefactos de projetos de servidor e bibliotecas

JAR (Java ARchive) — para bibliotecas Java/Kotlin. AAR (Android ARchive) — para bibliotecas Android com recursos. Imagens Docker — artefactos de contentores para microsserviços. Cada tipo tem o seu próprio registo e regras de gestão de versões.

Artefactos no pipeline CI/CD

Os artefactos são a ligação entre as etapas do pipeline. Cada etapa consome artefactos da anterior e produz novos. Compreender este fluxo é fundamental para configurar um pipeline CI/CD eficaz.

Fluxo de artefactos no pipeline

Um fluxo típico inclui: commit -> o servidor de compilação compila o código e cria um artefacto não otimizado -> o artefacto de teste é usado para executar testes -> em caso de sucesso, é criado um artefacto de lançamento -> é assinado e publicado no registo de artefactos -> o artefacto é obtido do registo para implementação em staging e produção. Cada transição entre etapas é acompanhada por uma verificação de integridade e conformidade com requisitos.

Artefactos intermédios e finais

O pipeline pode criar múltiplos artefactos em diferentes etapas. Os artefactos de depuração contêm informação de depuração, os não otimizados são compilados rapidamente para testes, os artefactos de lançamento são finais, com otimização e ofuscação. O sistema CI deve ser capaz de os distinguir e aplicar políticas de retenção adequadas para cada 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 distinguir entre cache de dependências e artefactos de compilação. Cache (cache do Gradle, cache do CocoaPods) acelera compilações repetidas mas não se destina à implementação. Os artefactos são o produto final, prontos para distribuição. Defina um TTL de vários dias para a cache e de semanas ou meses para os artefactos.

Repositórios de artefactos

Os artefactos não devem ser armazenados no servidor de compilação — existem sistemas especializados para este fim. Um Repository Manager fornece armazenamento centralizado, indexação, controlo de acesso e integração com ferramentas CI/CD.

Registos de artefactos populares

JFrog Artifactory — um gestor universal que suporta Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — uma alternativa de código aberto que suporta os principais formatos. GitHub Packages — um registo integrado no GitHub, conveniente para equipas que já usam GitHub. GitLab Container Registry — para imagens Docker.

Critérios de seleção do registo

Fatores-chave: formatos suportados, modelo de licenciamento (código aberto/empresarial), integração com CI/CD existente, capacidades de replicação entre regiões, disponibilidade de políticas de limpeza automática de versões antigas e relatórios de conformidade.

// Jenkins pipeline — publicação de APK no 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

Uma estratégia adequada de versionamento de artefactos é fundamental para a reprodutibilidade de compilações e rastreio de alterações. Sem versionamento, é impossível determinar que versão do código causou um problema em produção.

Versionamento Semântico (SemVer)

O padrão MAJOR.MINOR.PATCH: MAJOR muda com alterações incompatíveis na API, MINOR com adições de funcionalidade compatíveis com versões anteriores, PATCH com correções de erros compatíveis com versões anteriores. Para CI/CD, são adicionados metadados de compilação à versão: 2.4.1+build.20260703.1. Isto permite determinar exatamente que commit produziu um artefacto específico e quando foi criado.

Rastreabilidade — ligação Git

Cada artefacto deve conter metadados sobre a sua origem: SHA do commit, número de compilação CI, nome do ramo, data de compilação. Esta informação é registada no manifesto do artefacto e permite reconstruir o contexto da sua criação em qualquer momento. Sem rastreabilidade, trabalhar com artefactos torna-se adivinhar versões, o que é inaceitável para sistemas de produção com requisitos de auditoria.

Nomenclatura de artefactos

Convenção de nome: {project}-{module}-{version}.{ext}. Por exemplo: messaging-sdk-2.4.1.aar ou app-release-2.4.1.apk. O servidor de compilação pode gerar automaticamente uma versão com base numa etiqueta Git ou no número de compilação do sistema CI.

• Use a etiqueta Git como fonte de versão — isto liga o artefacto a um estado de código específico
• Adicione o SHA do commit aos metadados para identificação precisa durante a depuração
• Configure a política de retenção — mantenha as últimas N versões, arquive o resto

Snapshot vs Release

Nos registos de artefactos Maven/Gradle, distinguem-se versões de lançamento (fixas, imutáveis) e versões snapshot (desenvolvimento atual, podem ser sobrescritas). Nos pipelines CI/CD, os artefactos snapshot são convenientes para desenvolvimento, mas em produção apenas devem ser usadas versões de lançamento.

Segurança dos artefactos

Os artefactos são um elemento-chave da cadeia de fornecimento de software. O comprometimento de um artefacto pode levar à entrada de código malicioso em produção. A segurança dos artefactos inclui vários níveis de proteção.

Assinatura de artefactos

Os ficheiros APK são assinados com jarsigner ou apksigner; os IPA são assinados com um certificado Apple; as imagens Docker são assinadas com Content Trust (Notary) da Docker. A assinatura garante a integridade e confirma o autor do artefacto. O pipeline CI/CD deve incluir verificação de assinaturas de todas as dependências de terceiros.

Digitalização de vulnerabilidades

Antes da publicação, o artefacto é verificado por scanners automatizados: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Eles analisam as dependências incluídas, as versões das bibliotecas utilizadas e as vulnerabilidades CVE conhecidas. Se for detetada uma vulnerabilidade crítica, o lançamento é bloqueado imediatamente até que os programadores a corrijam.

Níveis de cadeia de fornecimento

SLSA (Supply chain Levels for Software Artifacts) é um framework de segurança que define níveis de confiança desde SLSA 1 (básico) até SLSA 4 (máximo). O servidor de compilação deve gerar uma atestação de proveniência — uma declaração assinada criptograficamente sobre como e a partir de que código o artefacto foi criado.