O Que é um Build Artifact Repository? Onde as Saídas de Build Vivem
Um build artifact repository é um store versionado para as saídas de um build, container images, pacotes, JARs, para que possam ser deployadas e reusadas de forma confiável.
Uma vez que o CI produz um build, esse artifact tem de viver em algum lugar endereçável para que deploys, jobs downstream e rollbacks possam buscar exatamente os mesmos bytes. Um build artifact repository é esse store. É o que faz o princípio build-once, deploy-many funcionar, e o que garante que a coisa que você testou é a coisa que você shipa.
O que ele armazena
Saídas compiladas e empacotadas: container images, pacotes de linguagem, binários, libraries, cada um tagueado com uma versão ou hash de conteúdo. Exemplos incluem container registries, registries npm ou Maven, e stores de artifact genéricos.
Por que é central para o CI/CD
- Build once, deploy many: cada ambiente puxa o mesmo artifact.
- Reprodutibilidade: uma versão mapeia para bytes exatos.
- Rollback: redeployar um artifact anterior instantaneamente.
- Compartilhamento: jobs downstream e times consomem builds publicados.
Build once, deploy everywhere
Em vez de rebuildar por ambiente, você builda um artifact imutável, publica-o, e promove esse mesmo artifact do staging à produção. O repository é o que o mantém entre build e deploy, eliminando a classe de bug "rebuildado e agora difere".
Imutabilidade e identidade
Artifacts devem ser imutáveis: uma dada versão sempre se refere aos mesmos bytes. Identificadores content-addressed, como um image digest, tornam essa garantia criptográfica, então você pode provar que o artifact deployado corresponde ao testado.
Retenção e proveniência
Repositories também cuidam de retenção (por quanto tempo manter artifacts antigos) e cada vez mais de proveniência (um registro assinado de como um artifact foi construído). Ambos alimentam verificações de supply-chain security que as pipelines rodam antes do deploy.
Puxando artifacts nos runners
Todo deploy e muitos passos de build puxam do artifact repository, então a latência do registry afeta a velocidade da pipeline. Runners gerenciados com camadas em cache e retry em erros transitórios de registry (como o Latchkey provê) mantêm esses pulls rápidos e confiáveis.
Principais conclusões
- Um build artifact repository é um store versionado para saídas de build.
- Ele viabiliza build-once-deploy-many, releases reproduzíveis e rollback instantâneo.
- Artifacts imutáveis e content-addressed provam que o build deployado corresponde ao testado.