O que de fato torna um deploy zero-downtime
“Deploy zero-downtime” é usado de forma solta o suficiente para valer a pena ser preciso sobre o que isso de fato exige mecanicamente, não só o que promete. Não é um recurso só — são cinco etapas que todas precisam se sustentar, em ordem, todas as vezes.
As cinco etapas
- Build, ou pull. Com um repositório, a nova imagem é construída num servidor de build dedicado se a equipe tiver um, senão no próprio servidor do app ou num temporário que o Railyard inicia para o trabalho. Uma origem
image://pula a build completamente e só baixa. - Comando de release. Se o app tiver um, ele roda uma vez contra a nova imagem, antes de qualquer coisa receber tráfego — é aqui que as migrações pertencem. Se falhar, o deploy para exatamente aqui e o app continua rodando a versão antiga. Nada sobre o app no ar mudou ainda.
- Verificação de saúde. O novo container inicia ao lado do que já está rodando, não no lugar dele. Se o app tiver um caminho de verificação de saúde configurado, o novo container precisa de fato responder a ele dentro do tempo limite configurado antes de qualquer outra coisa acontecer.
- Troca de tráfego. Só depois que o novo container passa a verificação de saúde é que o tráfego se move para ele — tudo de uma vez num deploy padrão, ou uma fração por vez num canary deploy, observado contra a taxa de erro do resto do app antes de avançar mais.
- A versão antiga para. O container anterior continua rodando até o novo ser confirmado, e só então é removido.
Essa ordem é todo o mecanismo. Nunca existe um ponto entre as etapas em que o app tem zero containers funcionais — o antigo não vai embora até o novo já ter se provado.
O que acontece quando algo falha
Essa é a parte que de fato importa mais do que o caminho feliz: se a build, o comando de release, ou a verificação de saúde falharem, o Railyard deixa a versão anterior rodando exatamente como estava e marca o deploy como falho. Um deploy ruim não derruba o app — ele simplesmente não vai ao ar. A página do deploy nomeia a causa exata e leva à correção — veja por que um deploy de fato falha, motivo por motivo para o que cada uma significa.
Fazer rollback é o mesmo mecanismo, não um diferente
Um rollback não é uma rota de escape com tratamento especial — é um deploy do commit ou da imagem de uma release anterior, o que significa que passa exatamente pelo mesmo build-ou-pull, comando de release, verificação de saúde e troca de tráfego que qualquer outro deploy. Isso é deliberado: um rollback que pulasse a verificação de saúde seria o único caminho de deploy que poderia de fato causar o downtime que o resto do sistema é construído para evitar.
railyard releases my-app # lista releases para as quais fazer rollback
railyard rollback my-app <version> [--code-only]--code-only restaura o código mas mantém as variáveis de ambiente de hoje — útil quando a release em si estava boa, mas uma variável mudou desde então e você não quer desfazer isso também.
Por que a ordem não pode ser pulada
Cada uma dessas etapas existe por causa de um modo de falha específico que ela bloqueia. Pule a verificação de saúde e uma nova versão em crash-loop recebe tráfego de qualquer forma. Pule manter o container antigo vivo durante a verificação e existe uma lacuna com nada respondendo. Rode o comando de release depois da troca em vez de antes e uma migração pendente atinge o tráfego real no meio da execução. Nada disso é engenharia exótica — é simplesmente não pular etapas sob pressão para lançar mais rápido.
Detalhe completo, incluindo canary deploys e janelas de deploy: Deploys and rollbacks.