Skip to content

GitLab

Processo · Changes

Page history
Update Processo authored by Arthur Antunes de Souza Both's avatar Arthur Antunes de Souza Both
Hide whitespace changes
Inline Side-by-side
Processo.md
View page @ bdb73f55
### Documentação de Negócio
| [Escopo](escopo) | [**Processo**](processo) | [Gerência](gerencia) | [Design](design) | [Sprints](sprints)
|-|-|-|-|-
### Documentação Técnica
| [Arquitetura](arquitetura) | [Banco de Dados](bancoDeDados) | [Transferência](transferência)
|-|-|-
---
## Sumário
[[_TOC_]]
# Processo
Esta sessão visa documentar os processos de desenvolvimento utilizados no projeto _Creative Flow_.
## Git Flow
![gitFlow](https://tools.ages.pucrs.br/creative-flow/wiki/-/raw/main/documents/processes/gitFlow.png)
GitFlow é o processo de contribuição para os projetos utilizando a ferramenta de gerenciamento de versões Git. As definições descritas serão utilizadas nos repositórios do Frontend e Backend do projeto.
# 🌱 Padrões de Branch e Commit # 🌱 Padrões de Branch e Commit
## 📌 Commits ## 📌 Commits
Estamos utilizando o padrão [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) baseado em [@commitlint/config-conventional](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). Estamos utilizando um padrão inspiraado no [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), que é baseado em [@commitlint/config-conventional](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
- Os commits devem seguir `<tipo>(<escopo>): <mensagem>`;
- Escopo é a abreviação da user story com três números, separados por dois hífens (ex. us-1-2-3);
- Mensagens de commit não podem ultrapassar 72 caracteres e devem ser escritas no imperativo;
- Tipo é conforme abaixo:
### 🔹 Tipos de commit
* Os commits devem seguir `<tipo>(<escopo>): <mensagem>`; | Tipo | Descrição
* Escopo é a abreviação da user story com hífen e dois dígitos (e.g., us-01); |---------|----------
* Mensagens de commit não podem ultrapassar 72 caracteres e devem ser escritas no imperativo; | `feat` | Adição de uma nova funcionalidade
* Tipo é conforme abaixo: | `fix` | Correção de um problema (bug ou não)
| `refactor` | Refatoração de código (sem mudanças na funcionalidade)
| `infra` | Tarefas de repositório, que não afetam diretamente o produto final (ex. atualização de dependências)
| `test` | Adição ou modificação de testes
| `style` | Mudanças de formatação e estilo (sem afetar funcionalidade)
### 🔹 Tipos de commit: ### Exemplos
| Tipo | Descrição |
|---------|----------|
| `feat` | Adição de uma nova funcionalidade |
| `fix` | Correção de um bug |
| `refactor` | Refatoração de código (sem mudanças na funcionalidade) |
| `chore` | Tarefas de manutenção (ex.: atualização de dependências) |
| `docs` | Alterações na documentação |
| `test` | Adição ou modificação de testes |
| `style` | Mudanças de formatação e estilo (sem afetar funcionalidade) |
### Exemplos: - `feat(us-1-2-1): Do something`
- `feat(us-01): I did something` - `fix(no-us): something case sensitive`
- `fix(no-ref): something case sensitive`
### 🔹 Regras
### 🔹 Regras:
- O **tipo** do commit deve estar em **minúsculas**. - O **tipo** do commit deve estar em **minúsculas**.
- O identificador da **us** deve estar **entre parênteses**. - O identificador da **us** deve estar **entre parênteses**.
- A **descrição** deve ser breve e começar com **letra minúscula**. - A **descrição** deve ser breve e começar com **letra minúscula**.
...@@ -34,22 +61,138 @@ Estamos utilizando o padrão [Conventional Commits](https://www.conventionalcomm ...@@ -34,22 +61,138 @@ Estamos utilizando o padrão [Conventional Commits](https://www.conventionalcomm
## 📌 Branches ## 📌 Branches
As branches para desenvolvimento devem ser feitas a partir da `develop`. Os nomes de branch devem seguir `<tipo>/<escopo>/<descrição>`, onde a descrição **deve ser breve** e com hífen no lugar dos espaços. Tipo e escopo são definidos conforme dito anteriormente. As branches para desenvolvimento devem ser feitas a partir da `develop`. Os nomes de branch devem seguir `<escopo>/<descrição>`, onde a descrição **deve ser breve**, conter apenas letras minúsculas e utilizar hífens no lugar de espaços. Escopo é definido conforme dito anteriormente.
### Exemplos
### Exemplos: - `us-5-2-4/issue-naming`
- `us-01/issue-naming`
- `no-ref/writing-something-here` - `no-ref/writing-something-here`
### 🔹 Regras: ### 🔹 Regras
- **`us-XX/descricao`** → Para tarefas relacionadas a uma User Story (US). O número `XX` representa a ID da US.
- **`us-X-Y-Z/descricao`** → Para tarefas relacionadas a uma User Story (US). Os números `X`, `Y` e `Z` representam a ID da US.
- **`no-ref/descricao`** → Para alterações sem uma US específica. - **`no-ref/descricao`** → Para alterações sem uma US específica.
- Utilize **hífens (-) para separar palavras** na descrição da branch. - Utilize **hífens (-) para separar palavras** na descrição da branch.
- A descrição deve ser escrita em **letras minúsculas**.
- A descrição deve ser curta e clara. - A descrição deve ser curta e clara.
--- ---
## 🚨 Merge Requests ## 🚨 Merge Requests
O título do merge request deve seguir o mesmo formato dos commits acima. Os MRs precisam passar todos os jobs no pipeline e, após isso, podem ser mergeados por um AGES III. É obrigatório submeter o MR no formato definido pelo template. O título do merge request deve seguir o mesmo formato dos commits acima. Os MRs precisam passar todos os jobs no pipeline e, após isso, podem ser mergeados por um AGES III ou IV. É obrigatório submeter o MR no formato definido pelo template.
---
## Tutoriais
### Manter suas branches atualizadas
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar a seguinte sequência de comandos:
``` git
git fetch upsteram
git rebase upsteram dev
```
### Criando novas branches
Para criar uma nova branch, use a seguinte sequência de comandos:
Todas as branches devem ser originadas da _dev_.
``` git
git checkout dev
```
Use isto para garantir que sua _dev_ (local) está atualizada
``` git
git pull origin dev
```
Agora, devemos criar a branch no seu repositório local
``` git
git checkout -b <Nome da branch no formato padrão>
```
Por fim, é necessáiro fazer um `push` para garantir que a branch estará no remoto
``` git
git push --set-upstream origin <Nome da branch no formato padrão>
```
Pronto! Agora você já pode começar a programar na sua branch.
### Adicionando mudanças ao desenvolvimento
#### Salvando Localmente
Para realizar um commit, utilize:
``` git
git add <Nome do arquivo com extensão>
```
Ou, para múltiplos arquivos pode-se utilizar:
``` git
git add <arquivo 1> <arquivo 2> ...
```
Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit:
``` git
git commit -m "<Mensagem de commit no formato padrão>"
```
#### Salvando Remotamente
Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o GitLab.
Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando `push`:
``` git
git push
```
### Abrindo um Merge Request (MR)
Após a realização do desenvolvimento de uma tarefa e ela estiver de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development, então deve-se abrir um Merge Request.
Para criar o Merge Request devem ser seguidos os seguintes passos:
1. Selecionar a branch de origem (branch de desenvolvimento) e branch (branch de development) de destino.
![mrOriginInto](https://tools.ages.pucrs.br/creative-flow/wiki/-/raw/main/documents/processes/mrOriginInto.png)
2. Selecionar `Compare branch and continue`
3. No campo **Title**, manter o mesmo formato de padrão do commit, com a descrição sendo um resumo do que foi feito em todos os commits da tarefa.
![mrTitle](https://tools.ages.pucrs.br/creative-flow/wiki/-/raw/main/documents/processes/mrTitle.png)
4. No campo Description, utilizar o template disponível e preenchê-lo com as informações necessárias.
![mrDescription](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrDescription.png)
5. Em **Asignee**, selecione _Assign to me_ para que você fique registrado como responsável pelo desenvolvimento daquela tarefa.
![mrAssignToMe](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrAssignToMe.png)
6. Em **Reviewer**, selecione o _AGES III_ responsável pela sua _Squad_ para que ele seja notificado pelo gitlab como responsável pela revisão.
7. Em **Labels** adicione o tipo da tarefa que foi realizado.
![mrLabel](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrLabel.png)
8. Assegure-se que ambas as caixas `Delete source branch when merge request is accepted.` e `Squash commits when merge request is accepted.` estão marcadas.
![mrMergeOptions](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrMergeOptions.png)
9. Revise se os arquivos estão corretos e clique em Submit Merge Request.
### Revisando o Merge Request
Todo Merge Request deve ter pelo menos duas aprovações, sendo uma delas obrigatoriamente de um AGES III.
--- O merge deve ser feito com a estratégia squash-commits e as branches devem ser excluídas após o merge para a branch de destino.
\ No newline at end of file