ADR 003 — Estratégia de branches (main + staging)

Status

Aceito

Contexto

SGApi é API .NET 10 para SuperApp + SG Linear, com homologação obrigatória (QA manual, smoke, E2E) antes de produção. O time adota monólito modular, testes de integração com MySQL 8.0 e 5.5, e deploy via Docker.

Alternativas consideradas:

• GitFlow (develop + release/*) — rejeitado: branches longas, merge hell, CI imprevisível
• Trunk-only (main + features direto) — rejeitado: falta ambiente estável de homologação compartilhado
• main + staging — aceito: preview de produção, fluxo simples, CI/CD previsível

Decisão

Adotar duas branches permanentes e branches temporárias por tipo de trabalho:

Permanente	Ambiente
staging	Homologação
main	Produção

Temporária	Uso
feature/*	Nova funcionalidade
fix/*	Bug não crítico
hotfix/*	Bug crítico em produção
refactor/*	Mudança estrutural sem alterar comportamento visível
chore/*	CI, docs, deps, tooling
spike/*	Investigação descartável

Fluxos:

• Desenvolvimento: {feature|fix|refactor|chore}/* → staging → main
• Hotfix: main → hotfix/* → main + staging (sincronizar staging após merge)

Proibido: commit ou push direto em staging e main.

Consequências

• Homologação reflete o que será promovido a produção (mesma imagem Docker, secrets/domínio diferentes)
• PRs pequenos e frequentes; branches temporárias deletadas após merge
• CI diferenciado por etapa (detalhes em workflow futuro; ver guia operacional)
• Integração MySQL 8.0 e 5.5 roda em PRs para staging (paridade com scripts/test.ps1)

Documentação operacional

Guia completo (gestão no time, quando quebrar branches, checklists):

→ docs/process/gestao-branches.md

Referências

• ADR 001 — Monólito modular
• Estratégia de testes
• DOCKER_BUILD_GUIDE.md