Noções Básicas de CI/CD Mobile

10 exemplos para entender verificações de PR, pipelines de lançamento e compilações noturnas para aplicativos Expo SDK 57 - 7 básicos e 3 intermediários.

Pré-requisitos

CI/CD para React Native difere da web: você envia binários nativos (compilações de loja) e, opcionalmente, pacotes JavaScript OTA (Noções Básicas de OTA Updates). Compilações na nuvem via Noções Básicas de EAS Build mantêm as chaves de assinatura fora dos laptops.

npx create-expo-app@latest ShipApp --template blank-typescript
cd ShipApp
npx expo install eas-cli --save-dev
npx eas-cli@latest build:configure

Padronize os scripts que a CI chamará:

{
  "scripts": {
    "lint": "expo lint",
    "typecheck": "tsc --noEmit",
    "test": "jest",
    "format:check": "prettier --check ."
  }
}

Ferramentas: Estes exemplos visam Expo SDK 57 (expo ~57.0.4), React Native 0.86.0 e React 19.2.3. Snippets E2E assumem compilações de desenvolvimento ou de pré-visualização - não apenas Expo Go.

Exemplos Básicos

1. Três Tipos de Pipeline

Equipes mobile executam três fluxos de automação distintos com diferentes metas de velocidade, custo e raio de explosão.

┌─────────────────────────────────────────────────────────────┐
│ Verificações de PR   │ Todo PR      │ 2–8 min  │ Bloqueia mesclagem │
├──────────────────┼──────────────┼──────────┼───────────────┤
│ Pipeline de lançamento │ Tag / main   │ 20–60 min│ Loja + OTA    │
├──────────────────┼──────────────┼──────────┼───────────────┤
│ Noturno          │ Cron 02:00   │ 30–90 min│ Sinal de desvio │
└─────────────────────────────────────────────────────────────┘

• Verificações de PR falham rapidamente - sem compilação nativa até que TypeScript e testes unitários passem
• Pipelines de lançamento produzem o mesmo artefato que o QA assinou e que as lojas recebem
• Noturnos capturam "PRs verdes, quebrados juntos" quando vinte branches pousam durante a noite

Relacionado: Portões de Qualidade de CI - scripts que as verificações de PR chamam

2. Verificações de PR - O que é Executado em Cada Solicitação de Pull Request

A automação de PR responde: "Esta alteração é segura para mesclar?" - não "Está pronta para a App Store?"

# .github/workflows/pr-checks.yml
name: PR Checks
on:
  pull_request:
    branches: [main]
 
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npx expo customize tsconfig.json
      - run: npm run format:check
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test -- --ci

• Executa em cada push para um PR aberto - os desenvolvedores recebem feedback antes da revisão
• Sem EAS build em cada PR, a menos que compilações de pré-visualização sejam explicitamente orçadas (Preview Builds on PRs)
• A proteção de branch requer a verificação quality - política, não sistema de honra
• Mesmos comandos localmente: npm run lint && npm run typecheck && npm test

Relacionado: Noções Básicas de Testes Mobile - camadas da pirâmide que as verificações de PR cobrem

3. Pipeline de Lançamento - Tag para Binário de Loja

A automação de lançamento responde: "Construa e envie a versão que marcamos."

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ["v*"]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: npm run typecheck && npm run test -- --ci
      - run: eas build --profile production --platform all --non-interactive

// eas.json (excerto)
{
  "build": {
    "production": {
      "autoIncrement": true,
      "channel": "production"
    }
  }
}

• Gatilho em tags Git semver (v2.4.0) - rastreabilidade tag ↔ binário
• Conta de robô EXPO_TOKEN - nunca senhas pessoais em CI (GitHub Actions + EAS)
• Perfil production mapeia para credenciais de assinatura da loja no EAS
• QA testa o ID de build deste pipeline - não um arquivo do laptop

Relacionado: Perfis e Sabores de Build - preview vs production

4. Compilações Noturnas - Capturar Desvio de Integração

Quando o volume de PR é alto, verificações verdes individuais escondem falhas de integração entre branches. As compilações noturnas rodam em um cronograma sem bloquear mesclagens.

# .github/workflows/nightly.yml
name: Nightly Integration
on:
  schedule:
    - cron: "0 6 * * 1-5"  # dias úteis 06:00 UTC
  workflow_dispatch:
 
jobs:
  nightly:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { ref: main }
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: npx expo-doctor
      - run: npm run test -- --ci
      - run: eas build --profile preview --platform android --non-interactive

