Lançamento Faseado e Rollback

Pausando o lançamento faseado do iOS e interrompendo o rollout do Play - o guia para conter lançamentos ruins em aplicativos Expo SDK 57 sem esperar pela exposição completa do usuário. O upload ainda flui através do EAS Submit; esta página cobre as ações do operador na App Store Connect e no Play Console após um build estar ativo ou parcialmente ativo.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

## Árvore de decisão de rollback (primeiros 15 minutos)
1. Confirme se o número do build ruim no Sentry / Play Vitals corresponde ao lançamento ativo
2. Classifique: crash nativo (build da loja) vs lógica JS (candidato EAS Update)
3. iOS: App Store Connect → pausar lançamento faseado
4. Android: Play Console → interromper rollout escalonado
5. Se nativo: preparar build de hotfix OU promover versionCode / buildNumber conhecido como bom
6. Publicar página de status + banner no aplicativo se autenticação/checkout estiverem quebrados

# Caminho de hotfix - incremente os números de build, reconstrua, reenvie
# app.config.ts: ios.buildNumber + android.versionCode incrementados
eas build --profile production --platform all
eas submit --platform ios --latest
eas submit --platform android --latest

Quando usar isso:

• A taxa de crash-free cai > 0,5% durante o primeiro dia do rollout.
• A taxa de ANR dobra nos vitals do Android em 20% de rollout escalonado.
• Regressão de checkout ou autenticação confirmada em produção - não um teste A/B instável.
• Marketing impulsionado antes que a engenharia valide as métricas da coorte faseada.
• Você precisa parar novos adotantes enquanto decide entre correção OTA e binário de hotfix.

Exemplo de Trabalho

Cenário - Regressão 2.4.0 em rollout parcial

Sintomas: Lançamento faseado do iOS dia 2 (~28% dos usuários); Android em 20% de rollout escalonado. Sentry mostra 3,2% de taxa de crash em 240012 (baseline 0,4%). Stack trace: ponteiro nulo em um módulo nativo após a atualização do RN 0.86.

Passo 1 - Pausar nova exposição

• Pausar lançamento faseado do iOS - usuários que já receberam a atualização a mantêm; nenhum novo usuário recebe 2.4.0 até que seja retomado ou substituído.
• Interromper rollout do Play - mesmo comportamento; instalações existentes permanecem na versão ruim até que atualizem novamente.

Passo 2 - Avaliar opções de rollback

Este crash é nativo - OTA não ajudará. Prossiga com o hotfix 2.4.1 build 240013.

Passo 3 - iOS: estratégia de lançamento enquanto pausado

1. Construa e envie o hotfix IPA via EAS.
2. Envie o 2.4.1 para Revisão da App Store - mencione a correção da regressão nas notas de revisão.
3. Opções enquanto espera:
   • Deixe o lançamento faseado do 2.4.0 pausado (limita o raio de explosão).
   • Se a Apple aprovar o 2.4.1 antes que a pausa expire, lance o 2.4.1 com o lançamento faseado ativado - não retome o 2.4.0.
4. Não é possível "fazer downgrade" de usuários no iOS - usuários na 2.4.0 precisam da correção futura 2.4.1.

<!-- Adendo à nota de revisão da App Store Connect -->
2.4.1 corrige crash na inicialização a frio (problema Sentry SHOP-4412) introduzido no build 240012 do 2.4.0.
O lançamento faseado do 2.4.0 está pausado. Nenhum novo usuário recebe 2.4.0.

Passo 4 - Android: interromper + lançamento substituto

1. Play Console → Produção → confirme se o rollout está interrompido em 20%.
2. Envie o hotfix AAB versionCode 240013 via eas submit.
3. Crie um novo lançamento de produção com 100% ou reinicie o rollout escalonado em 5% para a correção.
4. O Google não substitui instalações automaticamente - usuários na 2.4.0 baixam a 2.4.1 quando atualizam.

// eas.json - envio de hotfix (mesmos perfis, novo versionCode em app.config.ts)
{
  "submit": {
    "production": {
      "android": {
        "serviceAccountKeyPath": "./secrets/play-service-account.json",
        "track": "production"
      }
    }
  }
}

Passo 5 - Retomar rollout seguro

Passo 6 - Ganchos de postmortem

• Marque os releases do Sentry com buildNumber / versionCode.
• Adicione um checklist de aprovação/rejeição ao exemplo 9 de Noções Básicas de Operações de Loja.
• Registre um documento de incidente se a gravidade justificar - Resposta a Incidentes de Loja.

Referência de Lançamento Faseado do iOS

Controles na App Store Connect:

• Pausar Lançamento Faseado - congele a porcentagem até que seja retomada.
• Lançar Atualização para Todos os Usuários - pule os dias restantes do lançamento faseado (use apenas quando o hotfix for validado).
• Desativar lançamento faseado na próxima versão - 100% instantâneo (maior risco).

Usuários que atualizam manualmente na App Store podem receber o build imediatamente, independentemente da fase - o lançamento faseado se aplica a atualizações automáticas.

Referência de Rollout Escalonado do Android

Android vitals (Play Console → Qualidade → Android vitals):

• Taxa de crash percebida pelo usuário
• Taxa de ANR
• Compare fatias de versionCode - não apenas estatísticas gerais do aplicativo.

EAS Update como Mitigação Parcial

Quando o bug é apenas JavaScript e a política de versão de tempo de execução permite:

eas update --branch production --message "fix: rounding total do carrinho"

• Usuários com build nativo ruim ainda precisam de hotfix da loja se o código nativo foi alterado.
• Não use OTA sobre uma regressão nativa que causa crash ao iniciar - o aplicativo nunca alcança o bundle JS.
• Emparelhe com flags de recursos para desativar telas quebradas enquanto a atualização se propaga.

Limitações de Rollback

FAQs

Relacionados

• Fluxo de Trabalho da App Store Connect - lançamento faseado no envio
• Fluxo de Trabalho do Google Play Console - configuração de rollout escalonado
• Noções Básicas de Operações de Loja - monitoramento após o go-live
• Flags de Recursos para Rollout Seguro - mitigação JS
• EAS Submit - upload de hotfix
• Resposta a Incidentes de Loja - comunicação de interrupção grave

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