Skip to content

📌 Fluxo de Versionamento e Branches (Plano Condicional)

Este documento descreve o fluxo de versionamento adotado pelo time de desenvolvimento, baseado em branches organizadas e integradas com Semantic Release para automação de versões, changelogs e publicações.

🔹 Estrutura de Branches

  • main
  • Contém a versão estável em produção.
  • Exemplo de versão: v2.3.0.
  • Hotfixes devem ser aplicados diretamente aqui.
  • Responsável por gerar rollback e rollout quando necessário.

  • Sempre que houver promoção para a main (via Pull Request), o Semantic Release dispara um novo workflow, responsável pela publicação oficial.

    • Isso permite um rollout e rollback de forma facilitada.

  • release-candidate

  • Representa a branch de preparação para liberar uma nova versão estável.
  • Criada a partir da next.
  • Exemplo de versão: v2.3.0-rc.2.

  • Recebe apenas bugfixes até ser promovida para main.

  • next

  • Branch de integração das funcionalidades em desenvolvimento.
  • Cada merge de feature gera automaticamente uma versão beta.

  • Exemplo de versão: v2.3.0-beta.1.

  • feature/*

  • Utilizada pelos desenvolvedores para implementar novas funcionalidades.
  • Após o merge em next, gera uma versão beta.

🔹 Ciclo de Versionamento

  1. Desenvolvimento de Feature
  2. O desenvolvedor cria uma branch feature/nome-da-feature.

  3. Ao concluir e realizar merge na next, o Semantic Release gera uma versão beta (X.Y.Z-beta.N).

  4. Versões Beta

  5. Usadas para validar novas funcionalidades.
  6. Não elegíveis para serem promovidas diretamente à produção.

  7. Caso necessário, devem passar novamente por Pull Requests com adequações.

  8. Release Candidate (RC)

  9. Criada a partir da next quando as features já foram estabilizadas.
  10. Gera versões rc (X.Y.Z-rc.N).

  11. Apenas bugfixes entram nesta branch.

  12. Promoção para Main

  13. Quando estável, a release-candidate é promovida para main.
  14. Isso gera uma nova versão estável (X.Y.Z).
  15. Importante: neste ponto, o Semantic Release dispara um workflow de publicação, permitindo rollout e rollback.

🔹 Hotfixes

  • Devem ser aplicados diretamente na branch main.
  • O fluxo para hotfix é:
  • Criar a correção na main.
  • Gerar uma nova versão estável (X.Y.Z+1).
  • Propagar a correção para next e release-candidate se necessário.
  • Dependendo do contexto:
  • Se estava em RC, descer para a última versão de RC.
  • Se estava em Beta, descer para a última versão de Beta.

🔹 Semantic Release

  • Automatiza:
  • Geração de versões (beta, rc, stable).
  • Criação de changelog.

  • Disparo de workflows de publicação (rollout e rollback).

  • Tipos de versão:

  • Beta: gerada em merges na branch next.
  • RC: gerada ao criar uma branch release-candidate.
  • Stable: promovida da release-candidate para a main.

🔹 Resumo Visual do Fluxo

Fluxo de Branches (Avançado)

🔹 Boas Práticas

  • Sempre iniciar novas features a partir da branch next.
  • Evitar promover versões beta diretamente para produção.
  • Em caso de hotfix, priorizar correção rápida na main e sincronizar depois nas demais branches.
  • Acompanhar changelogs gerados automaticamente para garantir transparência das alterações.
  • Antes de promover para main, validar se todos os testes, validações e QA foram concluídos.
  • Lembrar que a promoção para main gera workflow de publicação, permitindo rollout/rollback fácil.

✅ Checklist Rápida para o Time

  • [ ] Criar branch feature/nome-da-feature a partir de next.
  • [ ] Merge na next → verificar geração automática de versão beta.
  • [ ] Validar se a versão beta estável pode seguir para RC.
  • [ ] Criar branch release-candidate a partir de next.
  • [ ] Validar apenas bugfixes dentro de release-candidate.
  • [ ] Promover release-candidate para main → gera versão estável e dispara workflow de publicação.
  • [ ] Confirmar changelog gerado pelo Semantic Release.
  • [ ] Em caso de hotfix, aplicar diretamente na main, gerar versão e sincronizar com next/RC.