|
|
|
[](home)
|
|
|
|
|
|
|
|
# Documentação do Negócio
|
|
|
|
[](Sprints)
|
|
|
|
[](Processos)
|
|
|
|
[](Gerência)
|
|
|
|
|
|
|
|
# Documentação Técnica
|
|
|
|
[](Arquitetura)
|
|
|
|
[](Mockups)
|
|
|
|
[](Banco-de-dados)
|
|
|
|
[](Configuração)
|
|
|
|
|
|
|
|
# Processo de Desenvolvimento
|
|
|
|
|
|
|
|
Esta seção descreve as diretrizes e padrões seguidos pelo time para garantir um fluxo de trabalho eficiente e colaborativo. A adoção de boas práticas facilita a comunicação, a rastreabilidade e a qualidade do código.
|
|
|
|
|
|
|
|
## Estratégia de Versionamento
|
|
|
|
|
|
|
|
Utilizamos o Git como sistema de controle de versão, adotando um fluxo baseado no **Git Flow** para organizar nosso desenvolvimento e facilitar a colaboração entre os membros da equipe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Estrutura de Branches
|
|
|
|
|
|
|
|
A estrutura de branches segue um padrão bem definido para garantir clareza e organização:
|
|
|
|
|
|
|
|
- **`main`**: Versão estável e pronta para produção.
|
|
|
|
- **`develop`**: Integração contínua de novas funcionalidades.
|
|
|
|
- **`feature/{id-da-issue}-{descricao-curta}`**: Desenvolvimento de novas funcionalidades.
|
|
|
|
- **`hotfix/{descricao}`**: Correção de problemas críticos encontrados em produção.
|
|
|
|
- **`release/{versao}`**: Preparação para um novo lançamento.
|
|
|
|
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
|
|
feature/45-autenticacao-oauth
|
|
|
|
```
|
|
|
|
|
|
|
|
### Padrão de Commits
|
|
|
|
|
|
|
|
Os commits devem seguir uma convenção semântica para melhorar a rastreabilidade e facilitar a leitura do histórico de mudanças. Adotamos o seguinte padrão:
|
|
|
|
|
|
|
|
- **feat:** Nova funcionalidade ou melhoria significativa.
|
|
|
|
- **fix:** Correção de bug.
|
|
|
|
- **docs:** Alterações em documentação.
|
|
|
|
- **test:** Inclusão ou modificação de testes.
|
|
|
|
- **ci:** Mudanças em configuração de CI/CD.
|
|
|
|
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
|
|
feat: implementação do login via OAuth
|
|
|
|
fix: ajuste na validação de senha
|
|
|
|
```
|
|
|
|
|
|
|
|
## Fluxo de Desenvolvimento
|
|
|
|
|
|
|
|
1. Criar uma branch a partir de `develop`:
|
|
|
|
```sh
|
|
|
|
git checkout develop
|
|
|
|
git pull
|
|
|
|
git checkout -b feature/{id-da-issue}-{descricao-curta}
|
|
|
|
```
|
|
|
|
2. Desenvolver e fazer commits semânticos.
|
|
|
|
3. Abrir um **Merge Request (MR)** para `develop`.
|
|
|
|
4. Aguardar revisão e aprovação.
|
|
|
|
5. Após a aprovação, realizar o merge e deletar a branch.
|
|
|
|
|
|
|
|
## Code Review e Boas Práticas
|
|
|
|
|
|
|
|
Para garantir a qualidade do código, todo MR deve:
|
|
|
|
- Ser revisado por pelo menos um membro da equipe.
|
|
|
|
- Ter uma descrição clara do que foi alterado e o motivo.
|
|
|
|
- Incluir testes unitários / automatizados sempre que aplicável.
|
|
|
|
- Seguir os padrões de lint e formatação adotados pelo projeto.
|
|
|
|
|
|
|
|
## Definition of Done (DoD)
|
|
|
|
|
|
|
|
Para que uma tarefa seja considerada finalizada, ela deve atender aos seguintes critérios:
|
|
|
|
- O código foi revisado e aprovado.
|
|
|
|
- Os testes foram implementados e passaram com sucesso.
|
|
|
|
- O build passou com sucesso.
|
|
|
|
- A documentação foi atualizada se necessário.
|
|
|
|
- O código foi integrado à branch `develop` e está pronto para ser lançado.
|
|
|
|
|
|
|
|
## Integração Contínua e Deploy
|
|
|
|
|
|
|
|
Adotamos um processo de integração contínua (CI) para garantir que as alterações sejam testadas e validadas antes de entrarem na branch principal. Além disso, o deploy é automatizado para ambientes de staging e produção.
|
|
|
|
|
|
|
|
Ferramentas utilizadas:
|
|
|
|
- **GitLab CI/CD** para pipelines de build, test e deploy.
|
|
|
|
- **Docker** para garantir ambientes consistentes.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
Seguir essas diretrizes ajuda a manter o projeto organizado, escalável e de fácil manutenção. Dúvidas ou sugestões? Compartilhe com o time!
|
|
|
|
|
