Um deploy não termina quando o container inicia

Existe uma classe específica de bug de deploy que é quase impossível de depurar depois do fato: o deploy reporta sucesso, o container está saudável, e ainda assim, por um tempo, as requisições retornam 502. Quando alguém vai olhar, tudo já está bem.

A causa geralmente é a lacuna entre um container estar pronto e seu app estar de fato acessível na sua URL real.

Duas perguntas diferentes

“O container está no ar?” é uma pergunta útil, e o Railyard faz ela antes de uma nova versão ser autorizada a receber tráfego. Mas não é a pergunta que seus usuários estão fazendo. Eles acessam seu aplicativo pelo domínio real dele, via HTTPS, e esse caminho tem o próprio momento de se estabilizar depois de uma release.

Então um deploy do Railyard verifica as duas coisas: a nova versão precisa responder por conta própria primeiro, e depois precisa de fato estar acessível do jeito que um visitante acessaria, antes de o deploy ser marcado como concluído.

O que acontece se não estiver

Se a nova versão nunca fica saudável, nada se move: a versão antiga continua servindo, o container novo é removido, e o deploy é marcado como falho com o motivo, incluindo as linhas de log da nova versão para você ver por que ela não subiu.

Se a nova versão está saudável mas nunca fica acessível na URL real dentro de alguns minutos, o Railyard faz rollback por conta própria: a versão anterior é iniciada de novo e o deploy é marcado como falho com o motivo, em vez de deixar um app pela metade trocado.

O resultado

O ponto de tudo isso não é o deploy em si. Um deploy que termina significa que a URL funciona, e um erro nos seus logs depois significa que algo está de fato errado com o seu aplicativo, não uma sobra da última release. É isso que torna os deploys sem downtime confiáveis em vez de apenas esperados.