Habilidade EAS Release

Q: A habilidade pode executar eas submit para o track de produção do Play automaticamente?

Tecnicamente sim via track: "production" - salvaguarda: padrão para internal até que o QA aprove. A habilidade deve avisar quando o track de produção for solicitado.

Etapas de build, envio e OTA com salvaguardas - uma Habilidade de Agente estilo cookbook para enviar binários e atualizações do Expo SDK 57 sem automação insegura.

O Que Esta Habilidade Faz

Produz um plano de release executável: seleção de perfil eas.json, comandos de build na nuvem, etapas de envio para a loja e eas update opcional - cada um protegido por runtimeVersion, credenciais e classificação de alteração.

Quando Invocar

Primeiro release de produção ou novo perfil eas.json
Escolhendo OTA vs. binário da loja para um hotfix
Conectando --auto-submit ou envio não interativo de CI
Adicionando distribuição preview/interna antes da produção
Release pós-merge em branches release/*

Entradas

Entrada	Por quê
`eas.json`	Perfis, env, destinos de envio
`app.config.ts`	`version`, `runtimeVersion`, IDs de bundle
Lista de alterações	Apenas JS vs. nativas (módulos, permissões, plugins)
Canal/branch de destino	`production`, `preview`, etc.
Último `updateId` conhecido como bom	Âncora de rollback para o caminho OTA
Escopo da plataforma	`ios`, `android`, `all`

Saídas

Lista de comandos ordenada com variantes de CI --non-interactive
Alertas de risco (credenciais, rollout faseado, seleção de track)
Verificação: eas build:list, eas submit, eas channel:view, npx expo-doctor
Parada explícita se a alteração impacta nativamente mas foi solicitada manualmente apenas OTA

Salvaguardas

Alteração nativa → eas build. Novo módulo expo-*, permissão, plugin de configuração ou edição de expo-build-properties nunca é apenas OTA.
runtimeVersion deve corresponder aos binários ativos da loja para OTA - veja Política de Runtime Version.
Envie primeiro para o canal interno/TestFlight - o rollout do track Play de produção é uma etapa separada no console (EAS Submit).
Segredos em ambientes EAS - não em arquivos .env commitados (Build Profiles & Flavors).
Pause o rollout faseado/gradual antes do binário de hotfix quando uma tempestade de crashes estiver ativa.
Execute npx expo-doctor após qualquer alteração de dependência ou plugin gerada pela habilidade.

Receita

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

# 1. Classificar alteração
npx expo-doctor
git diff --name-only HEAD~1   # verificar package.json, app.config.ts, plugins/
 
# 2. Build na nuvem (formato de loja)
eas build --profile production --platform all --non-interactive
 
# 3. Enviar artefatos mais recentes
eas submit --platform ios --latest --non-interactive
eas submit --platform android --latest --non-interactive
 
# 4. Hotfix apenas JS (mesmo runtimeVersion)
eas update --channel production --message "fix: checkout validation copy"
 
# 5. Verificar
eas channel:view production
eas build:list --limit 3

// eas.json (excerto - SDK 57)
{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production",
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {
      "ios": { "ascAppId": "1234567890" },
      "android": {
        "serviceAccountKeyPath": "./secrets/play-service-account.json",
        "track": "internal"
      }
    }
  }
}

Quando usar esta habilidade:

O capitão de release precisa de um checklist único antes do deploy de sexta-feira
O agente é solicitado a "enviar a correção" sem especificar OTA vs. binário
Novo engenheiro em onboarding para EAS - a habilidade impõe salvaguardas que a documentação sozinha pode pular

Exemplo de Trabalho

Etapa 0 - Classificar a alteração

npx expo-doctor

Sinal	Caminho
Apenas `.tsx`, hooks, cópia	Candidato a OTA
`package.json` novo `expo-camera`	Build necessário
`app.config.ts` plugin adicionado	Build necessário
Hermes / bump de versão RN	Build necessário + revisão de `runtimeVersion`

Etapa 1 - Build

eas build --profile production --platform all
# Um tiro para CI:
eas build --profile production --platform ios --auto-submit --non-interactive

developmentClient: true → cliente de desenvolvimento, não loja - EAS Build Basics
Equipes CNG: diretórios nativos gerados no servidor - Prebuild Basics

Etapa 2 - Envio

eas submit --platform ios --latest
eas submit --platform android --latest

Android track: "internal" em eas.json - promova no Play Console depois
iOS vai para o TestFlight - o rollout faseado é uma etapa do App Store Connect

Etapa 3 - OTA (apenas JS)

eas update --channel production --message "fix: cart total rounding"
eas channel:view production

Registre o updateId publicado no ticket de release - Rollback Runbook
Rollout OTA faseado: Staged Rollouts

Etapa 4 - Verificar

npx expo-doctor
eas build:list --limit 1
eas update:list --branch production --limit 3

Exemplos de Prompts de Invocação

Invoke EAS Release skill. SDK 57.
Change: fixed typo in Settings screen - no package.json diff.
Give OTA commands for production channel. Include rollback note with last good updateId f7a2.

Invoke EAS Release skill.
Added expo-notifications + config plugin in app.config.ts.
Produce full build + submit checklist for ios and android production profiles.
Flag anything that blocks OTA.

Invoke EAS Release skill for CI.
Need non-interactive eas build --auto-submit on merge to release/2.4.
List required EAS secrets and eas.json submit block only.

Decisão: OTA vs. Binário da Loja

                    ┌─────────────────┐
                    │  Alteração chegou │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │ expo-doctor OK? │──não──► corrigir config/deps primeiro
                    └────────┬────────┘
                             │ sim
                    ┌────────▼────────────────┐
                    │ Alteração impacta nativo? │
                    └────────┬────────────────┘
                         sim │      │ não
              ┌──────────────┘      └──────────────┐
              ▼                                    ▼
      eas build + submit                  runtimeVersion
      (novo binário)                      corresponde à loja?
                                                    │
                                    sim ──► eas update
                                    não  ──► eas build (aumentar runtimeVersion)

FAQs

A habilidade pode executar eas submit para o track de produção do Play automaticamente?

Tecnicamente sim via track: "production" - salvaguarda: padrão para internal até que o QA aprove. A habilidade deve avisar quando o track de produção for solicitado.

O --auto-submit pula os testes do TestFlight?

Não - ele carrega o binário. A distribuição do TestFlight e a Revisão do App ainda são etapas do console, a menos que seu fluxo de trabalho promova separadamente.

E se o expo-doctor falhar no meio do release?

Pare. A saída da habilidade não deve incluir submit/OTA até que o doctor passe. Corrija a discrepância com npx expo install --fix conforme SDK Upgrade Skill.

Relacionados

EAS Build Basics - perfis, primeiro build na nuvem
EAS Submit - cookbook de upload ASC e Play
Build Profiles & Flavors - env e credenciais
OTA Updates Basics - canais e branches
Rollback Runbook - recuperação de OTA ruim
Mobile CI/CD Basics - integração de pipeline
Agent Skills Basics - estrutura SKILL.md

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

O Que Esta Habilidade Faz

Quando Invocar

Primeiro release de produção ou novo perfil eas.json
Escolhendo OTA vs. binário da loja para um hotfix
Conectando --auto-submit ou envio não interativo de CI
Adicionando distribuição preview/interna antes da produção
Release pós-merge em branches release/*

Entradas

Entrada	Por quê
`eas.json`	Perfis, env, destinos de envio
`app.config.ts`	`version`, `runtimeVersion`, IDs de bundle
Lista de alterações	Apenas JS vs. nativas (módulos, permissões, plugins)
Canal/branch de destino	`production`, `preview`, etc.
Último `updateId` conhecido como bom	Âncora de rollback para o caminho OTA
Escopo da plataforma	`ios`, `android`, `all`

Saídas

Lista de comandos ordenada com variantes de CI --non-interactive
Alertas de risco (credenciais, rollout faseado, seleção de track)
Verificação: eas build:list, eas submit, eas channel:view, npx expo-doctor
Parada explícita se a alteração impacta nativamente mas foi solicitada manualmente apenas OTA

Salvaguardas

Alteração nativa → eas build. Novo módulo expo-*, permissão, plugin de configuração ou edição de expo-build-properties nunca é apenas OTA.
runtimeVersion deve corresponder aos binários ativos da loja para OTA - veja Política de Runtime Version.
Envie primeiro para o canal interno/TestFlight - o rollout do track Play de produção é uma etapa separada no console (EAS Submit).
Segredos em ambientes EAS - não em arquivos .env commitados (Build Profiles & Flavors).
Pause o rollout faseado/gradual antes do binário de hotfix quando uma tempestade de crashes estiver ativa.
Execute npx expo-doctor após qualquer alteração de dependência ou plugin gerada pela habilidade.

Receita

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

# 1. Classificar alteração
npx expo-doctor
git diff --name-only HEAD~1   # verificar package.json, app.config.ts, plugins/
 
# 2. Build na nuvem (formato de loja)
eas build --profile production --platform all --non-interactive
 
# 3. Enviar artefatos mais recentes
eas submit --platform ios --latest --non-interactive
eas submit --platform android --latest --non-interactive
 
# 4. Hotfix apenas JS (mesmo runtimeVersion)
eas update --channel production --message "fix: checkout validation copy"
 
# 5. Verificar
eas channel:view production
eas build:list --limit 3

// eas.json (excerto - SDK 57)
{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production",
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {
      "ios": { "ascAppId": "1234567890" },
      "android": {
        "serviceAccountKeyPath": "./secrets/play-service-account.json",
        "track": "internal"
      }
    }
  }
}

Quando usar esta habilidade:

O capitão de release precisa de um checklist único antes do deploy de sexta-feira
O agente é solicitado a "enviar a correção" sem especificar OTA vs. binário
Novo engenheiro em onboarding para EAS - a habilidade impõe salvaguardas que a documentação sozinha pode pular

Exemplo de Trabalho

Etapa 0 - Classificar a alteração

npx expo-doctor

Sinal	Caminho
Apenas `.tsx`, hooks, cópia	Candidato a OTA
`package.json` novo `expo-camera`	Build necessário
`app.config.ts` plugin adicionado	Build necessário
Hermes / bump de versão RN	Build necessário + revisão de `runtimeVersion`

Etapa 1 - Build

eas build --profile production --platform all
# Um tiro para CI:
eas build --profile production --platform ios --auto-submit --non-interactive

developmentClient: true → cliente de desenvolvimento, não loja - EAS Build Basics
Equipes CNG: diretórios nativos gerados no servidor - Prebuild Basics

Etapa 2 - Envio

eas submit --platform ios --latest
eas submit --platform android --latest

Android track: "internal" em eas.json - promova no Play Console depois
iOS vai para o TestFlight - o rollout faseado é uma etapa do App Store Connect

Etapa 3 - OTA (apenas JS)

eas update --channel production --message "fix: cart total rounding"
eas channel:view production

Registre o updateId publicado no ticket de release - Rollback Runbook
Rollout OTA faseado: Staged Rollouts

Etapa 4 - Verificar

npx expo-doctor
eas build:list --limit 1
eas update:list --branch production --limit 3

Exemplos de Prompts de Invocação

Invoke EAS Release skill. SDK 57.
Change: fixed typo in Settings screen - no package.json diff.
Give OTA commands for production channel. Include rollback note with last good updateId f7a2.

Invoke EAS Release skill.
Added expo-notifications + config plugin in app.config.ts.
Produce full build + submit checklist for ios and android production profiles.
Flag anything that blocks OTA.

Invoke EAS Release skill for CI.
Need non-interactive eas build --auto-submit on merge to release/2.4.
List required EAS secrets and eas.json submit block only.

Decisão: OTA vs. Binário da Loja

                    ┌─────────────────┐
                    │  Alteração chegou │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │ expo-doctor OK? │──não──► corrigir config/deps primeiro
                    └────────┬────────┘
                             │ sim
                    ┌────────▼────────────────┐
                    │ Alteração impacta nativo? │
                    └────────┬────────────────┘
                         sim │      │ não
              ┌──────────────┘      └──────────────┐
              ▼                                    ▼
      eas build + submit                  runtimeVersion
      (novo binário)                      corresponde à loja?
                                                    │
                                    sim ──► eas update
                                    não  ──► eas build (aumentar runtimeVersion)

FAQs

A habilidade pode executar eas submit para o track de produção do Play automaticamente?

Tecnicamente sim via track: "production" - salvaguarda: padrão para internal até que o QA aprove. A habilidade deve avisar quando o track de produção for solicitado.

O --auto-submit pula os testes do TestFlight?

Não - ele carrega o binário. A distribuição do TestFlight e a Revisão do App ainda são etapas do console, a menos que seu fluxo de trabalho promova separadamente.

E se o expo-doctor falhar no meio do release?

Pare. A saída da habilidade não deve incluir submit/OTA até que o doctor passe. Corrija a discrepância com npx expo install --fix conforme SDK Upgrade Skill.

Relacionados

EAS Build Basics - perfis, primeiro build na nuvem
EAS Submit - cookbook de upload ASC e Play
Build Profiles & Flavors - env e credenciais
OTA Updates Basics - canais e branches
Rollback Runbook - recuperação de OTA ruim
Mobile CI/CD Basics - integração de pipeline
Agent Skills Basics - estrutura SKILL.md

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

Habilidade EAS Release

Buscar na documentação

Habilidade EAS Release