• Canal de alertas (#mobile-ci) em caso de falha - não bloqueie mesclagens diurnas
• Inclua npx expo-doctor - captura desvios de SDK que ninguém tocou nos PRs de hoje
• Construa uma plataforma noturna se os créditos forem limitados; alterne iOS/Android semanalmente
• Emparelhe com testes de contrato contra APIs de staging (Contract Tests for APIs)

5. Verificações de PR vs. Compilações de Pré-visualização

Nem todo PR precisa de um binário nativo. Separe portões rápidos de compilações de pré-visualização opcionais.

# Pré-visualização controlada por rótulo - economiza créditos EAS
on:
  pull_request:
    types: [labeled]
jobs:
  preview:
    if: contains(github.event.pull_request.labels.*.name, 'needs-preview')
    # ... eas build --profile preview

• Padrão: apenas portões de qualidade - pré-visualização por rótulo ou filtro paths para diretórios que afetam o nativo
• Compilações de pré-visualização instalam via QR code em dispositivos reais - veja Preview Builds on PRs
• Documente o rótulo em CONTRIBUTING.md para que os designers saibam quando adicionar needs-preview

6. OTA no Trem de Lançamento

Correções apenas de JS são enviadas via eas update dentro do pipeline de lançamento - alterações nativas ainda precisam de eas build.

# .eas/workflows/release-ota.yml (excerto)
jobs:
  quality:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - run: npm run typecheck && npm run test -- --ci
 
  update_production:
    needs: [quality]
    type: update
    params:
      channel: production
      message: ${{ github.sha }}

• OTA executa após os mesmos scripts de qualidade das verificações de PR
• runtimeVersion deve corresponder ao binário da loja que os usuários instalaram - Política de Runtime Version
• Nunca envie um pacote OTA que importe um módulo nativo ausente do binário instalado
• Caminho de reversão: eas update --roll-back - Rollback Runbook

7. Promoção de Artefatos - Mesma Compilação CI para Loja

O anti-padrão: QA testa uma compilação de laptop; as lojas recebem uma compilação de nuvem diferente.

❌ Compilação de laptop → Aprovação de QA → Recompilação CI → Loja
✅ ID de compilação EAS abc123 → Aprovação de QA → eas submit --id abc123 → Loja

# Promova a compilação exata que o QA testou
eas submit --platform ios --id <BUILD_ID> --non-interactive
eas submit --platform android --id <BUILD_ID> --non-interactive

• Armazene IDs de compilação nas notas de lançamento e threads do Slack
• eas submit --latest é conveniente, mas arriscado se uma compilação mais recente foi enfileirada após o QA
• Promoção Automatizada de Loja controla o envio em Maestro smoke

Relacionado: EAS Submit - Handoff do App Store Connect e Play Console

Exemplos Intermediários

8. Gatilhos de PR Cientes de Monorepo

Monorepos Turborepo não devem executar CI mobile quando apenas o site de marketing mudou.

on:
  pull_request:
    paths:
      - "apps/mobile/**"
      - "packages/ui/**"
      - "package-lock.json"

# Ou ação de filtro de caminho
- uses: dorny/paths-filter@v3
  id: changes
  with:
    filters: |
      mobile:
        - 'apps/mobile/**'
        - 'packages/**'
- if: steps.changes.outputs.mobile == 'true'
  run: npm run typecheck -w apps/mobile

• Mudanças no lockfile raiz sempre acionam o mobile - o grafo de dependências pode ter mudado
• turbo run lint typecheck test --filter=mobile distribui com cache - GitHub Actions + EAS
• Noturno ainda constrói main completo - filtros de caminho são para velocidade de PR, não cobertura de integração

9. Trem de Lançamento com Portões Escalonados

Equipes avançadas encadeiam qualidade → compilação → E2E → envio em um único arquivo de fluxo de trabalho.

# .eas/workflows/store-release.yml (esboço)
name: Store Release
on:
  push:
    tags: ["v*"]
 
jobs:
  quality:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - run: npm run lint && npm run typecheck && npm run test -- --ci
 
  build_ios:
    needs: [quality]
    type: build
    params: { platform: ios, profile: production }
 
  smoke_ios:
    needs: [build_ios]
    type: maestro
    params:
      build_id: ${{ needs.build_ios.outputs.build_id }}
      flow_path: [".maestro/smoke.yml"]
 
  submit_ios:
    needs: [smoke_ios]
    type: submit
    params:
      platform: ios
      build_id: ${{ needs.build_ios.outputs.build_id }}

• needs encadeia e impõe a ordem - o envio não pode ocorrer se o Maestro falhou
• Fluxos de smoke permanecem curtos - login, home, uma aba crítica (Maestro E2E)
• Android e iOS podem paralelizar após a qualidade - veja a lista de verificação EAS Workflows

10. Coordenando JS, Nativo e Backend

Lançamentos mobile raramente ocorrem sozinhos. Documente dependências de implantação em um calendário de lançamento.

Trem de lançamento da Semana 12
  Ter - API Backend v3 implanta em staging (testes de contrato verdes)
  Qua - eas build production (nativo + JS embarcado)
  Qui - eas update production (hotfix JS se necessário, mesma runtimeVersion)
  Sex - eas submit após Maestro + QA manual
  Seg - Rollout escalonado 10% → 50% → 100%

• Release Train Calendar expande o modelo de calendário
• Feature flags desacoplam binário ativo de recurso visível - Feature Flags for Safe Rollout
• Testes de contrato em verificações de PR capturam desvios de forma de API antes do noturno

Anti-Padrões

FAQs

Relacionados

• EAS Workflows - Lista de verificação YAML para trabalhos de build, teste, submit, update
• GitHub Actions + EAS - segredos, cache, gatilhos de monorepo
• Preview Builds on PRs - distribuição de QR para QA
• EAS Build Basics - primeira compilação na nuvem e eas.json
• OTA Updates Basics - o que o OTA pode mudar
• Mobile Testing Basics - pirâmide de testes para camadas de CI
• CI/CD Best Practices - Resumo de 25 itens

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).