Pular para o conteúdo principal

Estados da publicação

Uma publicação percorre estados em ordem. Cinco são de progresso; quatro são desfechos.

Progresso​

EstadoO que está acontecendoPode cancelar?
PreparandoA publicação foi aceita e está sendo validada; aguarda um lugar na filaSim
ConstruindoO código está sendo obtido e a imagem, construídaSim
PublicandoO artefato foi enviado e a nova versão está sendo aplicadaNão
VerificandoA nova versão está subindo, e a plataforma espera que ela fique pronta antes de receber tráfegoNão
Voltando à versão anteriorUma versão anterior está sendo restauradaNão

A janela de cancelamento termina quando o artefato é enviado. A partir daí, a saída é restaurar a versão anterior.

Desfechos​

EstadoO que significaO que fazer
OnlineA nova versão ficou pronta e passou a ser a ativaNada. A confirmação do endereço vem com a primeira requisição real — ver Até onde foi confirmado
Não foi possível publicarFalhou. A versão anterior segue ativa e intactaA tela diz o motivo e a ação; ver também o log da etapa que falhou
CanceladoCancelado antes da troca de tráfego. Nenhuma mudança visívelPublicar de novo quando quiser
Versão anterior restauradaA versão anterior voltou a atenderInvestigar a versão com problema

Quando a aplicação não fica pronta​

Para a plataforma, uma instância está pronta quando aceita conexão TCP na porta do serviço — a porta que a aplicação recebe na variável PORT. Ver Como a aplicação roda.

Enquanto espera, a linha do tempo da publicação narra o que está acontecendo, com frases como:

  • "A aplicação iniciou, mas ainda não aceita conexão na porta 8080."
  • "A aplicação encerrou logo depois de iniciar (código 1); tentando de novo."
  • "O ambiente ainda não conseguiu baixar a imagem desta versão."
  • "Esperando capacidade livre no ambiente para a instância."

A espera tem prazo de 5 minutos. Se a aplicação não fica pronta nesse prazo, a publicação falha com o motivo — e nada é trocado: a versão anterior, se havia, continua sendo a que responde. Quando o motivo é definitivo, a publicação encerra em cerca de 30 segundos, sem esperar o prazo inteiro.

Na tela do deployment, a etapa Respondendo aparece como falha, com o problema e a ação. O mesmo código aparece na API e na CLI:

CódigoO que a tela dizO que aconteceuO que fazer
APPLICATION_NOT_STARTEDA aplicação não chegou a iniciarA imagem não pôde ser baixada, o ambiente recusou criar o processo, ou não havia capacidadePublique de novo. Se o motivo voltar, fale com quem administra a plataforma — não é algo que se corrija na aplicação
APPLICATION_CRASHED_ON_STARTA aplicação parou logo depois de iniciarO processo encerrou algumas vezes seguidas; a tela diz quantas e com que códigoVeja as últimas linhas em Logs → Runtime. Normalmente é variável de ambiente ausente ou dependência não configurada
HEALTH_CHECK_FAILEDA aplicação iniciou, mas não respondeuO processo está de pé e não aceitou conexão na porta do serviço dentro do prazoFaça a aplicação escutar em 0.0.0.0, na porta da variável PORT

As garantias​

Estas valem sempre, e é sobre elas que a operação do dia a dia se apoia:

  1. Uma publicação que falha nunca deixa o serviço sem versão ativa, quando já havia uma.
  2. A troca de tráfego só acontece depois que a nova versão fica pronta.
  3. Nenhuma versão publicada é sobrescrita — toda tentativa cria uma nova.
  4. Depois de enviar o artefato, a saída deixa de ser cancelamento e passa a ser restauração.
  5. Toda transição registra quando aconteceu, quem pediu, o motivo e a evidência quando há falha.

Até onde foi confirmado​

Além do estado, cada publicação mostra o quanto foi de fato provado, numa escada de quatro etapas:

EtapaSignifica
Imagem conferidaA imagem foi construída e teve a integridade confirmada
Configuração aplicadaA plataforma aceitou a configuração desta versão
Aplicação respondendoAs instâncias ficaram prontas: aceitam conexão na porta do serviço
Endereço confirmadoUma requisição real, vinda da internet depois da ativação desta versão, chegou à aplicação e foi respondida por ela

Antes da primeira etapa, a tela diz Ainda sem verificação.

"Endereço confirmado" só vem de tráfego real. Uma resposta que a própria plataforma gera quando não alcança a aplicação — por exemplo, um 503 com "upstream connect error" — não conta como prova. Por isso uma publicação recém-feita fica em 3 de 4 até a primeira requisição real chegar e ser respondida — abrir o endereço no navegador basta. A partir daí, 4 de 4 e Recebendo tráfego.

"Configuração aplicada" e "Endereço confirmado" são afirmações diferentes. A escada existe para que ninguém anuncie uma versão que ainda não responde.

Próximos passos​