Releases e rollout

Cada hot-updater deploy cria uma release: um bundle publicado num canal, para uma plataforma e uma faixa de versões do app. Tudo o que define quem recebe a release pode ser mudado depois, pelo painel, sem novo deploy.

Para quais builds a release vale

Depende do updateStrategy do projeto:

• appVersion: a release vale para uma faixa de versões nativas, como 1.4.x ou >=1.4.0. Por padrão, a CLI usa a versão do projeto. Para escolher outra faixa, passe -t:

  npx hot-updater deploy -p ios -t "1.4.x"

• fingerprint: a release vale para builds com o mesmo fingerprint nativo. Se a parte nativa mudou, o fingerprint muda e o update não chega na build antiga. Isso evita mandar JavaScript para um nativo incompatível.

Rollout gradual

O rollout é a porcentagem de aparelhos que recebe a release. Defina no deploy (-r 10) ou depois, no painel, abrindo a release.

• É estável. Cada aparelho cai sempre no mesmo grupo. Com 35%, cerca de 350 de cada 1.000 aparelhos recebem.
• Aumentar só adiciona aparelhos. Quem já recebeu continua com a release. Passar de 10% para 50% inclui mais gente sem tirar ninguém.
• Diminuir não desfaz o update em quem já baixou. Para tirar a release de todo mundo, desative.

Rollout automático

Em vez de subir a porcentagem à mão, deixe o Pipa no Ar subir em degraus e vigiar os crashes. Abra a release no painel e, em Liberar aos poucos, escolha:

• Degraus: por exemplo 10%, 25%, 50% e 100%.
• Tempo entre degraus: de 1 hora a 1 dia.
• Limite de crash: a taxa de inicializações com crash que dispara a reação (1%, 2% ou 5%).
• Inicializações mínimas: abaixo disso a taxa não é julgada, para não reagir a poucos aparelhos.
• Desativar a release se passar do limite: ligado, a release é desativada (rollback). Desligado, o rollout só para de subir.

A cada 15 minutos o Pipa no Ar confere a taxa de crash da release no Insights. Se estiver abaixo do limite, sobe para o próximo degrau na hora marcada. Ao chegar em 100%, continua vigiando por mais 24 horas. Quem pode publicar releases recebe um e-mail quando a release é desativada, quando o rollout pausa e quando chega a 100%. Tudo fica registrado em Auditoria.

Precisa do Insights

Sem o plugin insights() no app, não há dados de crash: os degraus sobem no horário, mas nada é desativado automaticamente.

Cohorts adicionais

Cohorts são grupos nomeados, como qa ou time-interno, que recebem a release sempre, qualquer que seja o rollout. Servem para testar em produção com o time antes de abrir para os usuários.

Adicione cohorts no painel, ao abrir a release. Os nomes são públicos: não use dados pessoais. Quem define o cohort de cada aparelho é o app, pelo SDK do hot-updater.

Atualização forçada

Normalmente o app baixa o update e aplica no próximo início. Com atualização forçada (-f no deploy, ou no painel), o app recarrega assim que termina de baixar. Use para correções urgentes.

Desativar uma release (rollback)

Desativar é o rollback do Pipa no Ar. Ao desativar no painel (ou com npx hot-updater bundle disable <id>), os aparelhos voltam, na próxima checagem, para a release ativa anterior do mesmo canal. Se não houver nenhuma, voltam para o bundle que veio na build nativa.

Além disso, o SDK protege o app sozinho: se um bundle novo faz o app crashar logo ao abrir, ele descarta o bundle e volta para o anterior.

Patches

Em apps com Hermes, a CLI gera patches depois do deploy: o aparelho baixa só a diferença para o bundle que já tem, em vez do bundle inteiro. Isso acontece sozinho; a coluna Patches em Releases mostra quantos foram gerados.