Como uma publicação funciona
Esta é a parte do modelo que mais se paga com o tempo. Quatro conceitos, deliberadamente separados:
| Conceito | Definição | Muda? |
|---|---|---|
| Build | O processo que transforma código em artefato | — |
| Artefato | A imagem construída, identificada por uma impressão digital única | Não |
| Versão | A configuração completa de uma implantação: artefato, variáveis, recursos, endereço | Não |
| Versão ativa | A versão que está recebendo tráfego | É um ponteiro |
Disso decorre tudo o que você percebe como confiabilidade.
Promover é reutilizar o mesmo artefato
Quando o mesmo artefato é publicado em outro ambiente, é exatamente o mesmo binário, bit a bit. Não há reconstrução. "Funcionou em um ambiente e quebrou no outro" perde a causa mais comum.
Nenhuma versão é sobrescrita
Toda mudança — código novo, variável alterada, recurso ajustado — cria uma versão nova. A anterior permanece inteira no histórico.
Restaurar é troca de ponteiro
Restaurar uma versão anterior não desfaz um update e não reconstrói nada: a versão de destino continua completa, com o artefato já aprovado, e o que acontece é a troca de qual delas recebe tráfego. É por isso que o produto pode prometer que a versão que funcionava volta a mesma.
Os cinco estados que você vê
Por dentro, uma publicação percorre muitos estados precisos. Na interface você vê cinco:
Preparando → Construindo → Publicando → Verificando → Online
E três desfechos possíveis além de Online: Não foi possível publicar, Cancelado e Versão anterior restaurada.
A tabela completa, com o que fazer em cada um, está em Estados da publicação.
Verificando não é decoração
O estado Verificando existe porque "a plataforma aceitou a publicação" e "a aplicação está respondendo" são coisas diferentes. A troca de tráfego só acontece depois que a nova versão fica pronta — e pronta, para a plataforma, é aceitar conexão TCP na porta do serviço. Não é uma verificação HTTP: a plataforma não sabe que caminho a sua aplicação responde.
Se a aplicação não fica pronta, a publicação falha com o motivo, e nada é trocado. Ver Estados da publicação.
Cada publicação registra até onde foi confirmada, numa escada de quatro etapas:
Imagem conferida → Configuração aplicada → Aplicação respondendo → Endereço confirmado
A última etapa só vem de tráfego real: uma requisição vinda da internet que a aplicação respondeu. Uma publicação recém-feita fica em 3 de 4 até essa primeira requisição.
Quando a publicação foi aceita mas nenhum processo chegou a existir, a resposta diz isso em vez de deixar implícito. É a mesma régua que faz um pedido de log de aplicação, antes de existir aplicação executando, responder "ainda não há execução" em vez de devolver uma lista vazia — vazio significaria "executou e não escreveu nada", e confundir os dois manda você procurar o problema no lugar errado.
Cancelar tem uma janela
Uma publicação pode ser cancelada enquanto está preparando ou construindo. Depois que o artefato foi enviado, o cancelamento deixa de existir como saída: a saída passa a ser restaurar a versão anterior.
Quando falha
Uma publicação que falha não deixa o serviço sem versão ativa: a anterior segue atendendo, intacta.
A plataforma coleta a evidência daquela falha — a saída relevante do build, o instante da falha, os eventos, a mudança de versão — e correlaciona tudo em um objeto único, com segredos já protegidos. É essa evidência que alimenta a tela, o diagnóstico e o agente que ajuda a investigar, para que os três enxerguem a mesma verdade.
O que você lê é do tipo:
A aplicação iniciou, mas não respondeu. Faça a aplicação escutar em
0.0.0.0, na porta da variávelPORT.
E não um convite para procurar em um painel.
Próximos passos
Esta página ajudou?
Reportar um problema nesta páginaNão envie senhas, chaves, tokens ou dados de clientes.