Skip to main content

​
Antes de começar

Leia as release notes. update nunca toca no diretório de configuração, que é o que o torna seguro. E significa que uma chave de configuração nova introduzida por uma release não é adicionada ao seu arquivo.
Faça um backup do banco. Migrations são unidirecionais; não há scripts de undo.

​
A ordem

1

Pare o gateway

SIGTERM, não SIGKILL. Um shutdown limpo devolve crédito pré-pago reservado não gasto; um kill -9 o deixa preso até que fireflo credit release seja executado.
2

Aplique migrations deliberadamente

Em vez de deixar FIREFLO_DB_MIGRATE=true fazer no startup, o que amarra uma mudança de schema a um start de processo e não mostra nada antes.
3

Atualize o artefato

Substitui /opt/fireflo e nada mais.
4

Atualize o painel

5

Verifique

version pergunta ao gateway em vez dos arquivos. Um artefato que foi construído mas nunca teve restart nele é a razão inteira para perguntar — o jar em disco e o processo servindo tráfego são perguntas diferentes.

​
Ambos os componentes andam juntos

A versão do painel repete a release do gateway contra a qual foi construído em seus três primeiros números. O painel checa o par em runtime e reporta um mismatch na tela. Um par descasado não está necessariamente quebrado — mas significa que o painel está descrevendo um gateway contra o qual não foi construído, e um recurso adicionado no mais novo pode estar faltando ou renderizado incorretamente.

​
O que uma atualização substitui

​
Fazendo rollback

Restaura o artefato anterior.
Rollback restaura o artefato, não o schema. Se a release da qual você está voltando aplicou uma migration, o artefato antigo roda contra o schema mais novo. Isso geralmente funciona — o schema é aditivo — mas não é garantido, e é por isso que o backup importa.

​
Lendo o verify

Exit 4 depois de uma atualização geralmente significa que um domínio de configuração ficou vazio — vale checar antes de concluir que a atualização quebrou alguma coisa.