Melhores Práticas de Atualizações OTA

Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção.

1. OTA é apenas JS e assets: Módulos nativos, plugins de configuração, permissões, direitos e atualizações de SDK, e ícones de aplicativos exigem eas build e envio para a loja - OTA não pode adicionar símbolos nativos.

2. Defina política explícita de runtimeVersion: Use appVersion, nativeVersion, ou fingerprint consistentemente em app.config - documente a escolha no README e nunca misture políticas entre sabores sem um ADR.

3. Corresponda o runtime no build e na atualização: O runtimeVersion resolvido por eas build deve ser igual ao que eas update tem como alvo - verifique com npx expo config --type public antes de cada publicação.

4. Incremente o runtime quando o código nativo mudar: Nova dependência nativa, edição de plugin ou string de permissão significa novo build da loja e nova linha de runtime - não use OTA para JS que importa módulos nativos ausentes.

5. Configure updates.url e projectId: Execute eas update:configure após eas init - a falta de updates.url desabilita expo-updates silenciosamente em builds de produção.

6. Conecte os cabeçalhos de canal aos perfis de build: updates.requestHeaders["expo-channel-name"] deve corresponder ao channel do eas.json para cada perfil - direcione a partir do EAS_BUILD_PROFILE em app.config dinâmico.

7. Use eas update --environment sempre: No SDK 55+, os executores de atualização ignoram o .env local - passe --environment production (ou preview) para que os bundles OTA correspondam às variáveis de ambiente do build.

8. Nomeie canais para ambientes: development, preview, staging, production - não nomes de engenheiros; mapeie canais para públicos em docs/release-channels.md.

9. Fluxo de promoção linear: development → preview (QA) → production - sem pular a pré-visualização para alterações de pagamento, autenticação ou checkout, independentemente do tamanho da diferença.

10. Builds de pré-visualização para aprovação OTA: Testes de QA em binários do perfil preview do EAS, não no Expo Go - o Expo Go não pode receber sua configuração de atualização de produção.

11. Publicação de produção apenas via CI: Prefira fluxos de trabalho do GitHub Actions com tags para eas update --channel production - publicação no laptop é para emergências com um segundo aprovador e pós-mortem.

12. Registre o ID da última atualização boa conhecida: Cada ticket de lançamento de produção armazena o ID do bundle anterior para eas update:rollback ou eas update:republish - rollbacks sem isso são adivinhação.

13. Defina gatilhos de rollback antes do lançamento: Limites de queda de crash, queda de sucesso de pagamento e pico de erro de autenticação com responsáveis - veja Regras de Lançamento e OTA Nível 4.

14. Pratique rollback trimestralmente na pré-visualização: Execute eas update:rollback no canal de pré-visualização em um exercício - mire em menos de 15 minutos da decisão até a verificação do topo do canal.

15. Proteja JS dependente de código nativo com flags: Chaves de desativação remota mais verificações de Application.nativeApplicationVersion evitam crashes até que a adoção da loja ultrapasse seu limite.

16. Registre updateId em análises de produção: Updates.updateId, runtimeVersion e channel no início da sessão - o suporte e a resposta a incidentes dependem de saber o bundle em execução.

17. checkAutomatically ON_LOAD com fallback 0: Verifique na inicialização a frio sem bloquear o lançamento em redes lentas - ajuste a experiência do usuário de recarga separadamente via API do cliente expo-updates.

18. Reconstrua após a primeira configuração de atualizações: Adicionar a configuração do expo-updates requer um novo binário nativo - eas update por si só não habilita atualizações em instalações antigas.

19. Trate regressões de tamanho de bundle como lançamentos: Bundles OTA grandes prejudicam o TTI - compare a saída do Metro antes da publicação de produção e vincule às regras de orçamento de desempenho.

20. Contratos de API retrocompatíveis: Usuários de dispositivos móveis pulam atualizações - o JS enviado via OTA deve tolerar respostas de API mais antigas até que a adoção da loja seja alta; execute testes de contrato em CI.

21. Migrações seguras de armazenamento local: Atualizações de esquema MMKV e SQLite precisam de caminhos de atualização testados a partir do bundle de produção anterior - migrações ruins travam instalações e precisam de rollback.

22. Rollouts graduais na produção: Use --rollout-percentage ou eas channel:rollout após a pré-visualização - monitore métricas de crash e pagamento em cada etapa antes de 100%.

23. Marque Sentry com updateId: Segmente relatórios de crash por bundle durante os rollouts - sem tags de coorte, os rollouts percentuais são cegos.

24. Monitore a distribuição do runtime semanalmente: Porcentagem de usuários por runtimeVersion - binários desatualizados param de receber OTAs; imponha a versão nativa mínima quando a segurança exigir.

25. Checklist de lançamento de duas trilhas: Checklist de envio para a loja para alterações nativas e checklist OTA para pré-visualização, flags, ID de rollback e dashboards - anexe ambos a cada ticket de lançamento.

FAQs

Relacionados

• Noções Básicas de Atualizações OTA - Limites de OTA vs loja
• Configuração do expo-updates - Receita de app.config
• Canais e Ramificações de Lançamento - fluxo de promoção
• Runbook de Rollback - republicação de canal em minutos
• Política de Versão de Runtime - seleção de política
• Rollouts Graduais - rollouts percentuais e monitoramento
• expo-updates (API do Cliente) - verificação/busca/recarregamento do cliente
• Noções Básicas do EAS Build - binários que recebem atualizações
• Regras de Lançamento e OTA - checklist de aplicação pela equipe

Versões da pilha: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).