Conceito e mecanismo
Um canary expõe uma parte do serviço à alteração e usa os resultados para decidir progressão. Precisa de população adequada, comparação, critérios e ligação à decisão de rollout. Uma amostra sem tráfego representativo pode estar verde porque não exercitou o comportamento alterado. Escolhe indicadores de resultado, erros, latência, capacidade e filas conforme o mecanismo de risco. A duração deve permitir observar os padrões relevantes, incluindo tarefas periódicas e horas de maior carga. Não existe uma percentagem ou duração universal que prove segurança. Se surgem sinais de degradação, trava a expansão e investiga ou recupera segundo critérios acordados, antes de aumentar o número de utilizadores expostos.
Aplicação guiada
Num cálculo original, o canary tem oito erros em 400 pedidos, ou 2%; o controlo tem 18 em 18000, ou 0,1%. Uma média global pode esconder a diferença. Compara também perfil de pedidos e integridade da telemetria antes de inferir causa. Blue-green mantém conjuntos separados e transfere tráfego, podendo combinar-se com progressão gradual; exige capacidade e compatibilidade do estado partilhado. A separação dos servidores não desfaz escritas na base de dados. Mantém coerência entre rollouts concorrentes: em GitLab, resource_group serializa os jobs abrangidos, mas o modo unordered não garante ordem. Uma release antiga ainda pode sobrescrever uma nova se a política de ordenação e proteção contra jobs desatualizados não for considerada.
2% no canary e 0,1% no controlo merecem análise separada, mesmo com pipeline verde.
Armadilhas comuns
Amostra vazia como sucesso; média global; blue-green como reversão de dados; lock como ordenação.
Tópicos relacionados: Âmbito e coordenação · Artefactos e rastreabilidade · Prontidão e autorização
Liga exposição à saúde observada e mantém controlo sobre a sequência de alterações.
Referência: Representative canary evaluation and feature exposure · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation