Convenções Git

Usamos conventional commits (feat:, fix:, chore:) que geram changelogs automaticamente. As branches são nomeadas após os tickets: feat/ZENO-123-add-heatmaps.

As mensagens de commit devem ser no imperativo ("Adicionar heatmaps" não "Adicionado heatmaps") e explicar o porquê, não apenas o quê. O diff mostra o que mudou — sua mensagem deve explicar o raciocínio.

Pull Requests

Cada mudança passa por revisão de código. Os PRs devem ser pequenos, focados e incluir contexto para os revisores. Visamos revisões em 4 horas durante o horário de trabalho.

Requisitos do PR:

Todos os testes passam
A verificação de tipos tem sucesso
Pelo menos uma aprovação
Nenhum comentário não resolvido

Boas descrições de PR incluem: o que mudou, por que mudou, como testá-lo e quaisquer riscos ou trabalhos de acompanhamento necessários.

Pipeline de CI/CD

Cada push aciona nosso pipeline de CI: lint, verificação de tipos, teste, build. Merges para main fazem deploy para staging automaticamente. Os deploys de produção requerem aprovação explícita.

O pipeline roda em menos de 5 minutos. Se demorar mais, tratamos isso como um bug a corrigir. Ciclos de feedback rápidos mantêm os desenvolvedores produtivos.

Gerenciamento de Ambientes

Mantemos três ambientes:

Desenvolvimento: Máquinas locais com Wrangler para Workers e Supabase local.
Staging: Ambiente semelhante à produção em subdomínios de staging. Usado para QA final e demo.
Produção: O ambiente real. Implantado após verificação do staging e aprovação explícita.

Migrações de Banco de Dados

As mudanças de esquema passam por migrações do Supabase. Cada migração deve ser reversível com uma migração down correspondente. Testamos migrações no staging com dados semelhantes aos de produção antes de aplicar à produção.

Processo de Lançamento

Lançamos continuamente. As funcionalidades entram em produção assim que estão prontas, protegidas por feature flags. Mudanças importantes são anunciadas em nosso changelog com guias de migração claros.

Os feature flags nos permitem implantar código sem ativá-lo para os usuários. Isso significa lançamentos mais seguros, rollouts graduais e reversões fáceis se algo der errado.