Padronizar controle de versão e processo de release

[cesarsv]

User Story

Como desenvolvedor da equipe DGB,
Quero um processo padronizado de versionamento e releases,
Para que possamos fazer rollbacks seguros, comunicar mudanças claramente e garantir qualidade nos deploys de produção.

Contexto

Atualmente os repositórios da organização usam estratégias diferentes de versionamento:

• Portal: Preparado para semver (GitHub Releases) mas sem releases criadas
• Data-platform: CD contínuo com hash de commit, sem versionamento semântico
• Scraper: Mesmo padrão de data-platform

Problemas identificados:

1. Rollback complexo em repos sem semver (precisa buscar SHA manualmente)
2. Sem CHANGELOG ou release notes
3. Difícil comunicar o que mudou entre deploys
4. Ambientes staging/production não distinguíveis por tag

Documentação criada: `reference/DEPLOY-VERSIONAMENTO.md` no repo `project`

Critérios de Aceite

• Portal tem primeira release (v1.0.0) criada e deployada
• Portal tem CHANGELOG.md automatizado
• Data-platform migrado para semver com ambiente staging
• Todos os repos têm documentação de processo de release
• Scripts de rollback simplificado disponíveis

Roadmap Proposto

Fase 1: Portal (P1 - Alta)

• Criar primeira release v1.0.0
• Implementar CHANGELOG automatizado (conventional-changelog)
• Documentar processo de release no README

Fase 2: Data-platform (P2 - Média)

• Adicionar versionamento semântico
• Criar ambiente staging (separar de main)
• Implementar semantic-release

Fase 3: Infraestrutura (P3 - Baixa)

• Dashboard de versões em produção
• Automação de rollback
• Política de limpeza de versões antigas

Dependências

• Relacionada: docs#25 (Modernização Técnica)
• Relacionada: docs#29 (Infraestrutura de Produção)

Impacto

Repositórios afetados: portal, data-platform, scraper, infra
Equipe: Todos os desenvolvedores
Prazo: Crítico para MVP do portal (abril-maio 2026)