APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma pipeline deve permitir responder a três perguntas: o que foi construído, o que foi testado e o que será executado. O hash do commit identifica código, mas não todas as entradas do build. Dependências variáveis, ferramentas e configuração podem produzir um binário diferente numa recompilação. Promove artefactos identificados e testados, separando configuração de ambiente e segredos. Conserva relatórios ligados à versão efetiva. Um comando de testes que mascara falhas com um código de saída de sucesso destrói o gate, mesmo quando o relatório documenta erros. A recolha de relatórios deve preservar a falha que determina se a promoção pode continuar.
Aplicação guiada
No CodeBuild, obter um segredo por integração apropriada evita colocá-lo em configuração visível, mas não torna qualquer log seguro. Uma transformação do valor pode escapar à máscara por correspondência exata. Não imprimas segredos nem variantes. Entre contas, separa assumir a role e aceder ao artefacto: a origem precisa de autorização sts:AssumeRole e o destino de trust adequada; S3, KMS e outros limites continuam a ser avaliados. Uma pipeline na conta A não suporta simplesmente passar um artefacto produzido em B para C quando ambas as ações estão fora de A. Confirma o fluxo suportado antes de aumentar permissões. Por fim, uma aprovação manual expirada é falha, não aceitação tácita. A API atual permite configurar o timeout; regista o valor efetivo.
O checksum mudou depois de QA. O responsável pela mudança precisa de evidência sobre o novo binário ou de promover o artefacto já validado.
Armadilhas comuns
Commit como binário; segredo codificado como seguro; notificação como aprovação; permissões excessivas para contornar uma limitação do serviço.
Tópicos relacionados: Entrega progressiva e rollback · IaC, drift e reconciliação
Liga identidade, evidência e autorização ao objeto realmente promovido.
Referência: DOP-C02 domain 1 · DOP-C02