APRENDER. PRATICAR. EVOLUIR.O caminho faz parte da release
O guião cria três servidores HTTP em 127.0.0.1, com portos atribuídos pelo sistema: blue, green e router. São listeners e pedidos reais, executados por threads num único processo Python. O router escolhe o destino e encaminha o pedido para um dos outros listeners. Inicialmente todos os pedidos seguem para blue. green já responde ready quando consultado diretamente, mas o pedido pilot pelo router continua a identificar blue. Num projeto APS, esta diferença impede comunicar disponibilização apenas porque a instalação terminou. Identifica o caminho que o consumidor dependente vai usar, incluindo o batch, e observa a versão e o resultado por esse caminho. O laboratório não executa um balanceador empresarial, DNS, TLS, Kubernetes ou autenticação.
Coorte explícita e população relevante
Quando candidate passa a true, o router escolhe green apenas para cohort=pilot; control continua em blue. O campo é uma entrada explícita do exercício, não um identificador autenticado de cliente. Não representa dez por cento do tráfego, uma seleção aleatória ou uma garantia de afinidade num produto real. A observação deve indicar quem entrou na amostra e que comportamento foi exercitado. Um grupo composto apenas por utilizadores internos pode não cobrir contratos antigos de clientes externos. Aumentar a duração sem mudar esse perfil não introduz automaticamente os caminhos ausentes. Para uma release fictícia, relaciona as populações com o mecanismo de risco e define o que falta observar antes de expandir. Não há tamanho universal de canary deduzido destes pedidos locais.
Status de sucesso e resultado incorreto
No caminho ordinary, a candidata devolve 100. No caminho critical, blue devolve 100 e green devolve 108, apesar de ambos usarem HTTP 200. O defeito é deliberado e o valor exigido pelo exercício é 100; não se trata de uma fórmula financeira. O endpoint ready continua verdadeiro porque não valida essa operação. Assim, o status e a disponibilidade do componente não bastam para aprovar a release. Liga os critérios a resultados que o consumidor reconhece e conserva a identidade da versão que os produziu. Quando um critério obrigatório falha, suspende a expansão e decide mitigação, recuperação ou correção segundo a autoridade aplicável. O prazo próximo não altera o resultado esperado nem transforma a observação numa aceitação.
O que o trace permite concluir
O registo do router guarda destino, método, caminho, tipo e valor após receber cada resposta. Nesta fase existem observações ordinary e critical, mas nenhuma export. A taxa export é apresentada como desconhecida, com denominador zero, e não como zero por cento de falhas. O registo também não constitui uma amostra de produção nem mede capacidade ou percentis de latência. Mais adiante, um pedido admitido primeiro fica suspenso e aparece depois de outro no trace: a ordem é de conclusão observada, não um log de admissão. Numa investigação de release, confirma o momento e o significado de cada campo antes de reconstruir a sequência. Conserva as lacunas de telemetria em vez de as preencher com conclusões favoráveis.
python3 content/labs/release-routing/run.py --output /tmp/dr-release-routing.json
# Inspect installedCandidateIsNotExposure and httpSuccessMissesSemanticFailure.
# Three temporary loopback listeners only; not a production proxy.green está ready, mas pilot continua em blue até mudar a regra; depois critical devolve HTTP 200 com 108 em vez de 100.
Armadilhas comuns
Acesso direto como disponibilização, coorte como percentagem aleatória, HTTP 200 como resultado correto ou ausência de pedidos como sucesso.
Tópicos relacionados: Critérios de go/no-go · Pedidos em curso e recuperação
A release precisa de evidência do percurso e das populações relevantes; prontidão de um componente não comprova aceitação funcional.
Referência: Canarying Releases · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation