10 min leitura • Guide 726 of 877
Checklist de Lançamento de Produto com GitScrum
Um lançamento bem-sucedido requer preparação cuidadosa entre múltiplos times. O GitScrum ajuda coordenar atividades de lançamento com checklists, rastreamento de tarefas e recursos de coordenação de time que garantem releases de produto suaves.
Preparação de Lançamento
Timeline de Lançamento
TIMELINE DE LANÇAMENTO DE PRODUTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ T-4 SEMANAS: FASE DE PREPARAÇÃO │
│ ☐ Feature freeze │
│ ☐ Criar checklist de lançamento │
│ ☐ Identificar todos times envolvidos │
│ ☐ Definir critérios de lançamento │
│ ☐ Começar documentação │
│ │
│ T-2 SEMANAS: FASE DE PRONTIDÃO │
│ ☐ Feature completa │
│ ☐ Testes completos │
│ ☐ Documentação completa │
│ ☐ Materiais de marketing prontos │
│ ☐ Time de suporte treinado │
│ │
│ T-1 SEMANA: PREP FINAL │
│ ☐ Ambiente staging verificado │
│ ☐ Reunião go/no-go agendada │
│ ☐ Plano de rollback testado │
│ ☐ Alertas de monitoramento configurados │
│ ☐ War room agendada │
│ │
│ T-1 DIA: PRÉ-LANÇAMENTO │
│ ☐ Decisão final go/no-go │
│ ☐ Todos sistemas prontos │
│ ☐ Disponibilidade do time confirmada │
│ ☐ Canais de comunicação configurados │
│ │
│ DIA DO LANÇAMENTO: EXECUÇÃO │
│ ☐ Executar deployment │
│ ☐ Verificar funcionalidade │
│ ☐ Monitorar métricas │
│ ☐ Habilitar para usuários │
│ ☐ Anunciar lançamento │
│ │
│ T+1 SEMANA: PÓS-LANÇAMENTO │
│ ☐ Monitorar feedback │
│ ☐ Endereçar issues críticos │
│ ☐ Retrospectiva do lançamento │
│ ☐ Celebrar! 🎉 │
└─────────────────────────────────────────────────────────────┘
Responsabilidades dos Times
PAPÉIS DO TIME DE LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ENGINEERING: │
│ ☐ Desenvolvimento de feature completo │
│ ☐ Todos testes passando │
│ ☐ Performance validada │
│ ☐ Revisão de segurança completa │
│ ☐ Scripts de deployment prontos │
│ ☐ Procedimento de rollback documentado │
│ ☐ Escala de on-call definida │
│ │
│ QA: │
│ ☐ Plano de teste executado │
│ ☐ Testes de regressão completos │
│ ☐ Edge cases verificados │
│ ☐ Testes cross-browser/device │
│ ☐ Acessibilidade verificada │
│ ☐ Sign-off dado │
│ │
│ PRODUTO: │
│ ☐ Feature atende requisitos │
│ ☐ Fluxos de usuário verificados │
│ ☐ Release notes escritas │
│ ☐ Stakeholders informados │
│ ☐ Métricas de sucesso definidas │
│ │
│ MARKETING: │
│ ☐ Anúncio preparado │
│ ☐ Blog post pronto │
│ ☐ Social media agendada │
│ ☐ Campanha de email pronta │
│ ☐ Website atualizado │
│ │
│ SUPORTE: │
│ ☐ Time treinado na nova feature │
│ ☐ Docs de ajuda publicados │
│ ☐ FAQs preparadas │
│ ☐ Caminho de escalonamento definido │
│ ☐ Capacidade extra se necessário │
└─────────────────────────────────────────────────────────────┘
Prontidão Técnica
Checklist Pré-Lançamento
CHECKLIST TÉCNICO DE LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRONTIDÃO DE CÓDIGO: │
│ ☐ Todos PRs merged na main │
│ ☐ Code freeze em efeito │
│ ☐ Sem bugs críticos/altos abertos │
│ ☐ Dívida técnica aceitável │
│ │
│ TESTES: │
│ ☐ Testes unitários passando (>80% cobertura) │
│ ☐ Testes de integração passando │
│ ☐ Testes E2E passando │
│ ☐ Testes de performance passou │
│ ☐ Scan de segurança limpo │
│ ☐ Auditoria de acessibilidade passou │
│ │
│ INFRAESTRUTURA: │
│ ☐ Staging espelha produção │
│ ☐ Migrações de database testadas │
│ ☐ Feature flags configuradas │
│ ☐ Estratégia de cache CDN definida │
│ ☐ Certificados SSL válidos │
│ │
│ MONITORAMENTO: │
│ ☐ Rastreamento de erros configurado │
│ ☐ Monitoramento de performance ativo │
│ ☐ Thresholds de alerta definidos │
│ ☐ Dashboard criado │
│ ☐ Rotação de on-call definida │
│ │
│ ROLLBACK: │
│ ☐ Procedimento de rollback documentado │
│ ☐ Rollback testado em staging │
│ ☐ Rollback de database possível │
│ ☐ Critérios de decisão definidos │
│ ☐ Pessoa responsável designada │
└─────────────────────────────────────────────────────────────┘
Decisão Go/No-Go
REUNIÃO GO/NO-GO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REUNIÃO: Go/No-Go de Lançamento │
│ HORÁRIO: T-1 dia (ou manhã do lançamento) │
│ PARTICIPANTES: Lead Eng., Produto, QA, Suporte │
│ │
│ AGENDA: │
│ │
│ 1. REVISÃO DO CHECKLIST (15 min) │
│ Cada time confirma seus itens completos │
│ Identificar itens abertos │
│ │
│ 2. RISCOS (10 min) │
│ Riscos conhecidos e mitigações │
│ Preocupações de qualquer time │
│ │
│ 3. DECISÃO (5 min) │
│ GO: Prosseguir com lançamento │
│ NO-GO: Adiar com issues específicos para corrigir │
│ CONDICIONAL: Go com condições específicas │
│ │
│ CRITÉRIOS DE DECISÃO: │
│ │
│ GO se: │
│ ✓ Todos itens críticos do checklist completos │
│ ✓ Sem bugs bloqueantes │
│ ✓ Rollback testado │
│ ✓ Time disponível para janela de lançamento │
│ │
│ NO-GO se: │
│ ✗ Bugs críticos abertos │
│ ✗ Rollback não verificado │
│ ✗ Membros chave do time indisponíveis │
│ ✗ Dependências externas bloqueantes │
│ │
│ DOCUMENTAR DECISÃO E RACIONAL │
└─────────────────────────────────────────────────────────────┘
Execução do Lançamento
Passos do Deployment
EXECUÇÃO DO DIA DO LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRÉ-DEPLOYMENT (30 min antes): │
│ ☐ Canal war room aberto │
│ ☐ Todos participantes online │
│ ☐ Dashboards de monitoramento visíveis │
│ ☐ Procedimento de rollback aberto │
│ │
│ DEPLOYMENT: │
│ ☐ Anunciar início do deployment │
│ ☐ Executar pipeline de deployment │
│ ☐ Monitorar progresso do deployment │
│ ☐ Verificar deployment completo │
│ │
│ VERIFICAÇÃO (Smoke tests): │
│ ☐ Health checks passando │
│ ☐ Fluxos core funcionando │
│ ☐ Sem spike de erro no monitoramento │
│ ☐ Performance dentro do range │
│ │
│ ROLLOUT: │
│ ☐ Habilitar para porcentagem de usuários (se gradual) │
│ ☐ Monitorar métricas em cada estágio │
│ ☐ Aumentar porcentagem gradualmente │
│ ☐ Rollout completo │
│ │
│ ANÚNCIO: │
│ ☐ Anúncio interno enviado │
│ ☐ Anúncio externo disparado │
│ ☐ Documentação tornada live │
│ ☐ Campanha de marketing iniciada │
│ │
│ MONITORAMENTO (Primeiras 2 horas): │
│ ☐ Observar taxas de erro │
│ ☐ Observar métricas de performance │
│ ☐ Observar canais de feedback de usuário │
│ ☐ Pronto para responder a issues │
└─────────────────────────────────────────────────────────────┘
War Room
WAR ROOM DE LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROPÓSITO: Comunicação centralizada durante lançamento │
│ │
│ PARTICIPANTES: │
│ • Lead de engineering (decisor) │
│ • Engineer fazendo deploy │
│ • Representante QA │
│ • Product manager │
│ • Lead de suporte │
│ │
│ COMUNICAÇÃO: │
│ • Canal Slack dedicado: #launch-[feature]-[data] │
│ • Video call para discussão real-time │
│ • Updates de status a cada 15 minutos │
│ │
│ FORMATO UPDATE DE STATUS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🟢 14:30 UPDATE ││
│ │ Deployment: Completo ││
│ │ Smoke tests: Passando ││
│ │ Taxa de erro: Normal (0.1%) ││
│ │ Usuários habilitados: 10% ││
│ │ Issues: Nenhum ││
│ │ Próximo: Aumentar para 25% às 14:45 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESCALONAMENTO: │
│ Issue menor → Continuar com monitoramento │
│ Issue major → Pausar rollout, investigar │
│ Issue crítico → Iniciar rollback │
│ │
│ PÓS-LANÇAMENTO: Fechar war room, suporte normal assume │
└─────────────────────────────────────────────────────────────┘
Pós-Lançamento
Verificação
VERIFICAÇÃO PÓS-LANÇAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRIMEIRAS 24 HORAS: │
│ ☐ Taxas de erro estáveis │
│ ☐ Métricas de performance normais │
│ ☐ Sem reclamações críticas de usuário │
│ ☐ Feature funcionando como esperado │
│ ☐ Sem rollback necessário │
│ │
│ PRIMEIRA SEMANA: │
│ ☐ Rastreamento de adoção de usuário │
│ ☐ Revisão de tickets de suporte │
│ ☐ Bug fixes deployed │
│ ☐ Feedback coletado │
│ ☐ Métricas de sucesso medidas │
│ │
│ CHECK DE MÉTRICAS DE SUCESSO: │
│ │
│ Métrica │ Target │ Atual │ Status │
│─────────────────────┼───────────┼──────────┼───────────── │
│ Adoção de usuário │ 10% │ 12% │ ✅ │
│ Taxa de erro │ <1% │ 0.5% │ ✅ │
│ Tickets suporte │ <20 │ 15 │ ✅ │
│ Conclusão tarefa │ 85% │ 82% │ ⚠️ Perto │
│ │
│ RETROSPECTIVA DO LANÇAMENTO (T+1 semana): │
│ • O que foi bem? │
│ • O que poderia melhorar? │
│ • Action items para próximo lançamento │
│ • Atualizar template do checklist de lançamento │
└─────────────────────────────────────────────────────────────┘
Procedimento de Rollback
PROCEDIMENTO DE ROLLBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUANDO FAZER ROLLBACK: │
│ • Taxa de erro >5% e subindo │
│ • Funcionalidade core quebrada │
│ • Issues de integridade de dados │
│ • Vulnerabilidade de segurança descoberta │
│ • Não consegue fix forward dentro do SLA │
│ │
│ PASSOS DE ROLLBACK: │
│ │
│ 1. DECISÃO │
│ Lead de engineering toma a decisão │
│ Documentar razão │
│ │
│ 2. COMUNICAÇÃO │
│ "Iniciando rollback. Razão: [razão]" │
│ Notificar todos participantes da war room │
│ │
│ 3. EXECUÇÃO │
│ ☐ Desabilitar feature flag (se usado) │
│ ☐ Fazer deploy da versão anterior │
│ ☐ Rollback de database se necessário │
│ ☐ Limpar caches │
│ │
│ 4. VERIFICAÇÃO │
│ ☐ Smoke tests passando │
│ ☐ Taxa de erro normalizada │
│ ☐ Funcionalidade restaurada │
│ │
│ 5. COMUNICAÇÃO │
│ ☐ Update interno │
│ ☐ Update externo se público │
│ ☐ Agendar post-mortem │
│ │
│ 6. ROOT CAUSE │
│ ☐ Investigar o que deu errado │
│ ☐ Corrigir antes de re-lançar │
└─────────────────────────────────────────────────────────────┘