|
|
|
<table>
|
|
|
|
<th> [Home](home) </th>
|
|
|
|
<th> [Gerenciamento](gerenciamento) </th>
|
|
|
|
<th> [Escopo & Cronograma](escopo)</th>
|
|
|
|
<th> [Requisitos](requisitos)</th>
|
|
|
|
<th> [Design & Mockups](design) </th>
|
|
|
|
<th> [Arquitetura](arquitetura) </th>
|
|
|
|
<th> [Persistência](persistencia) </th>
|
|
|
|
<th> [Infraestrutura](infraestrutura) </th>
|
|
|
|
<th> [Desenvolvimento & Qualidade](desenvolvimento) </th>
|
|
|
|
<th> [Instalação e Configuração](instalacao) </th>
|
|
|
|
<th> [Utilização](utilizacao) </th>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
> **Instruções para edição:** A atualização desta seção deve ser realizada preferencialmente pelos membros da equipe **Ages III**, ou sob sua supervisão direta. Os exemplos apresentados servem apenas como referência e devem ser substituídos por informações completas e precisas.
|
|
|
|
> A documentação da Wiki é um recurso público e desempenha um papel essencial no projeto. Ela será amplamente utilizada nos relatórios individuais da equipe, além de ser referenciada por clientes e pelo público externo. Portanto, é fundamental que seu conteúdo seja elaborado com precisão técnica, clareza e atenção aos detalhes.
|
|
|
|
Recomendamos o uso de uma linguagem técnica adequada e a inclusão do máximo de informações relevantes. Uma documentação bem estruturada e bem escrita não apenas facilita a compreensão do projeto, mas também contribui diretamente para sua credibilidade e sucesso.
|
|
|
|
> Seja meticuloso e comprometido ao editar esta seção.
|
|
|
|
|
|
|
|
|
|
|
|
# Processo de Desenvolvimento e Qualidade de Software
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
Este documento descreve o fluxo de trabalho adotado para o desenvolvimento de software, incluindo organização de branches, padrões de commits, revisão de Merge Requests (MR) e controle de qualidade.
|
|
|
|
|
|
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
|
|
- [Processo de Desenvolvimento e Qualidade de Software](#processo-de-desenvolvimento-e-qualidade-de-software)
|
|
|
|
- [Descrição](#descrição)
|
|
|
|
- [Sumário](#sumário)
|
|
|
|
- [Fluxo de Trabalho com Git](#fluxo-de-trabalho-com-git)
|
|
|
|
- [Branches](#branches)
|
|
|
|
- [Criação de Branch](#criação-de-branch)
|
|
|
|
- [Commits](#commits)
|
|
|
|
- [Merge Requests](#merge-requests)
|
|
|
|
- [Code-Lock](#code-lock)
|
|
|
|
- [Qualidade de Software](#qualidade-de-software)
|
|
|
|
- [Ferramentas](#ferramentas)
|
|
|
|
- [Testes](#testes)
|
|
|
|
- [Padronização de Código](#padronização-de-código)
|
|
|
|
|
|
|
|
## Fluxo de Trabalho com Git
|
|
|
|
|
|
|
|
### Branches
|
|
|
|
|
|
|
|
Utilizamos um padrão consistente para nomeação de branches:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<prefixo>/<identificador>-<descricao>
|
|
|
|
```
|
|
|
|
|
|
|
|
**Exemplos:**
|
|
|
|
- `feature/US06-component-navbar`
|
|
|
|
- `bugfix/US09-page-creations`
|
|
|
|
- `hotfix/13-endpoint-cadastro-produto`
|
|
|
|
|
|
|
|
#### Criação de Branch
|
|
|
|
|
|
|
|
1. Atualize a branch `dev`:
|
|
|
|
```bash
|
|
|
|
git pull origin dev
|
|
|
|
```
|
|
|
|
2. Crie uma nova branch:
|
|
|
|
```bash
|
|
|
|
git checkout -b <nomeDaBranch>
|
|
|
|
```
|
|
|
|
3. Registre a branch no repositório remoto:
|
|
|
|
```bash
|
|
|
|
git push --set-upstream origin <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
### Commits
|
|
|
|
|
|
|
|
Adotamos o padrão **Conventional Commits**:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<tipo>: <descrição curta>
|
|
|
|
```
|
|
|
|
|
|
|
|
**Tipos mais comuns:**
|
|
|
|
- **feat**: Nova funcionalidade
|
|
|
|
- **fix**: Correção de bug
|
|
|
|
- **refactor**: Refatoramento de código
|
|
|
|
- **docs**: Atualização de documentação
|
|
|
|
- **test**: Adição ou ajuste de testes
|
|
|
|
- **style**: Ajustes de formatação
|
|
|
|
- **chore**: Manutenção sem impacto na aplicação
|
|
|
|
|
|
|
|
**Exemplo de commit:**
|
|
|
|
```bash
|
|
|
|
git commit -m 'feat: add user login functionality'
|
|
|
|
```
|
|
|
|
|
|
|
|
### Merge Requests
|
|
|
|
|
|
|
|
1. Crie um Merge Request (MR) para a branch `dev`.
|
|
|
|
2. Preencha os seguintes campos:
|
|
|
|
- **Title**: Resumo da alteração
|
|
|
|
- **Description**: Justificativa da modificação
|
|
|
|
- **Milestone**: Sprint correspondente
|
|
|
|
- **Labels**: Ex.: `feature`, `bugfix`
|
|
|
|
3. Checklist para revisão:
|
|
|
|
- [ ] O commit segue o padrão?
|
|
|
|
- [ ] A branch está atualizada?
|
|
|
|
- [ ] Os critérios de aceitação foram atendidos?
|
|
|
|
- [ ] Foram incluídos testes?
|
|
|
|
- [ ] A documentação foi atualizada?
|
|
|
|
- [ ] Os testes automatizados passaram?
|
|
|
|
- [ ] A funcionalidade foi validada localmente?
|
|
|
|
4. Pelo menos um desenvolvedor nível AGES III ou IV deve aprovar o MR.
|
|
|
|
|
|
|
|
### Code-Lock
|
|
|
|
|
|
|
|
Nos dois dias anteriores à apresentação aos stakeholders e no dia do evento, novos MRs não serão aprovados para evitar problemas de infraestrutura e garantir estabilidade.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Qualidade de Software
|
|
|
|
|
|
|
|
### Ferramentas
|
|
|
|
|
|
|
|
Para garantir qualidade e manutenibilidade do código, utilizamos:
|
|
|
|
- **Jest**: Testes unitários
|
|
|
|
- **Insomnia/Postman**: Testes de integração
|
|
|
|
- **Eslint**: Análise de sintaxe
|
|
|
|
- **Prettier**: Formatação automática
|
|
|
|
- **Husky**: Hooks para validação pré-commit
|
|
|
|
- **Lint-Staged**: Verificação de arquivos modificados
|
|
|
|
|
|
|
|
### Testes
|
|
|
|
|
|
|
|
1. **Testes Unitários**: Desenvolvidos pelo autor da funcionalidade usando Jest.
|
|
|
|
2. **Testes de Integração**: Validação do sistema como um todo por meio de Insomnia/Postman.
|
|
|
|
|
|
|
|
### Padronização de Código
|
|
|
|
|
|
|
|
Nosso fluxo de validação de código ocorre em dois momentos:
|
|
|
|
1. **Localmente (pré-commit)**: Husky, Eslint e Prettier garantem conformidade antes do commit.
|
|
|
|
2. **No GitLab (pós-push)**: O CI/CD valida novamente a qualidade do código.
|
|
|
|
|
|
|
|
---
|
|
|
|
[**Topo**](#processo-de-desenvolvimento-e-qualidade-de-software) |
|
|
\ No newline at end of file |
