Melhores Práticas de CI/CD
Um resumo condensado das 25 práticas mais importantes de CI/CD para equipes mobile do Expo SDK 57 - extraído de todas as páginas desta seção.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 práticas mais importantes de CI/CD para equipes mobile do Expo SDK 57 - extraído de todas as páginas desta seção.
Mesmos scripts localmente e no CI: npm run lint, typecheck, test e format:check devem funcionar em um clone recém-criado - o CI não deve invocar comandos de ferramentas únicos que os desenvolvedores nunca executam.
Verificações de PR são portões rápidos: Lint, TypeScript e Jest em cada pull request - alvo abaixo de dez minutos; bloqueie o merge via proteção de branch.
Pipelines de release são separados: Fluxos de eas build e submit baseados em tags - gatilhos diferentes, orçamento de falha diferente das verificações de PR - Noções Básicas de CI/CD Mobile.
Sem builds para loja em laptop: Binários de produção vêm do EAS Build com credenciais no EAS - não archives do Xcode no MacBook de um engenheiro.
Mesmo artefato do CI para a loja: QA aprova o build_id; eas submit usa esse ID - não --latest após uma reconstrução - Promoção Automatizada para Loja.
Conta de robô EXPO_TOKEN: O CI usa um token de acesso Expo armazenado em GitHub Secrets - nunca senhas pessoais ou eas login interativo - GitHub Actions + EAS.
Sempre npm ci no CI: Instalações baseadas em lockfile - npm install em fluxos de trabalho cria falhas não reproduzíveis.
Node 20 LTS no CI: Alinhe engines.node com GitHub Actions e EAS Workflows - corresponde às expectativas de ferramentas do SDK 57.
Execute npx expo customize antes de tsc: Rotas tipadas precisam de .expo/types em checkouts limpos - Portões de Qualidade de CI.
Qualidade antes de type: build: EAS Workflows encadeia needs: [quality] para que as compilações nativas não comecem com TypeScript quebrado - EAS Workflows.
Builds de preview com portão de label: Label needs-preview ou filtros de caminho - não cada erro de digitação gasta créditos do EAS - Builds de Preview em PRs.
Distribuição interna para previews de PR: distribution: internal + apk Android - instalação via QR code para QA em dispositivos reais - Distribuição Interna.
Perfis preview e production separados: Preview não deve tocar nas credenciais de assinatura de produção ou auto-incrementar números de build da loja - Perfis e Flavors de Build.
Maestro smoke gates para submit: Dois a quatro fluxos curtos no build_id de produção antes do type: submit - Maestro E2E.
E2E permanece leve; Jest permanece amplo: Caminhos críticos no Maestro; cobertura de branch em testes unitários - Noções Básicas de Testes Mobile.
OTA apenas dentro de runtimeVersion: eas update envia JS compatível com binários da loja instalados - Política de Runtime Version.
Mudanças nativas exigem build de loja: Novos módulos Expo, plugins de configuração, atualizações de SDK - nunca apenas OTA - Noções Básicas de OTA Updates.
Canais de atualização explícitos: production, staging, preview - sem promoção acidental entre canais - Canais de Release e Branches.
Documentar rollback de OTA: eas update --roll-back ensaiado antes da primeira OTA de produção - Runbook de Rollback.
Calendário do trem de release é compartilhado: Mobile, backend e QA veem a mesma lista de dependências - API antes de quebrar mobile, flags antes de recursos visíveis - Calendário do Trem de Release.
Testes de contrato em verificações de PR: Desvios de forma da API detectados antes do nightly - especialmente quando o backend implanta continuamente - Testes de Contrato para APIs.
Nightlies detectam desvios de integração: Build completo agendado em main quando o volume de PR é alto - alertar, não bloquear merges.
Concorrência cancela execuções de PR obsoletas: cancel-in-progress: true - economiza minutos e reduz verificações vermelhas confusas em commits desatualizados.
Filtros de caminho de monorepo ou filtro Turbo: CI mobile pula quando apenas pacotes não relacionados mudam - mas nightlies ainda validam main completo.
Rollout escalonado após submit: Upload automatizado ≠ 100% dos usuários imediatamente - Play % escalonado e TestFlight faseado - Rollouts Escalonados.
Ambos é comum: GitHub para verificações de PR; EAS Workflows para cadeias de build → Maestro → submit. Mantenha os scripts npm idênticos.
Verificações de PR (lint + tsc + test) + eas build manual em tag. Adicione preview-on-PR e submit automatizado conforme o app cresce.
Módulo nativo, plugin de configuração, shell de navegação ou câmera/permissões - sim. Apenas cópia e teste unitário - não.
QA testando um binário e a loja recebendo outro. Fixe o build_id de ponta a ponta.
Sim - pelo menos nos fluxos de release e nightly. Detecta desvios de dependência antes de builds nativos caros.
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).
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026