Deploys e rollbacks

O que acontece durante um deploy

1. Build. Com um repositório, o Railyard builda uma imagem em um servidor de build dedicado, se sua equipe tiver um, ou então no próprio servidor da aplicação ou em um servidor de build temporário que o Railyard cria para a tarefa. Com uma fonte image://, ele baixa a imagem em vez de buildar; nada é compilado. Veja Métodos de build.
2. Comando de release. Se a aplicação tiver um configurado, ele roda uma vez contra a nova imagem antes de qualquer tráfego chegar a ela. É aqui que as migrations entram. Se falhar, o deploy para nesse ponto e a aplicação continua rodando a versão antiga.
3. Verificação de integridade. O novo container inicia ao lado do que já está rodando. Ele precisa subir e, se a aplicação tiver um caminho de verificação de integridade configurado, responder a ele dentro do tempo limite definido.
4. Troca de tráfego. Só depois que o novo container passa pela verificação é que o tráfego é movido para ele. Um deploy padrão move tudo de uma vez; um deploy canary envia uma fração primeiro. Veja Deploys canary e janelas de deploy.
5. A versão antiga é parada. O container anterior continua rodando até o novo ser confirmado, e só então é removido. É isso que torna os deploys sem downtime: nunca existe um momento em que a aplicação não tenha um container funcionando para responder.

Se algo falhar

Se o build, o comando de release ou a verificação de integridade falharem, o Railyard mantém a versão anterior rodando e marca o deploy como falho. Um deploy ruim nunca derruba sua aplicação. A página do deploy explica o que falhou e indica como corrigir; veja Resolvendo problemas em deploys com falha.

Fazendo rollback

Fazer rollback refaz o deploy do commit (ou imagem) de uma release anterior bem-sucedida e recupera as variáveis com que ela rodava. A tela de confirmação lista quais variáveis voltam ao valor antigo e avisa se algum secret mudou desde essa release. Para manter as variáveis de hoje e restaurar só o código, escolha a opção code-only (ou passe como flag/parâmetro).

• Painel: na aba Releases e deploys da aplicação, escolha Voltar para v<n> ao lado de uma release anterior bem-sucedida.
• CLI: railyard releases my-app lista as releases para as quais dá para voltar; railyard rollback my-app <version> [--code-only].
• API: POST /api/applications/:id/deploys com rollback_to (o id de um deploy anterior bem-sucedido) e, opcionalmente, "restore_config": false.

Um rollback também é um deploy: ele passa pelo mesmo build-ou-pull, comando de release, verificação de integridade e troca de tráfego que qualquer outro deploy, e respeita a janela de deploy da aplicação, a menos que você ignore isso explicitamente. Releases publicadas antes de o Railyard começar a guardar uma cópia das variáveis só conseguem reverter o código.

Histórico de releases

Todo deploy bem-sucedido com um commit é numerado como uma release (v1, v2, …). A aba Releases e deploys da aplicação lista todas elas, com os deploys mais antigos a um clique de distância; railyard deploys --app my-app e GET /api/deploys?application_id=:id mostram o histórico completo pela CLI e pela API. Cada deploy guarda seu log, o gatilho, o commit e qualquer nota.

Veja também

• Deploys canary e janelas de deploy — releases com tráfego parcial, deploys agendados e com janela, notas de deploy.
• Métodos de build — qual builder roda e como os builds se encaixam nos seus servidores.
• Resolvendo problemas em deploys com falha — o que cada motivo de falha significa e como corrigir.