APRENDER. PRATICAR. EVOLUIR.Distinguir execução e efeito
Num serviço fictício de fecho de posições, duas releases partilham o mesmo destino. A mais recente termina primeiro, mas a anterior escreve depois e repõe código antigo. O problema não se resolve olhando apenas para a ordem dos commits. Desenha a passagem desde o evento de origem até ao efeito no serviço: revisão obtida, entradas do build, artefacto produzido, validação, aprovação e operação de deployment. Regista identificadores que permitam relacionar cada etapa. A pipeline coordena tarefas, mas os serviços envolvidos têm estados próprios. Durante um incidente, distingue a execução que deixou de avançar de uma tarefa externa que ainda pode concluir ou produzir alterações. Essa distinção determina se uma segunda intervenção seria concorrente.
Escolher concorrência por requisito
SUPERSEDED permite que uma execução mais recente ultrapasse outra em espera entre stages; não cancela automaticamente a ação que já ocupa um stage. QUEUED preserva a ordem de processamento, enquanto PARALLEL permite execuções independentes. A escolha depende de ser aceitável omitir revisões intermédias e de o destino tolerar concorrência. Uma fila numa pipeline não é um bloqueio global sobre todas as pipelines da organização. Confirma também limitações de recuperação: stage rollback não está disponível em PARALLEL. Para CodeCommit nesse modo, o evento que iniciou a execução pode não corresponder ao HEAD obtido quando a ação de origem arranca. Um source revision override e a conferência da revisão efetiva tornam explícito o conteúdo a processar.
Interromper com estado conhecido
Stop and wait deixa terminar as ações em curso e impede as seguintes nessa execução. Stop and abandon deixa de aguardar a conclusão da ação, mas não garante cancelamento no fornecedor. Se CloudFormation continua UPDATE_IN_PROGRESS, a equipa ainda tem uma operação para acompanhar. Conserva eventos e identidade da alteração; controla novos arranques sobre o mesmo destino; avalia cancelamento ou recuperação através do mecanismo suportado pelo serviço. Evita descrever Stopped como rollback concluído. No comité ou na passagem de turno, apresenta separadamente a progressão da pipeline, o estado do fornecedor e o resultado funcional. Assim, quem assume a intervenção sabe o que está confirmado e o que ainda pode mudar.
Preservar a falha e a evidência
Um gate de testes precisa de conhecer o conjunto executado e o resultado, não apenas encontrar um ficheiro de relatório. Se um filtro reduz 240 casos a doze, 100% de sucesso pode deixar de cobrir a aceitação. Liga os resultados ao artefacto exato. Em CodeBuild, finally permite recolher diagnóstico após falha; o sucesso dessa recolha não transforma por si a fase anterior em sucesso. Revê também o compute usado: on-failure não tem suporte em compute Lambda nem reserved capacity segundo a referência consultada. Uma mudança de motor exige revalidar recuperação, permissões e captura de evidência, em vez de transportar configurações sem confirmar o seu efeito.
Conferir entradas e pacote
Variáveis efetivas podem diferir do ficheiro versionado: o pedido de arranque CodeBuild prevalece sobre o projeto, que prevalece sobre o buildspec. Por isso, uma aprovação baseada apenas no repositório pode omitir configuração usada na execução. No buildspec 0.1, comandos usam shells separadas; a versão 0.2 permite manter o contexto entre comandos. Trata essa diferença como semântica de execução. Inspeciona ainda o pacote: discard-paths em yes remove a estrutura de diretórios do artefacto. Se o serviço espera config/app.yml, um ficheiro achatado não é equivalente. Testa a unidade que será promovida, com configuração identificada, evitando tratar sucesso de compilação como prova de instalação correta.
Exercitar a decisão de promoção
O modelo local compara a identidade aprovada com a produzida e verifica se os testes obrigatórios pertencem ao conjunto aprovado. No exemplo, unit e duplicate-effect são obrigatórios; uma execução que reporta apenas unit é recusada, mesmo sem falhas. O código não chama AWS nem substitui um gate real: faltam autorização, integridade dos resultados e controlo de concorrência. Usa-o para discutir o contrato antes de o implementar. Para stage rollback, confirma sucesso anterior elegível na versão estrutural atual e valida compatibilidade do código antigo com os dados atuais. A conclusão operacional combina artefacto, estado e evidência funcional; nenhum indicador isolado demonstra os três.
def promotion_allowed(approved_digest, built_digest, required, passed):
return approved_digest == built_digest and required <= passed
required = {'unit', 'duplicate-effect'}
assert not promotion_allowed('r17', 'r17', required, {'unit'})
assert not promotion_allowed('r17', 'r18', required, required)
assert promotion_allowed('r17', 'r17', required, required)
# Original local model; no AWS calls, authorization, signature validation or concurrency control.Caso fictício: um worker passa doze testes, mas o filtro omitiu a repetição segura exigida pelo negócio; o gate fica pendente.
Armadilhas comuns
Confundir Stopped com cancelamento externo, percentagem com cobertura, evento com revisão efetiva e rollback de stage com reversão de dados.
Tópicos relacionados: CloudFormation: retenção e recuperação de estado
Antes de promover ou repetir, confirma a revisão, o conjunto validado e o estado das operações que ainda podem alterar o destino.
Referência: CodePipeline execution semantics · DOP-C02