Dia de lançamento no desenvolvimento de aplicativos: essência, etapas e preparação
O dia de lançamento (release day) é a data programada para o lançamento de uma nova versão de um aplicativo móvel, incluindo preparação do build, revisão da loja, staged rollout e monitoramento. Para aplicativos iOS, o processo começa com o upload do build para o App Store Connect 24-48 horas antes da data de lançamento planejada devido à revisão obrigatória da Apple. Para Android, o build é montado e enviado ao Google Play Console, onde o processo de revisão geralmente leva de 1 a 4 horas. De acordo com as Apple Developer Guidelines (2025), 90% dos builds passam pela revisão em 24 horas. Staged rollout permite minimizar o impacto caso erros sejam descobertos após a publicação.
Principais pontos
- Dia de lançamento — conjunto de atividades da preparação do build ao monitoramento pós-rollout
- Staged rollout — rollout gradual: 1%, 10%, 50%, 100%
- Smoke testing — verificação final do build antes de enviar à loja
- Plano de rollback — cenário de reversão pré-preparado para erros críticos
- Retrospectiva do lançamento — análise do processo após a conclusão do rollout em 100%
O que é o dia de lançamento e como se preparar
O dia de lançamento não é apenas o momento de apertar o botão Publicar. É um processo coordenado envolvendo desenvolvedores, QA, DevOps, gerentes de produto e, às vezes, suporte. A preparação começa 2-3 semanas antes do dia do lançamento: definição de escopo, code freeze, testes de regressão, preparação de notas de versão e materiais de marketing. Quanto mais minuciosa a preparação, mais tranquilo será o dia do lançamento.
A lista de verificação para a preparação do dia de lançamento inclui: execução final de QA (suíte de regressão + smoke) no build de lançamento; verificação de metadados nas lojas (nome, descrição, screenshots, keywords); acordo sobre a porcentagem de staged rollout com o gerente de produto; preparação do plano de rollback (qual tag redeploy, quanto tempo levará); notificação à equipe e serviços relacionados sobre o próximo lançamento. Release checklist deve ser automatizado via CI/CD — por exemplo, como um workflow do GitHub Actions que verifica todos os pontos antes de criar a tag de lançamento.
Um elemento importante da preparação é o blackout period (período em que deploys em produção são proibidos). Normalmente, o blackout é introduzido 48 horas antes do dia de lançamento e suspenso 24 horas após um rollout bem-sucedido em 100%. Change freeze durante o blackout se aplica a todos os serviços relacionados ao lançamento.
Preparação do build: code freeze, marcação e montagem
24-48 horas antes do dia de lançamento, é introduzido um code freeze — uma parada completa de alterações no código. Os desenvolvedores se dedicam à preparação de documentação e notas de versão. O DevOps monta o build de lançamento a partir de uma tag fixada (ex.: v2.6.0-rc1). O build passa por uma suíte completa de regressão (testes automatizados + manuais). Se forem encontrados bugs críticos, eles são corrigidos antes do code freeze ou o lançamento é adiado. Release candidate (RC) — um build que passou pelo QA e está pronto para envio à loja.
Tagging no Git: uma tag anotada é criada (git tag -a v2.6.0 -m “Release v2.6.0”). O pipeline de CI/CD compila um AAB (Android App Bundle) para o Google Play e um IPA (iOS App Store Package) para a Apple App Store. O build é acompanhado por: arquivo de soma de verificação (SHA256), changelog e lista de problemas conhecidos (known issues). Reproducible builds — uma prática ideal onde recompilar a partir da mesma tag produz um resultado binariamente idêntico.
bash
# Pipeline de release — criação de tag e compilação
# Assume que o code freeze já está ativo
# Criar branch de release a partir de develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: regras de proteção de branch bloqueiam novos PRs
# Executar suíte de regressão no CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Criar tag de release após QA bem-sucedido
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Compilar binário de release via CI/CD
# fastlane build_release produz AAB + universal APK
fastlane build_releaseImportante: o version bump (atualização de version code e version name) é feito antes do code freeze. Após o code freeze, a versão não muda. Para Android: versionCode — um inteiro monotonicamente crescente; versionName — versão semântica (2.6.0). Para iOS: CFBundleVersion (build number) e CFBundleShortVersionString (versão semântica). Versioning deve ser automatizado no gradle/xcconfig.
Upload na loja e processo de revisão
Para iOS: o build é enviado via Xcode, Transporter ou fastlane para o App Store Connect. Após o upload, o build passa por uma verificação automática da Apple (processing) e é enviado para revisão manual. O tempo médio de revisão é de 24 horas, mas pode variar de 1 hora a 7 dias dependendo da carga de trabalho dos revisores da Apple e dos requisitos de compliance. Expedited review — uma solicitação de revisão acelerada para correções de bugs críticos (disponível no máximo uma vez por mês, não garantida).
Para Android: o build é enviado via Google Play Console. O Google usa uma abordagem combinada: testes automatizados (acessibilidade, malware, conformidade com políticas) + revisão manual seletiva. O tempo médio de revisão é de 1 a 4 horas. Internal test track e Closed track permitem testes finais antes da publicação no Production track. Recomendação: 1-2 dias em Internal test → 1 dia em Closed beta → rollout gradual em Production.
Para ambas as plataformas, é fundamental verificar os metadados antes de enviar o build: nome do aplicativo, descrição (curta + completa), screenshots para cada dispositivo compatível (iPhone 6.5″, 5.5″, iPad, telefone Android, tablet), keywords (iOS) ou experiments de store listing (Android). Um erro nos metadados pode atrasar a revisão em um dia adicional. App metadata deve ser localizada para todos os idiomas compatíveis.
Staged rollout: como distribuir um lançamento sem riscos
Staged rollout (rollout gradual, implantação em fases) é uma estratégia onde uma nova versão se torna disponível para os usuários gradualmente, não de uma só vez. Um esquema típico para uma equipe madura: 1% dos usuários (primeiras 2-4 horas) → 10% (24 horas) → 25% (24 horas) → 50% (24 horas) → 100%. Cada etapa inclui monitoramento de métricas e verificação de ausência de erros críticos. Staged rollout é a principal ferramenta para minimizar riscos durante lançamentos.
O Google Play Console oferece staged rollout integrado: você pode especificar uma porcentagem de usuários e agendar aumentos graduais. Para o iOS App Store Connect, não há esse recurso integrado — o staged rollout é implementado através do Phased Release (aumento automático de cobertura ao longo de 7 dias com possibilidade de pausa) ou através de feature flags no servidor com geodistribuição. Phased release no App Store Connect permite pausar o lançamento se problemas forem detectados.
Métricas principais para avançar para a próxima etapa: crash-free rate (≥99.9% para o novo lançamento), taxa de ANR (Android, ≤0.1%), taxa de erro na API backend (≤0.5% 5xx), avaliações dos usuários (não inferiores à versão anterior), apdex score (≥0.94). Se qualquer métrica exceder o limite, o rollout é pausado até que a causa seja determinada. Go/no-go gate em cada etapa é responsabilidade do release manager ou do engenheiro de plantão.
Monitoramento pós-lançamento: o que observar nas primeiras horas
As primeiras 4 horas após o lançamento são o momento mais crítico. A equipe monitora a taxa de crashes (Sentry, Firebase Crashlytics, App Center), a taxa de erro 5xx no backend, eventos personalizados (pagamentos bem-sucedidos, logins, registros), avaliações na App Store e Google Play e menções em redes sociais (Twitter, Reddit). O dashboard de monitoramento deve ser preparado com antecedência e estar disponível em uma tela grande no escritório ou em um canal dedicado do Slack. Release dashboard — um painel único para todas as métricas do lançamento.
Atenção especial às métricas de regressão: comparar a taxa de crashes com a versão anterior em um período similar. Se a taxa de crashes aumentou mais de 0,1%, isso é uma bandeira vermelha que requer análise imediata. Também é importante comparar a latência mediana e p95 dos endpoints de API principais: mesmo sem crashes, um aumento de 200ms no tempo de resposta pode sinalizar um problema. Metric comparison (baseline vs atual) é automatizada no Datadog ou Grafana.
O feedback dos usuários é tão importante quanto as métricas numéricas. Nas primeiras horas após um lançamento, os usuários deixam ativamente avaliações nas lojas e escrevem para o suporte. Bugs não capturados pelos testes surgem rapidamente nas avaliações. O líder da equipe ou um engenheiro de QA designado monitora as avaliações a cada 30 minutos nas primeiras 4 horas e as classifica: falso positivo, problema conhecido (já na lista de known issues), novo bug. New bugs P0/P1 — um gatilho para pausar o rollout.
Rollback: quando e como reverter um lançamento
Rollback é a reversão para uma versão estável anterior quando problemas críticos são descobertos. A decisão de fazer rollback é tomada pelo release manager em conjunto com o tech lead se: a taxa de crashes do novo lançamento cair abaixo de 99%, um vazamento de dados for detectado, a funcionalidade crítica (pagamentos, autenticação) não funcionar para mais de 5% dos usuários, ou a loja (App Store Review) rejeitar o build após a publicação. Rollback trigger deve ser definido antes do lançamento para que a decisão seja baseada em fatos, não emoções.
Para Android: rollback no Google Play Console significa parar o staged rollout e alternar para a versão anterior. Se o build atual já estiver em 100% dos usuários, publique a versão anterior como um novo lançamento. Para iOS: através do App Store Connect — Phased Release → Pause Release → lançar uma nova versão com a correção (App Store não permite reverter para uma versão anterior). Rollback no iOS é mais complexo: o desenvolvedor precisa compilar um novo build com revert commits e passar pela revisão novamente.
Após um rollback, a equipe entra em modo de incidente: análise de causa raiz, hotfix ou próximo lançamento com a correção, post-mortem. Rollback não é uma falha, mas um procedimento padrão. Equipes que nunca fizeram rollback provavelmente não estão percebendo problemas, não que estejam lançando versões sem bugs. Rollback rate é uma das métricas DORA: equipes de alto desempenho fazem rollback em menos de 10% dos lançamentos e se recuperam em menos de 1 hora.
Perguntas frequentes
Em qual dia é melhor lançar um aplicativo móvel?
Os melhores dias são terça, quarta ou quinta-feira. Segunda-feira tem alto tráfego do fim de semana, e sexta-feira traz o risco de entrar no fim de semana com um lançamento problemático. Evite sexta-feira: se um problema for descoberto após o deploy, a equipe estará corrigindo durante o fim de semana ou esperando até segunda-feira.
O que fazer se o App Store Review rejeitar o build?
Leia o motivo da rejeição no Resolution Center, corrija e reenvie o build. Causas comuns: links quebrados, campos incompletos, conteúdo sem assinatura (se exigido), screenshots desatualizadas. Rejeição do App Review atrasa o lançamento em 24-48 horas, portanto o primeiro upload do build deve ser feito 3-5 dias antes da data de lançamento planejada.
Qual porcentagem de staged rollout é ideal para começar?
Para lançamentos grandes (mudanças importantes) — 1%. Para lançamentos de patch — 5-10%. O primeiro estágio deve ser pequeno o suficiente para que, em caso de erro, o impacto seja mínimo, mas grande o suficiente para obter métricas estatisticamente significativas. 1% para um aplicativo com 10 milhões de usuários são 100.000 pessoas — suficiente para detectar problemas críticos.
Deve-se fazer uma festa de lançamento?
Uma festa de lançamento (celebração da equipe) é opcional, mas benéfica para o moral. É melhor realizá-la após um rollout bem-sucedido em 100%, não no momento do upload do build. Release celebration pode ser combinada com uma retrospectiva do lançamento para discutir o que correu bem e o que pode ser melhorado.
Quem é responsável pela decisão “lançar ou adiar”?
A responsabilidade é do release manager (geralmente um engenheiro sênior ou tech lead). A decisão é baseada nos dados do dashboard de lançamento, não no prazo final. Release manager tem autoridade para atrasar o lançamento se as métricas não passarem pelo go/no-go gate.
Resumo
- Dia de lançamento — processo coordenado do code freeze ao monitoramento pós-rollout
- Preparação — release candidate, execução de QA, verificação de metadados, plano de rollback
- Staged rollout — 1% → 10% → 25% → 50% → 100% com go/no-go gate em cada etapa
- Monitoramento — crash-free rate, ANR, taxa de erro 5xx, avaliações nas primeiras 4 horas
- Rollback — procedimento padrão quando a taxa de crashes cai abaixo de 99%
- Comunicação — notificar equipe e stakeholders antes e depois do lançamento
- Retrospectiva do lançamento — revisão do processo após a conclusão do rollout em 100%
Vamos desenvolver um aplicativo móvel chave na mão
A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.
Leia também