Conceito e mecanismo
Um pacote de release precisa de identidade verificável. Liga revisão de código, build, artefacto, configuração, migrações e resultados de testes. Um nome como latest pode mudar entre aprovação e deployment; conserva uma referência estável ao conteúdo e verifica o que foi efetivamente promovido. Builds reproduzíveis dependem de ferramentas e dependências controladas, não apenas da mesma revisão de código. O objetivo é compreender como o artefacto foi produzido e evitar diferenças acidentais entre ambientes. A aprovação de um pacote não se transfere automaticamente para outro recompilado ou alterado. Mantém notas que expliquem alterações, limitações e ligações à evidência relevante, com acesso adequado ao destinatário.
Aplicação guiada
Num exercício fictício, QA aprova o artefacto A, mas o job de produção resolve uma etiqueta para B. Interrompe a promoção e determina qual pacote corresponde à evidência. Não renomeies B para parecer A. Para alterações de base de dados, a documentação EF Core recomenda executar o script revisto, em vez de o voltar a gerar no deployment. Guardar um script de rollback também não garante reconstrução de dados eliminados. Regista versões de configuração e migração juntamente com o binário e confirma compatibilidade entre elas. Se dois pipelines alteram o mesmo ambiente, a rastreabilidade deve incluir ordem real, estado anterior e resultado. Um log de job concluído demonstra execução do job, não aceitação funcional da release.
Aprovação de A com deployment de B deixa a release sem a evidência esperada.
Armadilhas comuns
Etiqueta mutável como identidade; rebuild como mesmo pacote; script gerado depois da revisão.
Tópicos relacionados: Âmbito e coordenação · Prontidão e autorização · Exposição e observação
Promove o conteúdo revisto e conserva a cadeia entre alteração, teste e execução.
Referência: Reproducible builds versioned artifacts and release traceability · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation