Fluxo e Distribuição
Última atualização: 6 de novembro de 2025
Visão Geral
Este documento descreve a estratégia completa de versionamento e distribuição dos aplicativos mobile da Vidya, contemplando tanto o Google Play Store (Android) quanto a Apple App Store (iOS). O objetivo é garantir lançamentos seguros, controlados e com capacidade de rollback rápido em caso de problemas.
✅ Estratégia Geral
Princípios Fundamentais
- Um único app e uma única versão para todos os clientes
- Diferenças entre clientes são feitas via configurações, feature flags e temas (não via versões diferentes)
- Versões são disponibilizadas de forma gradual para reduzir riscos
- Processo consistente entre Android e iOS, respeitando as particularidades de cada plataforma
Benefícios da Estratégia
| Benefício | Descrição |
|---|---|
| Menos risco | Rollout gradual detecta problemas antes de afetar todos |
| Menos retrabalho | Todos clientes na mesma versão |
| Suporte mais fácil | Uma versão = comportamento padronizado |
| Atualização contínua | Os clientes sempre recebem melhorias no tempo certo |
🤖 Fluxo de Publicação - Android (Google Play Store)
1) Teste Interno
Quem recebe:
- Time de implantação + suporte
Objetivo:
- Validar se o app funciona corretamente
Disparo:
- Toda nova versão gerada → vai automaticamente para Teste Interno
Características:
- Disponibilização imediata (sem revisão do Google)
- Ambiente controlado apenas para equipe interna
2) Teste Fechado
Quando usar:
- Mudanças grandes em fluxo
- Alterações em áreas sensíveis (login, checkout, pedidos, etc.)
- Validação de novas funcionalidades
Quem recebe:
- Pequeno grupo de usuários selecionados
Observação:
- Se o update for simples → pode pular essa etapa
3) Teste Aberto (Beta controlado por empresa)
Quem recebe:
- 1 representante por empresa (Pessoa responsável pela validação final antes da produção)
Objetivo:
- Validar funcionamento na operação real, antes da massa de usuários
Configuração:
- Criar lista de testers com e-mail dos representantes
- Enviar convite via Google Play Console
4) Produção (Lançamento Gradual)
Processo:
- Publica a versão nova como rollout gradual
- Começa em 10–20%
- Monitora erros/crashes
- Se ok → aumenta para 50%
- Se ok → 100%
Monitoramento:
- Acompanhar métricas de crash
- Verificar feedback de usuários
- Analisar logs de erro
🔙 Rollback Android
Se a versão está em rollout:
- Só interromper o rollout
- Automaticamente o Google Play volta a distribuir a versão anterior estável
Se a versão já estava em 100%:
- Play Console → Produção
- Versões anteriores
- Selecione a versão anterior
- Promover para Produção
- Escolha porcentagem (20% → 100%)
Facilidade de Rollback
Não precisa fazer novo build, nem reenviar APK. Apenas promove a versão estável anterior.
🍎 Fluxo de Distribuição - iOS (TestFlight + App Store)
1) TestFlight – Grupo Interno
Quem recebe:
- Time de implantação + suporte
Características:
- Não precisa aguardar revisão da Apple (build é liberado quase imediatamente)
- Permite testar apenas dentro da equipe
Objetivo:
- Garantir que o app está funcionando corretamente antes de enviar para testers externos
Disparo:
- Toda vez que gerar uma nova versão → enviar para o grupo interno automaticamente
2) TestFlight – Grupo Externo (Beta Controlado por Cliente)
Quem recebe:
- 1 representante por empresa (gerente, supervisor, power user)
Atenção:
- Para o grupo externo, a Apple precisa aprovar o build (geralmente 1 a 48 horas)
- Depois do primeiro build aprovado, os próximos são aprovados mais rápido
Objetivo:
- Validar que o app funciona no mundo real, antes de liberar para todos
Como organizar:
- Criar um grupo de testers externo com representantes definidos
- Enviar convites via link público do TestFlight ou e-mail
3) App Store – Lançamento Gradual (Phased Release)
Processo:
- Enviar para App Review
- Ao aprovar → usar "Phased Release" (Liberação gradual)
Configuração recomendada:
- Começa com 1%
- Depois 2%
- Depois 5%
- Depois 10%
- Depois 20% → 50% → 100%
Progressão Automática
A Apple faz a progressão automática diariamente, MAS você pode pausar/mudar quando quiser.
🔙 Rollback iOS
Se estiver em phased release (gradual):
- Basta pausar a liberação → isso congela a nova versão
- Todos novos usuários continuam recebendo a versão anterior
Se já estava 100% liberado:
Limitação do iOS
Reativar versão anterior NÃO É PERMITIDO pela Apple (ela bloqueia rollback direto)
Solução:
- Faça um rebuild da versão anterior (mesmo código)
- Suba novamente como "nova versão" (ex.: 1.8.2 → retroceder para 1.7.5 → vira 1.7.6)
- Envie para revisão (geralmente rápida, pois já foi aprovada antes)
- Liberar novamente (gradual)
Diferença entre Plataformas
iOS não permite promover build anterior igual ao Android — mas o Phased Release evita o impacto.
📊 Fluxogramas Visuais
Fluxo Android
Commit → CI Build → Teste Interno (implantação + suporte)
↓
Teste Fechado (opcional - mudanças críticas)
↓
Teste Aberto (1 representante por empresa)
↓
Produção → Rollout Gradual (10% → 50% → 100%)
↓
Se problema → Interromper rollout → Volta versão anterior
↓
Se já estava 100% → Promover versão anterior → Rollout gradual
Fluxo iOS
Commit → CI Build → TestFlight Interno (implantação + suporte)
↓
TestFlight Externo (1 tester por empresa)
↓
App Store → Lançamento Gradual (Phased Release)
↓
Se problema → Pausar rollout → Ficar na versão antiga
↓
Se já estava 100% → Rebuild da versão anterior → Re-submeter
🔥 Dicas e Boas Práticas
Para TestFlight (iOS)
| Item | Recomendação |
|---|---|
| Nome dos grupos | "Interno" e "Beta Clientes" |
| Notas de versão | Curta, clara e com foco em o que testar |
| Logs | Integrar com Firebase Crashlytics ou similar |
| Tempo de beta | Ideal de 2 a 5 dias antes da App Store |
Para Play Store (Android)
| Item | Recomendação |
|---|---|
| Rollout inicial | Começar com 10-20% para detectar problemas |
| Monitoramento | Acompanhar crashes e ANRs antes de aumentar % |
| Tempo entre fases | 24-48h entre cada aumento de porcentagem |
| Comunicação | Informar representantes sobre novidades antes do beta |
🎯 Comparativo entre Plataformas
| Aspecto | Android (Play Store) | iOS (App Store) |
|---|---|---|
| Revisão teste interno | ❌ Não requer | ❌ Não requer |
| Revisão teste externo | ❌ Não requer | ✅ Requer (1-48h) |
| Rollout gradual | ✅ Configurável manualmente | ✅ Phased Release automático |
| Rollback direto | ✅ Possível (promover versão antiga) | ❌ Requer rebuild |
| Tempo de aprovação | Instantâneo (sem revisão) | 1-48h (primeira vez), depois mais rápido |
| Controle granular | ✅ Escolha exata de % | ⚠️ Progressão automática (pausável) |
📝 Checklist de Lançamento
Antes de publicar:
- Código revisado e aprovado
- Testes automatizados passando
- Build gerado com sucesso
- Testado internamente (implantação + suporte)
- Notas de versão documentadas
- Representantes avisados sobre o beta
Durante o beta:
- Acompanhar feedback dos representantes
- Monitorar crashes e erros
- Validar funcionalidades críticas
- Documentar issues encontradas
Antes de ir para produção:
- Beta aprovado pelos representantes
- Sem crashes críticos
- Métricas de performance OK
- Plano de rollback preparado
- Equipe de suporte alertada
Durante rollout gradual:
- Monitorar crashes em tempo real
- Acompanhar feedback de usuários
- Verificar métricas de adoção
- Preparado para pausar/reverter se necessário
🚨 Procedimentos de Emergência
Se detectar problema crítico:
- Imediatamente pausar o rollout
- Avaliar a gravidade do problema
- Decidir: fix rápido ou rollback?
- Se rollback: seguir procedimento específico da plataforma
- Comunicar a equipe e usuários afetados
- Documentar o incidente
- Planejar correção
Comunicação de incidente:
- Informar gerência imediatamente
- Avisar equipe de suporte
- Se necessário, comunicar clientes afetados
- Documentar cronologia e ações tomadas