Canais & Branches de Lançamento

Promoção de Staging → produção com EAS Update - um guia para canais, branches e o fluxo de promoção linear que mantém o QA de preview alinhado com o comportamento de produção.

Receita

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

// eas.json - canal por perfil de build
{
  "build": {
    "preview": { "distribution": "internal", "channel": "preview" },
    "production": { "channel": "production" }
  }
}

# Publicar para o branch de preview (soak)
eas update --branch preview --channel preview --environment preview \
  --message "feat: correção de validação de checkout"
 
# Após aprovação do QA - publicar o mesmo commit para o canal de produção
eas update --branch production --channel production --environment production \
  --message "promote: correção de validação de checkout"

# Inspecionar o que cada canal serve
eas channel:view production
eas update:list --branch production --limit 5

Quando usar isto:

• Configurando o primeiro fluxo development → preview → production.
• Promovendo um bundle de preview testado para usuários de produção.
• Mapeando branches Git para branches do EAS Update para equipes trunk-based.
• Auditando qual ID de bundle o canal de produção está servindo atualmente.

Quando evitar:

• Canais por engenheiro (jane-dev) - use builds de preview + atualizações de branch em vez disso.
• Publicação direta em produção a partir de um branch de funcionalidade sem soak de preview em caminhos de receita.
• Compartilhar um canal de produção entre dois IDs de bundle - white-label precisa de canais separados.

Exemplo de Trabalho

Promoção ponta a ponta de staging → preview → production com tabelas de canal/branch e gate de CI.

Passo 1 - Documentar o mapa de canais

<!-- docs/release-channels.md -->
| Channel      | Binary profile | Audience        | Who may publish      |
|--------------|----------------|-----------------|----------------------|
| development  | development    | Engineers       | Any dev (local)      |
| preview      | preview        | QA + stakeholders | Tech lead on-call  |
| staging      | preview*       | Pre-prod soak   | Release manager      |
| production   | production     | Store users     | CI tag only          |
 
* staging uses preview profile binary with `expo-channel-name: staging` header override if needed

Passo 2 - Conectar branches a canais

# Uma vez: garantir que os canais apontem para os branches pretendidos
eas channel:create preview
eas channel:create production
eas channel:edit preview --branch preview
eas channel:edit production --branch production

Passo 3 - Trabalho de funcionalidade em preview

git checkout -b fix/checkout-validation
# ... Apenas alterações em JS (seguras para OTA) ...
 
eas update --branch preview --channel preview --environment preview \
  --message "fix: regex de validação de cartão"

Passo 4 - QA no binário de preview

# QA instala o artefato eas build --profile preview
# Maestro smoke + caminho de pagamento manual em dispositivo físico
eas update:list --branch preview --limit 3

Passo 5 - Promover para produção (CI preferencial)

# .github/workflows/eas-update-production.yml (excerpt)
name: Promote OTA to production
on:
  workflow_dispatch:
    inputs:
      message:
        required: true
jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: eas update --branch production --channel production \
               --environment production \
               --message "${{ github.event.inputs.message }}"

O que isso demonstra:

• Branches armazenam o histórico de atualizações; canais são o ponteiro que os dispositivos consultam em tempo de execução
• O soak de preview acontece no mesmo canal que os binários de QA embutem via requestHeaders
• A promoção para produção é uma segunda publicação deliberada - não uma edição acidental de canal
• A publicação de produção apenas por CI deixa uma trilha de auditoria (eas update:list, logs do GitHub Actions)

Mergulho Profundo

Canais vs Branches

eas update --branch feature-x     →  escreve o bundle para o branch "feature-x"
eas channel:edit preview --branch feature-x   →  o canal preview agora serve feature-x
App consulta o canal "preview"      →  recebe a cabeça do branch feature-x

• eas update --channel production publica no branch atualmente vinculado a production
• Prefira --branch explícito ao promover para que o histórico permaneça rastreável
• eas channel:view <name> mostra o mapeamento do branch e o ID da atualização atual

Fluxo de Promoção Linear

development  →  preview (QA)  →  staging (soak opcional)  →  production
     ↑              ↑                      ↑                        ↑
  engenheiro      build interno        soak de 24–48h              apenas CI tag

• development: iteração rápida; pode quebrar; não para stakeholders
• preview: binário interno similar ao de release; smoke test do Maestro obrigatório
• staging (opcional): soak mais longo para autenticação/pagamento; mesma classe de binário que preview
• production: usuários da loja; regra de duas pessoas ou apenas CI

Mapeando Branches Git para Branches EAS

# Trunk-based: publicar de main para o branch preview
git checkout main
eas update --branch preview --channel preview --environment preview
 
# GitFlow: publicar de release/x.y para o branch staging
git checkout release/2.4
eas update --branch staging --channel staging --environment staging

• Branches EAS não estão automaticamente vinculados a branches Git - você impõe o mapeamento em CI
• Documente qual branch Git pode publicar para qual canal EAS em CONTRIBUTING.md
• Rejeite a publicação direta em production de branches de funcionalidade não mesclados

Padrão de Promoção por Republicação

Quando preview e production devem executar o mesmo artefato de bundle:

# Opção A - cherry-pick do commit e publicar para o branch de produção
git checkout main
git cherry-pick <preview-commit-sha>
eas update --branch production --channel production --environment production \
  --message "promote: <ticket-id>"
 
# Opção B - redirecionamento de canal (avançado; use com cuidado)
eas channel:edit production --branch preview
# Siga imediatamente com a divisão do branch se preview continuar divergindo

• A Opção A preserva o histórico Git claro por canal
• A Opção B é mais rápida, mas obscurece a semântica do branch - documente no runbook
• Sempre registre a janela de soak de preview e o ID do bundle no ticket de release

Armadilhas

• Header do canal ≠ canal do eas update - Binário construído com header preview nunca vê atualizações de production. Correção: Reconstruir ou corresponder o canal de publicação ao header embutido.
• Pular preview para "pequena" correção de pagamento - Incidentes custam mais do que tempo de soak. Correção: Mínimo de 24h de preview em caminhos de receita por Regras de Release & OTA.
• .env local na publicação de produção - Host de API errado no bundle OTA. Correção: Sempre eas update --environment production.
• Dois apps, um canal - App consumidor recebe JS do app de negócios. Correção: projectId, canal e ID de bundle separados por variante.
• OTA de produção na sexta-feira sem plantão de fim de semana - Rollback às 18h sem cobertura. Correção: Política nas regras de release.

Alternativas

FAQs

eas channel:view production
eas update:view <update-id>

Relacionados

• Noções Básicas de Atualizações OTA - Limites OTA vs loja
• Configuração do expo-updates - Conexão de requestHeaders
• Rollouts Graduais - Rollouts percentuais em canais
• Runbook de Rollback - Republicação de canal em minutos
• Noções Básicas do EAS Build - Perfis que embutem canais
• Regras de Release & OTA - Checklist de promoção de Nível 2

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