9 min leitura • Guide 799 of 877
Estratégias de Gestão de Releases
Releases consistentes constroem confiança. GitScrum ajuda a coordenar planejamento de release e rastrear o que é entregue em cada versão.
Planejamento de Release
Cadências de Release
OPÇÕES DE CADÊNCIA DE RELEASE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONTINUOUS DEPLOYMENT: │
│ ────────────────────── │
│ Todo commit na main → produção │
│ Múltiplas releases por dia │
│ Menor risco por release │
│ Requer: Automação forte, feature flags, testes rápidos │
│ │
│ RELEASES DIÁRIAS: │
│ ───────────────── │
│ Horário fixo cada dia │
│ Mudanças agrupadas juntas │
│ Baixo risco, previsível │
│ Requer: Bom CI/CD, testes rápidos │
│ │
│ RELEASES SEMANAIS: │
│ ────────────────── │
│ Toda terça-feira (ou similar) │
│ Semana para testes e preparação │
│ Comum para aplicações web │
│ Requer: Feature freeze antes do release │
│ │
│ BASEADO EM SPRINT: │
│ ───────────────── │
│ Final de cada sprint │
│ Ciclos de 1-2 semanas │
│ Alinha com cerimônias ágeis │
│ Requer: Disciplina de sprint │
│ │
│ MODELO DE TREM: │
│ ──────────────── │
│ Agenda fixa: "Trem parte na terça" │
│ Features prontas → embarcam. Não prontas → próximo trem │
│ Previsível para stakeholders │
│ Requer: Features desacopladas │
│ │
│ TRIMESTRAL / ANUAL: │
│ ─────────────────── │
│ Versões maiores com ciclos longos │
│ Alto risco por release │
│ Comum para: Software desktop, apps mobile, hardware │
│ Requer: Testes extensivos, planejamento de rollback │
└─────────────────────────────────────────────────────────────┘
Planejando um Release
PLANEJANDO UM RELEASE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PLANO DE RELEASE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RELEASE: v2.4.0 ││
│ │ DATA ALVO: 30 de Janeiro de 2025 ││
│ │ GERENTE DE RELEASE: @jordan ││
│ │ ││
│ │ TEMA: Melhorias de pagamento + Performance ││
│ │ ││
│ │ FEATURES INCLUÍDAS: ││
│ │ ☑ EPIC-015: Integração PayPal ││
│ │ ☑ EPIC-018: Performance do dashboard ││
│ │ ☑ STORY-890: Atualizações de template de email ││
│ │ ☑ BUG-123: Corrigir exibição de timezone ││
│ │ ☐ STORY-891: Relatórios customizados (em risco) ││
│ │ ││
│ │ CRONOGRAMA: ││
│ │ 20 Jan: Feature freeze ││
│ │ 21-24 Jan: Testes e correções de bugs ││
│ │ 27 Jan: Release candidate pronto ││
│ │ 28 Jan: Deploy em staging ││
│ │ 29 Jan: Verificação final ││
│ │ 30 Jan: Release em produção ││
│ │ ││
│ │ DEPENDÊNCIAS: ││
│ │ • Migração Stripe API v3 completa ││
│ │ • Marketing pronto com anúncio ││
│ │ ││
│ │ PLANO DE ROLLBACK: ││
│ │ Manter v2.3.0 pronta para rollback rápido ││
│ │ Migrações de banco são backward compatible ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FEATURE FREEZE: │
│ ─────────────── │
│ Após freeze: Apenas correções de bugs permitidas │
│ Novas features → esperar próximo release │
│ Foco muda para estabilidade │
└─────────────────────────────────────────────────────────────┘
Versionamento
Versionamento Semântico
VERSIONAMENTO SEMÂNTICO (SemVer):
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMATO DA VERSÃO: MAJOR.MINOR.PATCH │
│ ───────────────────────────────── │
│ │
│ v2.4.1 │
│ │ │ │ │
│ │ │ └── PATCH: Apenas correções de bugs (sem features) │
│ │ │ Incremento: 2.4.0 → 2.4.1 │
│ │ │ │
│ │ └─── MINOR: Novas features, backward compatible │
│ │ Incremento: 2.4.1 → 2.5.0 (patch reseta) │
│ │ │
│ └──── MAJOR: Breaking changes │
│ Incremento: 2.5.0 → 3.0.0 (minor/patch resetam) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLOS: │
│ │
│ v1.2.3 → v1.2.4 │
│ Correção de bug: Corrigido crash ao exportar arquivos │
│ grandes │
│ │
│ v1.2.4 → v1.3.0 │
│ Nova feature: Adicionado modo escuro │
│ (Ainda funciona com configs antigas) │
│ │
│ v1.3.0 → v2.0.0 │
│ Breaking: Mudança no método de autenticação da API │
│ (Clientes antigos não funcionarão sem atualizações) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VERSÕES PRÉ-RELEASE: │
│ ───────────────────── │
│ v2.0.0-alpha.1 Testes iniciais │
│ v2.0.0-beta.1 Feature completa, testando │
│ v2.0.0-rc.1 Release candidate │
│ v2.0.0 Release estável │
└─────────────────────────────────────────────────────────────┘
Processo de Release
Workflow de Deployment
WORKFLOW DE RELEASE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PIPELINE DE RELEASE: │
│ │
│ DESENVOLVIMENTO │
│ │ │
│ ▼ │
│ ┌─────────┐ Feature branches, commits diários │
│ │ DEV │ Auto-deploy a cada merge │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ Feature completa, testes de integração │
│ │ STAGING │ Deploy de release candidates │
│ └────┬────┘ Verificação do QA │
│ │ │
│ ▼ │
│ ┌─────────┐ Ambiente similar a produção │
│ │ PROD │ Tráfego real de usuários │
│ └─────────┘ Monitoramento ativo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CHECKLIST DE RELEASE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PRÉ-RELEASE: ││
│ │ ☐ Todas features mergeadas na branch de release ││
│ │ ☐ Todos testes passando ││
│ │ ☐ Release notes preparadas ││
│ │ ☐ Staging deployado e verificado ││
│ │ ☐ Stakeholders notificados ││
│ │ ││
│ │ DIA DO RELEASE: ││
│ │ ☐ Equipe disponível para issues ││
│ │ ☐ Plano de rollback pronto ││
│ │ ☐ Dashboards de monitoramento abertos ││
│ │ ☐ Deploy para produção ││
│ │ ☐ Smoke test nos caminhos críticos ││
│ │ ││
│ │ PÓS-RELEASE: ││
│ │ ☐ Monitorar por 1 hora ││
│ │ ☐ Anunciar para stakeholders ││
│ │ ☐ Atualizar documentação ││
│ │ ☐ Tag do release no Git ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Documentação de Release
Release Notes
TEMPLATE DE RELEASE NOTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RELEASE NOTES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ VERSÃO 2.4.0 - 30 de Janeiro de 2025 ││
│ │ ││
│ │ ✨ NOVAS FUNCIONALIDADES ││
│ │ ───────────────────────── ││
│ │ • Pagamentos PayPal agora disponíveis no checkout ││
│ │ • Suporte a modo escuro (Configurações → Aparência) ││
│ │ • Exportar dashboards para PDF ││
│ │ ││
│ │ 🐛 CORREÇÕES DE BUGS ││
│ │ ─────────────────────── ││
│ │ • Corrigida exibição de timezone em relatórios ││
│ │ • Resolvido crash ao fazer upload de arquivos grandes ││
│ │ • Notificações por email agora enviam corretamente ││
│ │ ││
│ │ ⚡ MELHORIAS ││
│ │ ─────────── ││
│ │ • Dashboard carrega 40% mais rápido ││
│ │ • Responsividade mobile melhorada ││
│ │ • Melhores mensagens de erro para pagamentos falhos ││
│ │ ││
│ │ ⚠️ BREAKING CHANGES ││
│ │ ────────────────── ││
│ │ • Endpoints da API v1 deprecados (remover até Abr 25) ││
│ │ • Browser mínimo: Chrome 90+, Firefox 88+ ││
│ │ ││
│ │ 📝 NOTAS ││
│ │ ───────── ││
│ │ • Usuários serão deslogados após atualização ││
│ │ • Limpe cache do browser se problemas persistirem ││
│ │ ││
│ │ Changelog completo: github.com/company/app/releases ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AUDIÊNCIA: │
│ ───────── │
│ • Interna: Inclua detalhes técnicos │
│ • Cliente: Foque em mudanças visíveis ao usuário │
│ • Consumidores de API: Enfatize breaking changes │
└─────────────────────────────────────────────────────────────┘
Estratégia de Rollback
Lidando com Releases Falhos
PLANEJAMENTO DE ROLLBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DO RELEASE: │
│ ─────────────── │
│ • Saiba como fazer rollback │
│ • Teste procedimento de rollback │
│ • Migrações de banco reversíveis? │
│ • Mantenha versão anterior pronta │
│ │
│ QUANDO FAZER ROLLBACK: │
│ ───────────────────── │
│ • Taxa de erro > 5% (subiu do baseline 0.1%) │
│ • Latência > 3x baseline │
│ • Health checks falhando │
│ • Métrica de negócio crítica caiu > 10% │
│ │
│ PASSOS DE ROLLBACK: │
│ ───────────────────── │
│ 1. Confirme decisão de rollback │
│ 2. Comunique início do rollback │
│ 3. Execute rollback (deploy versão anterior) │
│ 4. Verifique sucesso do rollback │
│ 5. Comunique conclusão do rollback │
│ 6. Conduza post-mortem │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Gestão de Releases
- Releases pequenos e frequentes — Menor risco
- Automatize tudo — Pipeline de CI/CD
- Feature flags — Rollout controlado
- Monitore ativamente — Detecte issues cedo
- Documente tudo — Release notes, runbooks
Anti-Padrões
ERROS DE GESTÃO DE RELEASES:
✗ Big bang releases (muito grande para falhar)
✗ Deploys manuais propensos a erro
✗ Sem plano de rollback
✗ Feature freeze muito longo
✗ Pular staging
✗ Sem monitoramento pós-release
✗ Release notes vagas ou ausentes
✗ Sem ownership claro de release