Processo do Time – WimBelemDon+

Este documento descreve como o time organiza o trabalho, desde a definição de tarefas até a entrega em produção, garantindo consistência, colaboração e qualidade.

Sumário

• Planejamento
• Branches e Commits
• Pull Requests
• Code Review
• Integração Contínua
• Entrega
• Reuniões e Comunicação
• Boas Práticas

Planejamento

• As tarefas são priorizadas no board (Scrum/Sprint) pela equipe.
• Cada tarefa deve estar claramente descrita, com critérios de aceite e linkada a uma issue.
• O time planeja entregas por sprints quinzenais, com daily check-ins curtos para acompanhamento.

Branches e Commits

• Usar branch naming conventions e conventional commits descritos abaixo.
• Cada issue/task deve ter sua branch dedicada.
• Branches são criadas a partir de develop.
• Commits devem ser pequenos, claros e relacionados a uma única mudança.

Diretrizes para Mensagens de Commit

Seguimos o padrão Conventional Commits:

<tipo>(<escopo>): <assunto> (#<id-da-tarefa>)

• tipo: feat, fix, chore, test, docs, ci, perf, refactor, build
• escopo: opcional, ex.: módulo ou funcionalidade
• assunto: descrição curta, em minúsculas, sem ponto final

Exemplos:

• feat(auth): adicionar login via Google OAuth
• fix(ui): corrigir alinhamento do botão na página inicial
• chore(deps): atualizar react para 19.0.1
• test(auth): adicionar testes unitários para login
• docs(readme): atualizar instruções de configuração
• ci(pipeline): adicionar etapa de linting
• perf(api): cachear respostas para reduzir tempo de carregamento
• refactor(ui): simplificar renderização condicional
• build(webpack): atualizar configuração para produção

Use sempre o imperativo em vez do passado.

Se houver, adicione o id da tarefa ao final do título do commit. Exemplo:

feat(auth): adicionar login via Google OAuth (#123)

Convenções de Nomenclatura de Branches

Usamos kebab-case para os nomes das branches. Prefixe as branches de acordo com o tipo de trabalho:

Não use espaços ou caracteres especiais nos nomes das branches.

Pull Requests

• Todo desenvolvimento deve passar por PR.

• PRs devem ser abertos contra develop.

• O autor deve:

  • Descrever claramente as alterações.
  • Atribuir-se como responsável.
  • Solicitar revisão de ao menos 1 integrante do time.

• PR só pode ser mergeado após aprovação e pipeline passando.

Code Review

• O objetivo é garantir qualidade e aprendizado coletivo, não apenas apontar erros.

• Revisores devem checar:

  • Clareza e legibilidade do código.
  • Padrões de arquitetura e estilo.
  • Testes e cobertura mínima.
  • Segurança (nada de segredos hardcoded).

• Feedback deve ser construtivo e registrado nos comentários do PR.

Integração Contínua

• O pipeline de CI roda automaticamente em cada PR.

• Passos básicos:

  • Lint e formatação.
  • Testes unitários.
  • Build.

• Nenhum PR pode ser mergeado com falha no pipeline.

Entrega

• develop é a branch de integração.
• main representa a versão estável em produção.
• Releases seguem versionamento semântico (vX.Y.Z).
• O deploy é feito somente a partir de main, após validação do PO/cliente.

Reuniões e Comunicação

• Dailies: acompanhamento rápido (15 min).
• Planning: início da sprint para priorizar tarefas.
• Review/Demo: apresentação das entregas ao cliente.
• Retrospectiva: ajustes no processo do time.
• Comunicação principal via Slack/Teams/Discord (definir).
• Decisões importantes devem ser documentadas (no Notion/Confluence).

Boas Práticas

• Todo código, documentação e commits devem estar em inglês.
• PR descriptions e comentários podem ser em português.
• Evitar big PRs → dividir em entregas menores.
• Tratar warnings e falhas de lint antes do merge.
• Se encontrar um problema, abrir uma issue mesmo que não vá resolver no momento.