|
|
|
# Quadro de tarefas
|
|
|
|
Para o gerenciamento do projeto e acompanhamento das tarefas, foi criado um board na Azure onde temos as tarefas separadas por épicos.
|
|
|
|
|
|
|
|
Sempre que for trabalhar em um item, seja ele correção ou funcionalidade nova, verifique se já não existe uma tarefa igual no board. Em caso negativo, comunique ao AGES IV.
|
|
|
|
|
|
|
|
> Para acessar o board, [clique aqui](https://dev.azure.com/AGES-Ludo-Pets/Ludo%20Pets/_sprints/taskboard/Ludo%20Pets%20Team/Ludo%20Pets/Sprint%202)
|
|
|
|
|
|
|
|

|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
# GitFlow
|
|
|
|
No projeto, seguimos o GitFlow conforme a imagem abaixo:
|
|
|
|

|
|
|
|
|
|
|
|
## Padrão de nomenclatura
|
|
|
|
|
|
|
|
## Branches
|
|
|
|
Toda branch terá todo seu texto em minúsculo com palavras separadas por `-`.
|
|
|
|
### Tipos de branches
|
|
|
|
|
|
|
|
#### `main`
|
|
|
|
- Código validado e testado.
|
|
|
|
- Só vai para produção o que já foi aprovado pelo cliente.
|
|
|
|
|
|
|
|
#### `develop`
|
|
|
|
- Branch de integração da sprint.
|
|
|
|
- Todos os MRs de funcionalidades e correções vão para cá.
|
|
|
|
- No fim da sprint, ela vira uma release.
|
|
|
|
|
|
|
|
#### `feat/{ID-US}-{nome-da-tarefa}`
|
|
|
|
- Branch para desenvolver **funcionalidades**.
|
|
|
|
- Exemplo: `feat/01-create-login-screen`
|
|
|
|
|
|
|
|
#### `release/{numero-da-sprint}`
|
|
|
|
- Junta tudo da sprint para deploy.
|
|
|
|
- Exemplo: `release/1`
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Commits
|
|
|
|
|
|
|
|
Formato do commit:
|
|
|
|
`{prefixo}({área}): {ID-US} descrição no gerúndio`
|
|
|
|
|
|
|
|
### Prefixos
|
|
|
|
|
|
|
|
| Prefixo | Quando usar |
|
|
|
|
|-----------|-------------|
|
|
|
|
| `feat` | Nova funcionalidade |
|
|
|
|
| `test` | Testes criados ou alterados |
|
|
|
|
| `fix` | Correções de bugs |
|
|
|
|
| `chore` | Configurações ou código que não vai pra produção |
|
|
|
|
| `refactor`| Refatoração de código |
|
|
|
|
| `docs` | Documentação, Swagger, README |
|
|
|
|
| `style` | Formatação, sem mudar comportamento |
|
|
|
|
| `build` | CI/CD e build da aplicação |
|
|
|
|
|
|
|
|
### Exemplos
|
|
|
|
|
|
|
|
- `feat(sign-up): creating login components`
|
|
|
|
- `fix(sign-up): fixing empty CPF error`
|
|
|
|
- `chore(sign-up) adding swagger configuration`
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Como desenvolver uma US
|
|
|
|
|
|
|
|
### 1. Escolher e iniciar
|
|
|
|
- Vá até o board, escolha/crie uma tarefa
|
|
|
|
- Atribua seu nome (_Assignee_)
|
|
|
|
- Mova para _In Progress_
|
|
|
|
|
|
|
|
### 2. Desenvolvimento
|
|
|
|
1. Crie uma branch com o nome certo
|
|
|
|
2. Commite seguindo o padrão
|
|
|
|
3. **Escreva os testes**
|
|
|
|
4. Mantenha a branch atualizada:
|
|
|
|
```
|
|
|
|
git fetch
|
|
|
|
git merge origin/develop
|
|
|
|
```
|
|
|
|
5. Abra o Merge Request para `develop` e preencha o template
|
|
|
|
6. Resolva conflitos se houver
|
|
|
|
7. Mova o card para _In Review_
|
|
|
|
8. Resolva os comentários do PR
|
|
|
|
9. Faça o merge após **duas aprovações (1 AGES III obrigatória)**
|
|
|
|
10. Mova para _In Homolog_
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Estrutura de um Merge Request
|
|
|
|
|
|
|
|
### Título
|
|
|
|
Prefixado com o número da tarefa, deve ser conciso e sucinto no que foi alterado
|
|
|
|
|
|
|
|
### Descrição
|
|
|
|
Aqui é o espaço para detalhar as alterações feitas, decisões tomadas e até mesmo explicar porque algumas coisas foram alteradas.
|
|
|
|
|
|
|
|
* Caso tenha trabalhado em uma tela, **forneça screenshots das telas** criadas/alteradas caso tenha alguma mudança visual
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Checklist aprovação do PR:
|
|
|
|
- Revisado por no minimo 2 pessoas (1 AGES III obrigatório)
|
|
|
|
- Sem conflitos
|
|
|
|
- Comentários Respondidos (se houver)
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
## Definition of Done (DoD)
|
|
|
|
|
|
|
|
O que precisa para considerar a tarefa pronta:
|
|
|
|
|
|
|
|
- Alinhado com o design
|
|
|
|
- Atende os critérios de aceitação
|
|
|
|
- Develop revisada
|
|
|
|
--- |
|
|
|
\ No newline at end of file |