|
|
|
| [Home](home) | [**Escopo**](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Gerência](gerencia) | [Estudos](estudos) | [Arquitetura](arquitetura) | [Contratos](contratos) | [BD](banco_dados) | [Qualidade](qualidade) | [Configuração](configuracao) | [Instalação](instalacao) | [Instruções](instrucoes) | [Utilização](utilizacao) | [Analytics](Analytics) |
|
|
|
|
| :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: | :----------: |
|
|
|
|
|
|
|
|
|
|
|
|
# Processo de Desenvolvimento
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
Nesta seção, apresentamos o processo de desenvolvimento seguido pela equipe. Aqui estão descritos o fluxo de trabalho com Git, a organização das branches, as práticas de commits, e as diretrizes para criação e revisão de Merge Requests.
|
|
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
|
|
- [Git Workflow](#git-workflow)
|
|
|
|
- [Branches](#branches)
|
|
|
|
- [Commits](#commits)
|
|
|
|
- [Merge Requests](#merge-requests)
|
|
|
|
- [Fluxo de aprovação do MR](#fluxo-de-aprovação-de-merge-request)
|
|
|
|
- [Code-Lock](#code-lock)
|
|
|
|
|
|
|
|
> **Observação:** Consulte a seção *Commits* no menu [Qualidade](qualidade#commits) para mais detalhes sobre design patterns.
|
|
|
|
|
|
|
|
## Git Workflow
|
|
|
|
|
|
|
|
### Branches
|
|
|
|
|
|
|
|
#### Nomes
|
|
|
|
|
|
|
|
Utilizamos um padrão consistente para a criação de branches:
|
|
|
|
A referência da User Storie + Tipo do item + nome do item
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<USXX><tipoDeItem>-<nomeDoItem>
|
|
|
|
```
|
|
|
|
|
|
|
|
- **Exemplos de componentes:**
|
|
|
|
```plaintext
|
|
|
|
US06-component-navBar
|
|
|
|
US07-component-slider
|
|
|
|
```
|
|
|
|
|
|
|
|
- **Exemplos de páginas:**
|
|
|
|
```plaintext
|
|
|
|
US15-page-recipes
|
|
|
|
US09-page-creations
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Criação
|
|
|
|
|
|
|
|
Para garantir que você está trabalhando com a versão mais atualizada da branch `dev`, execute o seguinte comando antes de criar uma nova branch:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git pull origin dev
|
|
|
|
```
|
|
|
|
|
|
|
|
Em seguida, crie a nova branch:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git checkout -b <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
Faça o `push` inicial para registrar a branch no repositório remoto:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git push --set-upstream origin <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
Agora, sua branch está pronta para desenvolvimento.
|
|
|
|
|
|
|
|
### Commits
|
|
|
|
|
|
|
|
Usamos o formato de **Conventional Commits** para garantir padronização e clareza nas mensagens de commit. As mensagens seguem o seguinte padrão:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
<tipo>: <descrição curta>
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Tipos de commit mais comuns:
|
|
|
|
|
|
|
|
- **feat**: Para adicionar uma nova funcionalidade.
|
|
|
|
- **fix**: Para corrigir bugs.
|
|
|
|
- **refactor**: Para mudanças de código que não afetam o comportamento, apenas refatorações.
|
|
|
|
- **docs**: Para atualizações de documentação.
|
|
|
|
- **test**: Para adição ou ajuste de testes.
|
|
|
|
- **style**: Para mudanças de formatação de código (espaços, ponto e vírgula, etc).
|
|
|
|
- **chore**: Para mudanças que não afetam a aplicação ou testes, como atualizações de dependências.
|
|
|
|
|
|
|
|
#### Exemplos de mensagens de commit:
|
|
|
|
|
|
|
|
- ```plaintext
|
|
|
|
feat: add navbar component
|
|
|
|
```
|
|
|
|
- ```plaintext
|
|
|
|
fix: resolve user authentication bug
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Salvando localmente
|
|
|
|
|
|
|
|
Adicione apenas os arquivos relevantes para o commit:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git add <nomeDoArquivo>
|
|
|
|
```
|
|
|
|
|
|
|
|
Em seguida, faça o commit com uma mensagem conforme o padrão de Conventional Commits:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git commit -m 'feat: add user login functionality'
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Salvando remotamente
|
|
|
|
|
|
|
|
Depois de concluir os commits locais, envie para o repositório remoto:
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
|
|
|
|
### Merge Requests
|
|
|
|
|
|
|
|
Após concluir o desenvolvimento da tarefa, envie um Merge Request (MR) para a branch de destino, seguindo os critérios de aceitação.
|
|
|
|
|
|
|
|
|
|
|
|
#### Criando o Merge Request no GitLab
|
|
|
|
|
|
|
|
1. Selecione a branch de origem (sua branch de desenvolvimento).
|
|
|
|
2. Selecione a branch de destino (branch `dev`).
|
|
|
|
3. Clique em `Compare branches and continue`.
|
|
|
|
4. No campo `Title`, escreva um título conciso que descreva a tarefa.
|
|
|
|
5. Em `Description`, inclua uma breve descrição justificando as alterações.
|
|
|
|
6. Se aplicável, adicione um gif ou imagem mostrando as mudanças (ex.: correções visuais ou novos componentes).
|
|
|
|
7. Em `Assignee`, selecione você mesmo.
|
|
|
|
8. Em `Milestone`, selecione a sprint em que a tarefa foi realizada.
|
|
|
|
9. Adicione os `Labels` apropriados (ex.: `feature`, `bugfix`).
|
|
|
|
10. Revise os arquivos que estão sendo enviados e clique em `Submit Merge Request`.
|
|
|
|
|
|
|
|
#### Exemplo de Checklist para revisão de Merge Requests
|
|
|
|
|
|
|
|
- [ ] O código segue o padrão de commits convencionais?
|
|
|
|
- [ ] A branch está atualizada com a branch `dev`?
|
|
|
|
- [ ] Todos os critérios de aceitação foram atendidos?
|
|
|
|
- [ ] Foram incluídos testes para validar a funcionalidade ou correção?
|
|
|
|
- [ ] A documentação foi atualizada (se necessário)?
|
|
|
|
- [ ] O código segue as boas práticas de formatação e estilo?
|
|
|
|
- [ ] Não há erros ou falhas nos testes automatizados?
|
|
|
|
- [ ] A funcionalidade foi validada localmente (visual, bugs, etc.)?
|
|
|
|
|
|
|
|
> **Observação:** Pelo menos um desenvolvedor de nível AGES III ou IV deve revisar e aprovar o MR antes do merge final.
|
|
|
|
|
|
|
|
### Fluxo de aprovação de Merge Request
|
|
|
|
- será respeitada a ordem de chegada dos MR
|
|
|
|
- prazo máximo de 24hs para aprovação, com exceção do [**code-lock**](#code-lock)
|
|
|
|
|
|
|
|
### Code-Lock
|
|
|
|
Será adotado um período de interrupção nas aprovações de novos MR, que deverá compreender o dia da apresentação aos stakeholders e os dois dias anteriores. Este período é essencial para resolver questões de infra e ambiente de produção, bem como outros problemas que possam surgir. Durante esse período não serão aprovados/realizados merges na main. Os MR pendentes serão analisados no final do code-lock, depois de realizada a apresentação aos stakeholders.
|
|
|
|
|
|
|
|
---
|
|
|
|
[**Topo**](#processo-de-desenvolvimento) |
|
|
\ No newline at end of file |
