Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • Ludo Pets
  • Wiki
  • Wiki
  • Processo

Processo · Changes

Page history
Create Processo authored Mar 22, 2025 by Gustavo Pretto Scholze's avatar Gustavo Pretto Scholze
Hide whitespace changes
Inline Side-by-side
Processo.md 0 → 100644
View page @ be78699a
# 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)
![image](uploads/85d673b307adfc31c55551df3d1016ba/image.png)
---
# GitFlow
No projeto, seguimos o GitFlow conforme a imagem abaixo:
![image](uploads/f21fefd296746ac690ce21255eecbfae/image.png)
## 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
Clone repository
  • Banco de Dados
  • Configuração
  • Código
  • Processo
  • arquitetura
  • design_mockups
  • escopo e cronograma
  • Home