APRENDER. PRATICAR. EVOLUIR.Definir o contrato do build
Um build útil para produção precisa de responder a quatro perguntas: que revisão entrou, que dependências foram usadas, que verificações correram e que artefacto saiu. Numa API fictícia de posições, o branch release avançou entre duas execuções com o mesmo nome. A equipa só consegue comparar resultados quando regista a revisão resolvida e o identificador de cada execução. Para Git suportado, CODEBUILD_RESOLVED_SOURCE_VERSION identifica o commit depois de DOWNLOAD_SOURCE; não assumes que a variável existe para todas as origens. Junta ao registo a configuração do build, entradas relevantes e referência ao artefacto. Um número de build identifica uma execução, mas não demonstra que duas execuções produziram o mesmo conteúdo.
Tratar cache como aceleração recuperável
O build deve continuar correto quando o cache está vazio. Cache local pertence ao host e não é suportado em projetos ligados a VPC; mudar permissões Docker não remove essa limitação. Evita dar ao custom cache o nome de um diretório versionado, porque a ligação ao conteúdo recuperado pode sobrepor as fontes. No cache S3, uma key derivada do lockfile ajuda a separar dependências incompatíveis; para partilhar, verifica também namespace, paths, bucket e prefixo. Faz um ensaio sem cache e compara os resultados esperados. Se a versão só compila com restos de uma execução anterior, falta uma entrada declarada ou há dependência indevida de estado.
Desenhar o caminho até cada dependência
Antes de mover CodeBuild para VPC, inventaria DNS, registry, origem Git, serviços AWS e destinos de integração. O acesso ao RDS privado não prova saída para um registry público. Uma rota direta para internet gateway não atribui endereço público às ENI do build. Define saída autorizada por NAT ou proxy, ou fornece uma origem interna adequada. Endpoints privados dão acesso aos serviços respetivos; o endpoint CodeBuild não é um proxy genérico para GitHub. Diagnostica por camada: resolução, rota, filtros, TLS, autenticação e autorização. Um UnauthorizedOperation EC2 durante preparação da rede pede revisão das permissões VPC do service role, não alteração dos testes ainda não executados.
Limitar o acesso aos pacotes
Para CodeArtifact, separa obtenção do token, autorização de leitura e configuração do cliente. O principal precisa das permissões de emissão adequadas, incluindo STS; colocar sts:GetServiceBearerToken apenas na resource policy do domínio não resolve essa parte. Numa conta diferente, confirma domain-owner em vez de depender de um nome que pode existir em várias contas. Se o requisito é terminar o token com a sessão assumida, usa a opção de duração que representa o tempo restante, em vez de confiar no valor predefinido. Evita guardar tokens em caches partilhados, logs ou artefactos. O troubleshooting deve conservar IDs e contexto sem divulgar o segredo usado na autenticação.
Aceitar cobertura demonstrada
Uma suite obrigatória não deve ser configurada como falha ignorável num batch. Compara o conjunto de verificações exigidas com resultados concluídos da revisão candidata. INCOMPLETE, ausência de relatório e teste SKIPPED não demonstram execução bem-sucedida. Diferencia uma falha funcional de um problema de recolha; ambos podem impedir a promoção, mas pedem ações distintas. Para revisão posterior, exporta resultados brutos e gere a retenção, porque o relatório CodeBuild expira. Define quem pode ler, alterar e eliminar a evidência. Na passagem a produção, a pergunta útil é se os critérios previstos foram demonstrados, e não se existe pelo menos um painel verde no percurso.
Exercício: localizar a evidência que falta
O modelo local abaixo recebe uma revisão candidata, o inventário de suites obrigatórias e resultados sintéticos. Devolve razões para suspender a aceitação quando falta uma suite, a revisão diverge ou o resultado não é concluído com sucesso. Não consulta CodeBuild, não interpreta XML e não substitui um gate operacional. No exercício, altera autorização para SKIPPED, apaga reconciliação e muda a revisão de contratos. Explica que evidência falta em cada caso e que equipa deve a produzir. Por fim, relaciona a decisão com a janela: adiar pode ser a ação correta se as condições de entrada não puderem ser cumpridas. Uma exceção, quando autorizada, precisa de tratamento próprio e explícito.
# Original local coverage exercise; not a CodeBuild integration.
def missing_evidence(revision, required, results):
reasons = []
for suite in sorted(required):
row = results.get(suite)
if row is None:
reasons.append((suite, "missing"))
elif row["revision"] != revision:
reasons.append((suite, "wrong revision"))
elif row["status"] != "SUCCEEDED":
reasons.append((suite, "not successful"))
return reasons
required = {"contracts", "reconciliation", "authorization"}
good = {s: {"revision": "candidate-42", "status": "SUCCEEDED"} for s in required}
assert missing_evidence("candidate-42", required, good) == []
assert missing_evidence("candidate-42", required, {}) == [(s, "missing") for s in sorted(required)]
bad = {**good, "authorization": {"revision": "candidate-42", "status": "SKIPPED"}}
assert missing_evidence("candidate-42", required, bad) == [("authorization", "not successful")]
old = {**good, "contracts": {"revision": "candidate-41", "status": "SUCCEEDED"}}
assert missing_evidence("candidate-42", required, old) == [("contracts", "wrong revision")]
Um batch verde esconde reconciliação falhada e autorização sem resultado; o gate compara as três suites exigidas com a revisão candidata.
Armadilhas comuns
Tratar cache como fonte; confundir endpoint com proxy; aceitar INCOMPLETE; guardar só o URL de um relatório; ignorar um filho obrigatório.
Tópicos relacionados: Validação de releases e exposição progressiva
A promoção precisa de evidência completa da revisão candidata e de um build que funcione sem estado acidental.
Referência: CodeBuild environment variables · DOP-C02