Um pedido mantém o destino já escolhido
O guião envia um POST pilot do tipo critical e confirma que entrou no handler green. Um Event suspende o processamento antes da escrita. Só depois dessa confirmação a política muda para blue. Um segundo POST, enviado pela mesma coorte, segue agora para blue, devolve 100 e escreve o respetivo recibo. Entretanto, o primeiro cliente continua pendente e o contador mantém um pedido em curso. Esta intercalação usa sinais explícitos, não uma estimativa de atraso de rede. O ensaio demonstra que a regra de seleção nova não reencaminha retroativamente o handler que já está a executar. Não demonstra comportamento de sessões persistentes, multiplexing, retries, cancelamento pelo cliente ou ligação perdida, porque esses mecanismos não foram exercitados.
Drenagem exige observar o trabalho admitido
Depois de verificar o novo caminho, o guião liberta o Event e espera pela conclusão do primeiro cliente. A resposta continua a identificar green e contém 108. Apenas depois encerra o listener candidato e confirma que um pedido seguinte ainda funciona por blue. Esta sequência separa retirar novas seleções, concluir trabalho já admitido e retirar o componente. Num destino real, define limites de espera e o que fazer quando uma operação excede o tempo disponível. Esperar indefinidamente não é uma política completa; terminar sem avaliar efeitos também não é. O plano deve identificar interrupção suportada, autoridade, estado parcial, escalada e critérios de retoma. O laboratório escolheu conclusão normal controlada e não ensaiou interrupção de operações remotas.
A última consequência pode surgir depois do cutover
O ficheiro temporário termina com dois registos: blue/100 seguido de green/108. O segundo efeito foi produzido depois de a rota já estar recuperada para novos pedidos. Fechar green deixa o ficheiro inalterado. Por isso, a hora da mudança de política não basta para delimitar todos os efeitos da candidata. Numa aplicação real, relaciona pedidos admitidos, confirmações e efeitos persistidos antes de decidir reconciliação ou compensação. Se uma ligação se perder após uma possível escrita, a ausência de resposta não prova ausência de efeito. Esse cenário adicional é discutido nas perguntas, mas não foi executado pelo laboratório. O guião não implementa idempotência nem autoriza repetir cegamente um POST; a política de repetição depende do contrato e do estado confirmado.
Aceitação e comunicação com RUN
A oficina proposta reúne APS, fornecedor, responsável pelo serviço e RUN. Em inglês, devem explicar o que foi instalado, o que recebe pedidos novos, o que continua a executar e que efeitos precisam de tratamento. O guião existe, mas não foi executado por um grupo humano. Treze grupos locais passaram duas vezes em CPython 3.13.1, usando três listeners próprios e limpeza dos sockets, threads e diretoria temporária. http.server não é recomendado para produção e o router pedagógico não oferece segurança ou capacidade de um componente empresarial. Mantém pendentes ensaios do destino, revisão especializada e demonstração de autonomia. Na revisão posterior, separa cobertura funcional, drenagem e reconciliação em ações com responsáveis e critérios que comprovem o resultado pretendido.
python3 content/labs/release-routing/run.py --output /tmp/dr-release-draining.json
# Compare routeChangeDoesNotCancelInFlight and effectAfterCutoverRemains.
# Proposed human workshop: explain remaining work and recovery in English.O POST novo escreve blue/100; depois de libertar o Event, o POST antigo escreve green/108, que permanece no recibo.
Armadilhas comuns
Rota recuperada como cancelamento, fecho do listener como reconciliação ou repetição cega de um POST com confirmação ambígua.
Tópicos relacionados: Drenagem e limites de espera · Handover e revisão posterior
A mudança da rota controla seleções futuras; o plano precisa de decisões separadas sobre pedidos antigos, efeitos e retirada do componente.
Referência: threading: Event and thread lifecycle · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation