| name | release-manager |
| description | Use quando o usuário pede para planejar releases, gerenciar changelogs, coordenar implantações, criar branches de release ou automatizar versionamento. |
| agents | ["claude-code"] |
Release Manager
Nível: PODEROSO
Categoria: Engenharia
Domínio: Gerenciamento de Release de Software e DevOps
Visão Geral
A skill Release Manager fornece ferramentas e conhecimento abrangentes para gerenciar releases de software de ponta a ponta. Desde a análise de commits convencionais até a geração de changelogs, determinação de versões e orquestração de processos de release, esta skill garante releases de software confiáveis, previsíveis e bem documentados.
Capacidades Principais
- Geração Automatizada de Changelog a partir do histórico git usando commits convencionais
- Bump de Versão Semântica com base na análise de commits e mudanças disruptivas
- Avaliação de Prontidão de Release com listas de verificação e validação abrangentes
- Planejamento e Coordenação de Release com templates de comunicação com stakeholders
- Planejamento de Rollback com procedimentos de recuperação automatizados
- Gerenciamento de Hotfix para releases de emergência
- Integração com Feature Flags para rollouts progressivos
Componentes Principais
Scripts
- changelog_generator.py - Analisa logs git e gera changelogs estruturados
- version_bumper.py - Determina bumps de versão corretos a partir de commits convencionais
- release_planner.py - Avalia a prontidão do release e gera planos de coordenação
Documentação
- Metodologia abrangente de gerenciamento de release
- Especificação e exemplos de commits convencionais
- Comparações de fluxo de trabalho de release (Git Flow, Trunk-based, GitHub Flow)
- Procedimentos de hotfix e protocolos de resposta de emergência
Metodologia de Gerenciamento de Release
Versionamento Semântico (SemVer)
O Versionamento Semântico segue o formato MAJOR.MINOR.PATCH onde:
- MAJOR versão quando você faz mudanças incompatíveis de API
- MINOR versão quando você adiciona funcionalidade de forma compatível retroativamente
- PATCH versão quando você faz correções de bugs compatíveis retroativamente
Versões de Pré-release
Versões de pré-release são denotadas anexando um hífen e identificadores:
1.0.0-alpha.1 - Releases alpha para testes iniciais1.0.0-beta.2 - Releases beta para testes mais amplos1.0.0-rc.1 - Release candidates para validação final
Precedência de Versão
A precedência de versão é determinada comparando cada identificador:
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.11.0.0-rc.1 < 1.0.0
Commits Convencionais
Os Commits Convencionais fornecem um formato estruturado para mensagens de commit que habilita ferramentas automatizadas:
Formato
<tipo>[escopo opcional]: <descrição>
[corpo opcional]
[rodapé(s) opcional(ais)]
Tipos
- feat: Uma nova funcionalidade (correlaciona com bump de versão MINOR)
- fix: Uma correção de bug (correlaciona com bump de versão PATCH)
- docs: Mudanças apenas na documentação
- style: Mudanças que não afetam o significado do código
- refactor: Uma mudança de código que nem corrige um bug nem adiciona uma funcionalidade
- perf: Uma mudança de código que melhora o desempenho
- test: Adicionando testes ausentes ou corrigindo testes existentes
- chore: Mudanças no processo de build ou ferramentas auxiliares
- ci: Mudanças em configurações e scripts de CI
- build: Mudanças que afetam o sistema de build ou dependências externas
- breaking: Introduz uma mudança disruptiva (correlaciona com bump de versão MAJOR)
Exemplos
feat(user-auth): adicionar integração OAuth2
fix(api): resolver race condition na criação de usuário
docs(readme): atualizar instruções de instalação
feat!: remover API de pagamento descontinuada
BREAKING CHANGE: A API de pagamento legada foi removida
Geração Automatizada de Changelog
Os changelogs são gerados automaticamente a partir de commits convencionais, organizados por:
Estrutura
# Changelog
## [Não Lançado]
### Adicionado
### Modificado
### Descontinuado
### Removido
### Corrigido
### Segurança
## [1.2.0] - 2024-01-15
### Adicionado
- Suporte a autenticação OAuth2 (#123)
- Painel de preferências do usuário (#145)
### Corrigido
- Race condition na criação de usuário (#134)
- Vazamento de memória no processamento de imagem (#156)
### Mudanças Disruptivas
- Removida API de pagamento legada
Regras de Agrupamento
- Adicionado para novas funcionalidades (feat)
- Corrigido para correções de bugs (fix)
- Modificado para mudanças em funcionalidades existentes
- Descontinuado para funcionalidades prestes a serem removidas
- Removido para funcionalidades já removidas
- Segurança para correções de vulnerabilidades
Extração de Metadados
- Link para pull requests e issues:
(#123)
- Mudanças disruptivas destacadas com proeminência
- Agrupamento por escopo:
auth:, api:, ui:
- Co-authored-by para reconhecimento de colaboradores
Estratégias de Bump de Versão
Os bumps de versão são determinados pela análise dos commits desde o último release:
Regras de Detecção Automática
- MAJOR: Qualquer commit com
BREAKING CHANGE ou ! após o tipo
- MINOR: Qualquer commit do tipo
feat sem mudanças disruptivas
- PATCH: Commits dos tipos
fix, perf, security
- SEM BUMP: Apenas
docs, style, test, chore, ci, build
Tratamento de Pré-release
Considerações para Monorepos
Para monorepos com múltiplos pacotes:
- Analise commits que afetam cada pacote independentemente
- Suporte a bumps de versão com escopo:
@scope/package@1.2.3
- Gere planos de release coordenados entre pacotes
Fluxos de Trabalho de Branch de Release
Git Flow
main (produção) ← release/1.2.0 ← develop ← feature/login
← hotfix/critical-fix
Vantagens:
- Clara separação de preocupações
- Branch main estável
- Desenvolvimento paralelo de funcionalidades
- Processo de release estruturado
Processo:
- Crie branch de release a partir de develop:
git checkout -b release/1.2.0 develop
- Finalize o release (bump de versão, changelog)
- Mescle para main e develop
- Crie tag do release:
git tag v1.2.0
- Implante a partir de main
Desenvolvimento Trunk-based
main ← feature/login (curta duração)
← feature/payment (curta duração)
← hotfix/critical-fix
Vantagens:
- Fluxo de trabalho simplificado
- Integração mais rápida
- Conflitos de merge reduzidos
- Amigável para integração contínua
Processo:
- Branches de funcionalidade de curta duração (1-3 dias)
- Commits frequentes para main
- Feature flags para funcionalidades incompletas
- Portões de testes automatizados
- Implantação a partir de main com feature toggles
GitHub Flow
main ← feature/login
← hotfix/critical-fix
Vantagens:
- Simples e leve
- Ciclo de implantação rápido
- Bom para aplicações web
- Overhead mínimo
Processo:
- Crie branch de funcionalidade a partir de main
- Commits e pushes regulares
- Abra pull request quando estiver pronto
- Implante a partir do branch de funcionalidade para testes
- Mescle para main e implante
Integração com Feature Flags
As feature flags habilitam rollouts seguros e progressivos:
Tipos de Feature Flags
- Flags de release: Controle a visibilidade da funcionalidade em produção
- Flags de experimento: Testes A/B e rollouts graduais
- Flags operacionais: Circuit breakers e toggles de desempenho
- Flags de permissão: Acesso a funcionalidades baseado em papel
Estratégia de Implementação
if feature_flag("new_payment_flow", user_id):
return new_payment_processor.process(payment)
else:
return legacy_payment_processor.process(payment)
Coordenação de Release
- Implante código com funcionalidade atrás de flag (desabilitada)
- Habilite gradualmente para porcentagem de usuários
- Monitore métricas e taxas de erro
- Rollout completo ou rollback rápido com base nos dados
- Remova a flag no release subsequente
Listas de Verificação de Prontidão de Release
Validação Pré-Release
Portões de Qualidade
Requisitos de Documentação
Aprovações de Stakeholders
Coordenação de Implantação
Plano de Comunicação
Stakeholders Internos:
- Equipe de engenharia: Mudanças técnicas e procedimentos de rollback
- Equipe de produto: Descrições de funcionalidades e impacto no usuário
- Equipe de suporte: Problemas conhecidos e guias de troubleshooting
- Equipe de vendas: Mudanças voltadas ao cliente e pontos de discussão
Comunicação Externa:
- Notas de release para usuários
- Changelog de API para desenvolvedores
- Guia de migração para mudanças disruptivas
- Notificações de downtime se aplicável
Sequência de Implantação
- Pré-implantação (T-24h): Validação final, congele o código
- Migrações de banco de dados (T-2h): Execute e valide mudanças de esquema
- Implantação blue-green (T-0): Mude o tráfego gradualmente
- Pós-implantação (T+1h): Monitore métricas e logs
- Janela de rollback (T+4h): Ponto de decisão para rollback
Monitoramento e Validação
- Verificações de saúde da aplicação
- Monitoramento de taxa de erro
- Rastreamento de métricas de desempenho
- Monitoramento de experiência do usuário
- Validação de métricas de negócio
- Saúde de integrações de terceiros
Procedimentos de Hotfix
Os hotfixes abordam problemas críticos de produção que requerem implantação imediata:
Classificação de Severidade
P0 - Crítico: Interrupção completa do sistema, perda de dados, violação de segurança
- SLA: Corrija em 2 horas
- Processo: Implantação de emergência, todos as mãos no deck
- Aprovação: Tech Lead de Engenharia + Gerente de Plantão
P1 - Alto: Funcionalidade principal quebrada, impacto significativo no usuário
- SLA: Corrija em 24 horas
- Processo: Revisão e implantação aceleradas
- Aprovação: Tech Lead de Engenharia + Product Manager
P2 - Médio: Problemas menores de funcionalidade, impacto limitado no usuário
- SLA: Corrija no próximo ciclo de release
- Processo: Processo normal de revisão
- Aprovação: Revisão padrão de PR
Processo de Resposta de Emergência
- Declaração de incidente: Acione a equipe de plantão
- Avaliação: Determine severidade e impacto
- Branch de hotfix: Crie a partir do último release estável
- Correção mínima: Aborde apenas a causa raiz
- Testes acelerados: Testes automatizados + validação manual
- Implantação de emergência: Implante em produção
- Pós-incidente: Análise de causa raiz e prevenção
Planejamento de Rollback
Todo release deve ter um plano de rollback testado:
Gatilhos de Rollback
- Pico na taxa de erro: Mais de 2x a linha de base em 30 minutos
- Degradação de desempenho: Aumento de latência >50%
- Falhas de funcionalidade: Funcionalidade principal quebrada
- Incidente de segurança: Vulnerabilidade explorada
- Corrupção de dados: Integridade do banco de dados comprometida
Tipos de Rollback
Rollback de Código:
- Reverta para a imagem Docker anterior
- Apenas mudanças de código compatíveis com banco de dados
- Desabilitação de feature flag preferível ao rollback de código
Rollback de Banco de Dados:
- Apenas para migrações não destrutivas
- Backup de dados obrigatório antes da migração
- Migrações somente para frente preferidas (adicione colunas, não remova)
Rollback de Infraestrutura:
- Troca de implantação blue-green
- Reversão de configuração de balanceador de carga
- Mudanças de DNS (tempo de propagação maior)
Rollback Automatizado
def monitor_deployment():
if error_rate() > THRESHOLD:
alert_oncall("Pico na taxa de erro detectado")
if auto_rollback_enabled():
execute_rollback()
Métricas e Analytics de Release
Indicadores-Chave de Desempenho
- Lead Time: Do commit à produção
- Frequência de Implantação: Releases por semana/mês
- Tempo Médio de Recuperação: Do incidente à resolução
- Taxa de Falha de Mudança: Porcentagem de releases causando incidentes
Métricas de Qualidade
- Taxa de Rollback: Porcentagem de releases revertidos
- Taxa de Hotfix: Hotfixes por release regular
- Taxa de Escape de Bugs: Bugs de produção por release
- Tempo para Detecção: Quão rapidamente os problemas são identificados
Métricas de Processo
- Tempo de Revisão: Tempo gasto em revisão de código
- Tempo de Testes: Duração de testes automatizados + manuais
- Ciclo de Aprovação: Tempo do PR à mesclagem
- Preparação de Release: Tempo gasto em atividades de release
Integração de Ferramentas
Sistemas de Controle de Versão
- Git: VCS primário com análise de commits convencionais
- GitHub/GitLab: Automação de pull request e CI/CD
- Bitbucket: Integração de pipeline e portões de implantação
Plataformas CI/CD
- Jenkins: Orquestração de pipeline e automação de implantação
- GitHub Actions: Automação de workflow e publicação de release
- GitLab CI: Pipelines integrados com gerenciamento de ambiente
- CircleCI: Builds baseados em container e implantações
Monitoramento e Alertas
- DataDog: Monitoramento de desempenho da aplicação
- New Relic: Rastreamento de erros e insights de desempenho
- Sentry: Agregação de erros e rastreamento de releases
- PagerDuty: Resposta a incidentes e escalonamento
Plataformas de Comunicação
- Slack: Notificações de release e coordenação
- Microsoft Teams: Comunicação com stakeholders
- Email: Notificações externas para clientes
- Páginas de Status: Comunicação pública de incidentes
Melhores Práticas
Planejamento de Release
- Cadência regular: Estabeleça um calendário de release previsível
- Congelamento de funcionalidades: Bloqueie mudanças 48h antes do release
- Avaliação de riscos: Avalie mudanças para potencial impacto
- Alinhamento de stakeholders: Garanta que todas as equipes estejam preparadas
Garantia de Qualidade
- Testes automatizados: Cobertura abrangente de testes
- Ambiente de staging: Ambiente de testes semelhante ao de produção
- Releases canário: Rollout gradual para um subconjunto de usuários
- Monitoramento: Detecção proativa de problemas
Comunicação
- Cronogramas claros: Comunique os agendamentos com antecedência
- Atualizações regulares: Relatórios de status durante o processo de release
- Transparência de problemas: Comunicação honesta sobre problemas
- Post-mortems: Aprenda com incidentes e melhore
Automação
- Reduza etapas manuais: Automatize tarefas repetitivas
- Processo consistente: Os mesmos passos toda vez
- Trilhas de auditoria: Registre todas as atividades de release
- Autoatendimento: Habilite equipes a implantar com segurança
Anti-Padrões Comuns
Anti-Padrões de Processo
- Implantações manuais: Sujeitas a erros e inconsistentes
- Mudanças de última hora: Introdução de risco sem testes adequados
- Pular testes: Implantar sem validação
- Comunicação ruim: Stakeholders alheios às mudanças
Anti-Padrões Técnicos
- Releases monolíticos: Releases grandes e infrequentes com alto risco
- Implantações acopladas: Serviços que devem ser implantados juntos
- Sem plano de rollback: Incapaz de se recuperar rapidamente de problemas
- Deriva de ambiente: Produção difere do staging
Anti-Padrões Culturais
- Cultura de culpa: Medo de fazer mudanças ou relatar problemas
- Cultura de herói: Depender de indivíduos em vez de processo
- Perfeccionismo: Atrasar releases por melhorias menores
- Aversão ao risco: Evitar mudanças necessárias por medo
Primeiros Passos
- Avaliação: Avalie o processo de release atual e pontos de dor
- Configuração de ferramentas: Configure scripts para o seu repositório
- Definição de processo: Escolha o fluxo de trabalho adequado para a sua equipe
- Automação: Implemente pipelines CI/CD e portões de qualidade
- Treinamento: Eduque a equipe sobre novos processos e ferramentas
- Monitoramento: Configure métricas e alertas para releases
- Iteração: Melhore continuamente com base em feedback e métricas
A skill Release Manager transforma implantações caóticas em releases previsíveis e confiáveis que constroem confiança em toda a organização.
