APRENDER. PRATICAR. EVOLUIR.Começar pelo mecanismo real
Blue/green descreve coexistência e mudança entre versões, mas não identifica o controlador. ECS tem entrega nativa e um caminho controlado por CodeDeploy; as regras e hooks não são intercambiáveis. Nesta aula, os exemplos ECS que citam AppSpec e deployment group usam explicitamente CODE_DEPLOY. Antes de adaptar um runbook, regista controlador, estratégia, load balancer, alvo de teste, alvo de produção e versão do contrato. Num serviço novo, consulta também o mecanismo nativo atual. Uma restrição do caminho CodeDeploy com NLB não deve ser ensinada como restrição universal do ECS. Esta identificação inicial evita aplicar comandos plausíveis ao objeto que não controla a entrega em curso.
Testar o alvo certo no momento certo
Num serviço CODE_DEPLOY com ALB, dois target groups permitem representar o original e a substituição. O test listener opcional oferece um caminho para o verde antes de mover produção. Não basta obter HTTP 200: confirma que o pedido chegou à revisão candidata e exerceu a dependência alterada. O AppSpec tem de concordar com task definition, container e porta. Se a validação usa o listener de teste, escolhe um hook depois de esse encaminhamento mudar, como AfterAllowTestTraffic. O caso desta aula apresenta um validador que testava o azul; corrigir apenas o estado reportado ao controlador deixaria a release aprovada com evidência da versão errada.
Fechar o protocolo de validação
A Lambda de validação precisa de executar os testes e comunicar o resultado pelo protocolo do CodeDeploy. O retorno normal do handler não substitui PutLifecycleEventHookExecutionStatus com os identificadores do deployment e da execução do hook. A chamada aceita Succeeded ou Failed para o resultado; não uses outro estado do enum geral como aprovação. Regista falhas do callback sem esconder falhas funcionais. Verifica igualmente se o controlador consegue consultar os alarmes. Quando a política exige esse sinal, ignorePollAlarmFailure deve refletir a decisão de parar se a leitura falhar. Uma indisponibilidade de observação não deve ser convertida silenciosamente em autorização para ampliar tráfego.
Distinguir exposição de amostra observada
Um alias ponderado Lambda distribui invocações entre duas versões publicadas compatíveis. Exige o mesmo execution role e configuração DLQ; não aponta a LATEST. O peso exprime probabilidade e pode divergir bastante da proporção observada em pouco tráfego. Segmenta resultados por ExecutedVersion para não diluir uma regressão nova no volume saudável antigo. Se há capacidade provisionada, acompanha spillover e a experiência do cliente: execução em concorrência normal não é o mesmo que throttling. O gate local do exercício exige um número observado e verificações funcionais; o valor escolhido é uma política fictícia de aprendizagem, não uma regra AWS nem uma demonstração estatística de ausência de falhas.
Coordenar capacidade e recuperação
A entrega pode exigir capacidade para duas versões e para as dependências partilhadas. Em ECS CODE_DEPLOY, a ocorrência de escala durante mudança de tráfego tem regras de estabilização diferentes da escala já ativa no início. Não copies a janela de uma fase para outra. Depois da mudança, a espera de eliminação do task set azul é distinta do intervalo canário; usa essa observação para decidir sobre resultados e custos. Em EC2, os hooks têm outra semântica: ApplicationStop vem da revisão anterior bem-sucedida, e Install pertence ao agente. Uma correção no pacote novo pode não corrigir o script antigo executado antes do download. O runbook deve indicar que revisão e fase investigar.
Exercício: tomar uma decisão proporcional à evidência
O modelo local de canário distingue três resultados: interromper se há falha funcional conhecida, recolher evidência quando falta amostra ou telemetria e considerar os critérios locais cumpridos quando todos passam. Não calcula confiança estatística, não observa AWS e não autoriza automaticamente uma release. Executa os casos de poucos pedidos, erro funcional, telemetria ausente e amostra suficiente. Explica por que uma falha confirmada pode justificar parar mesmo antes do mínimo, enquanto zero erros numa amostra pequena não justifica promoção. Na reunião de mudança, comunica versão, janela, população observada, resultados, limites e próxima ação. A decisão deve poder ser reconstruída sem depender da memória de quem viu um painel verde.
# Original local policy exercise; not statistical proof or release authorization.
def canary_decision(observed, failures, telemetry, functional_ok, minimum=200):
if not isinstance(observed, int) or not isinstance(failures, int):
raise ValueError("counts must be integers")
if observed < 0 or failures < 0 or failures > observed or minimum <= 0:
raise ValueError("invalid counts")
if failures or functional_ok is False:
return "stop and investigate"
if not telemetry or functional_ok is None or observed < minimum:
return "collect required evidence"
return "local criteria met; release decision still required"
assert canary_decision(3, 0, True, True).startswith("collect")
assert canary_decision(3, 1, True, True).startswith("stop")
assert canary_decision(220, 0, False, True).startswith("collect")
assert canary_decision(220, 0, True, False).startswith("stop")
assert canary_decision(220, 0, True, None).startswith("collect")
assert canary_decision(220, 0, True, True).startswith("local criteria")
try:
canary_decision(3, 4, True, True)
except ValueError:
pass
else:
raise AssertionError("invalid counts accepted")
O teste respondeu 200 na versão azul, enquanto o verde nunca foi exercitado; o validador precisa de alvo correto e callback identificado.
Armadilhas comuns
Misturar ECS nativo e CodeDeploy; testar azul para aprovar verde; usar retorno do handler como callback; trocar probabilidade por quota; confundir spillover e throttling.
Tópicos relacionados: Builds reproduzíveis e evidência de testes
A entrega só ganha evidência quando o alvo, a fase e os resultados observados correspondem à decisão que se pretende tomar.
Referência: Native ECS blue/green deployments · DOP-C02