ricardonevesbraga/flowgrammers-skills/release-manager

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

1. changelog_generator.py - Analisa logs git e gera changelogs estruturados
2. version_bumper.py - Determina bumps de versão corretos a partir de commits convencionais
3. 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 iniciais
• 1.0.0-beta.2 - Releases beta para testes mais amplos
• 1.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. 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta
2. 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1
3. 1.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

1. MAJOR: Qualquer commit com BREAKING CHANGE ou ! após o tipo
2. MINOR: Qualquer commit do tipo feat sem mudanças disruptivas
3. PATCH: Commits dos tipos fix, perf, security
4. SEM BUMP: Apenas docs, style, test, chore, ci, build

Tratamento de Pré-release

# Alpha: 1.0.0-alpha.1 → 1.0.0-alpha.2
# Beta: 1.0.0-alpha.5 → 1.0.0-beta.1  
# RC: 1.0.0-beta.3 → 1.0.0-rc.1
# Release: 1.0.0-rc.2 → 1.0.0

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:

1. Crie branch de release a partir de develop: git checkout -b release/1.2.0 develop
2. Finalize o release (bump de versão, changelog)
3. Mescle para main e develop
4. Crie tag do release: git tag v1.2.0
5. 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:

1. Branches de funcionalidade de curta duração (1-3 dias)
2. Commits frequentes para main
3. Feature flags para funcionalidades incompletas
4. Portões de testes automatizados
5. 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:

1. Crie branch de funcionalidade a partir de main
2. Commits e pushes regulares
3. Abra pull request quando estiver pronto
4. Implante a partir do branch de funcionalidade para testes
5. 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

# Exemplo de rollout progressivo
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

1. Implante código com funcionalidade atrás de flag (desabilitada)
2. Habilite gradualmente para porcentagem de usuários
3. Monitore métricas e taxas de erro
4. Rollout completo ou rollback rápido com base nos dados
5. Remova a flag no release subsequente

Listas de Verificação de Prontidão de Release

Validação Pré-Release

• [ ] Todas as funcionalidades planejadas implementadas e testadas
• [ ] Mudanças disruptivas documentadas com guia de migração
• [ ] Documentação de API atualizada
• [ ] Migrações de banco de dados testadas
• [ ] Revisão de segurança concluída para mudanças sensíveis
• [ ] Testes de desempenho passaram nos thresholds
• [ ] Strings de internacionalização atualizadas
• [ ] Integrações de terceiros validadas

Portões de Qualidade

• [ ] Cobertura de testes unitários ≥ 85%
• [ ] Testes de integração passando
• [ ] Testes de ponta a ponta passando
• [ ] Análise estática limpa
• [ ] Varredura de segurança aprovada
• [ ] Auditoria de dependências limpa
• [ ] Testes de carga concluídos

Requisitos de Documentação

• [ ] CHANGELOG.md atualizado
• [ ] README.md reflete novas funcionalidades
• [ ] Documentação de API gerada
• [ ] Guia de migração escrito para mudanças disruptivas
• [ ] Notas de implantação preparadas
• [ ] Procedimento de rollback documentado

Aprovações de Stakeholders

• [ ] Aprovação do Product Manager
• [ ] Aprovação do Tech Lead de Engenharia
• [ ] Validação de QA concluída
• [ ] Liberação da equipe de segurança
• [ ] Revisão jurídica (se aplicável)
• [ ] Verificação de conformidade (se regulado)

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

1. Pré-implantação (T-24h): Validação final, congele o código
2. Migrações de banco de dados (T-2h): Execute e valide mudanças de esquema
3. Implantação blue-green (T-0): Mude o tráfego gradualmente
4. Pós-implantação (T+1h): Monitore métricas e logs
5. 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