Canary deploys que realmente observam a taxa de erro, não só um timer

Um deploy padrão é binário: a nova versão passa pelo health check, e todo o tráfego vai pra ela de uma vez. Isso é ótimo até o problema não ser uma falha ao iniciar, mas um leak lento que só aparece sob 100% da carga de produção — e, quando fica óbvio, todo mundo já está na versão com problema. Um canary deploy existe exatamente pra essa lacuna.

O que realmente acontece

Ative em Settings → General → Deploy strategy, escolha Canary, e defina uma porcentagem do canary (1-99%): essa porcentagem dos novos visitantes recebe a versão nova, rodando bem ao lado da atual, sem substituí-la ainda. Um cookie mantém cada visitante na versão em que ele caiu primeiro, por um dia — ninguém é jogado entre a antiga e a nova no meio de uma sessão.

A partir daí, três configurações decidem o quão cauteloso é o rollout:

• Etapas da rampa, uma lista crescente como 5, 25, 50 — cada etapa é seu próprio canary, observado da mesma forma, e completar a última promove pra 100%. Deixe em branco pra uma única etapa que você promove manualmente.
• Permanência por etapa, em minutos — deixe em branco e você promove cada etapa você mesmo; defina um valor e o Railyard avança automaticamente depois que uma etapa rodar por esse tempo sem disparar a configuração seguinte.
• Fazer rollback acima de uma taxa de 5xx (%) — a parte que torna isso mais do que um simples toggle de divisão de tráfego. Se a taxa de erro de uma etapa cruzar esse limite, o Railyard faz o rollback por conta própria. Ninguém precisa estar de olho num dashboard às 2h da manhã pra isso pegar uma versão com problema.

Enquanto está ativo, a página de deploy mostra a contagem de requisições do canary, a taxa de 5xx e a latência p95 ao lado das do resto da aplicação — a comparação real que decide se promove, não um palpite.

O que ainda precisa rodar como um deploy padrão

Alguns casos sempre pulam o canary por completo, e saber disso de antemão evita confusão depois: o primeiro deploy de uma aplicação, um deploy durante o modo de manutenção, uma aplicação só de worker (sem tráfego pra dividir), e uma aplicação com um volume de dados. O comando de release — migrations, geralmente — ainda roda uma vez, antes do canary começar, o que significa que as migrations precisam funcionar contra o código antigo e o novo ao mesmo tempo durante todo o tempo em que o canary estiver rodando. Essa não é uma limitação específica do Railyard; é o tradeoff real que todo sistema de canary deploy faz, dito de forma clara em vez de disfarçado.

Combinando com uma janela de deploy

O canary responde “quão rápido uma versão nova chega a todo mundo.” Uma configuração separada e combinável — as janelas de deploy — responde “quando os deploys podem acontecer”:

railyard deploy-window my-app mon,tue,wed,thu,fri 09:00 17:00 America/Toronto

Pushes fora da janela entram numa fila e saem juntos quando ela abre; um deploy manual fora dela pergunta antes. As duas funcionalidades não interagem além disso — um canary no meio da rampa quando uma janela fecha continua rodando exatamente como configurado, já que avançar um canary já iniciado não é a mesma ação que iniciar um deploy novo.

Por que isso importa ainda mais quando você é dono dos servidores

Um canary com rollback automático é um dos lugares onde “self-hosted” poderia plausivelmente significar “menos proteções do que uma plataforma gerenciada” — e isso é a prova de que não precisa significar. O mecanismo é o mesmo independente de quem é dono da máquina: observar a taxa de erro real contra um limite real, não um timer fixo, e deixar o sistema se proteger antes que um humano precise intervir.

Referência completa, incluindo deploys agendados e notas de deploy: Canary deploys and deploy windows.