|
|
|
Essa seção é dedicada a exposição e documentação dos processos do time, tais como Git Workflow escolhido e `<adicionar mais processos de exemplo aqui>`, tanto para proporcionar um ambiente organizado para os AGES e outros usuários que consultarão o projeto, quanto para servir de consulta aos integrantes do time durante o processo de desenvolvimento
|
|
|
|
|
|
|
|
# Sumário
|
|
|
|
|
|
|
|
- [Git Workflow](#git-workflow)
|
|
|
|
|
|
|
|
# Git Workflow
|
|
|
|
O workflow escolhido se espelha no Gitflow workflow. As duas branches principais são `master` e `dev`:
|
|
|
|
- A `master` é onde concentramos as versões estáveis e as entregas para os Stakeholders. Por padrão iremos criar tags para cada merge que é feito nessa branch, seguindo o padrão de [versionamento semântico](#versionamento-semântico)
|
|
|
|
- A `dev` será de onde todas as outras branches serão criadas (com exceção à `hotfix`), e onde concentraremos a versão mais nova do software, sendo então onde as novas `features` serão mergeadas.
|
|
|
|
|
|
|
|
## Branches
|
|
|
|
Os possíveis tipos de branch que teremos e o padrão que cada uma delas deve seguir:
|
|
|
|
|
|
|
|
### master
|
|
|
|
Branch principal do projeto, onde o código testado e validado com o cliente é disponibilizado, através do merge de uma branch `release`. Essa branch ficara bloqueada para commits.
|
|
|
|
|
|
|
|
### develop
|
|
|
|
Branch de integração dos códigos desenvolvidos durante a duração do projeto. Todos as branches devem ser criadas a partir dela e os MRs correspondentes devem apontar para ela (salvo exceções). Essa branch também ficara bloqueada para commits, sendo possível altera-la apenas através de MRs.
|
|
|
|
|
|
|
|
### feature
|
|
|
|
Branch utilizada para o desenvolvimento das US.
|
|
|
|
```
|
|
|
|
feature/<codigo-da-US>
|
|
|
|
Ex.: feature/US-01
|
|
|
|
```
|
|
|
|
### release
|
|
|
|
Para realizar os testes e ajustes finais antes de disponibilizar o código em produção (master). As releases são enviadas para a master **somente** após a validação com os clientes.
|
|
|
|
```
|
|
|
|
release/<nr-da-sprint>
|
|
|
|
Ex.: release/01
|
|
|
|
```
|
|
|
|
### hotfix
|
|
|
|
Para corrigir erros que foram lançados em produção (master).
|
|
|
|
```
|
|
|
|
hotfix/<codigo-do-card> TODO: vamos atribuir código aos cards? Se não, trocar o codigo do card pelo problema a ser tratado.
|
|
|
|
Ex.: hotfix/ajustar-endpoint-de-suplementos
|
|
|
|
```
|
|
|
|
### task
|
|
|
|
Todas as alterações necessárias que não dizem respeito ao código em si devem ser feitas através de branches de task: Alterar dependências, adicionar arquivos de deploy...
|
|
|
|
```
|
|
|
|
task/<nome-do-card>
|
|
|
|
Ex.: task/adicionar-docker-compose
|
|
|
|
```
|
|
|
|
|
|
|
|
## Commits
|
|
|
|
### Estrutura
|
|
|
|
Todo commit deverá possuir a seguinte estrutura:
|
|
|
|
```<prefixo>: <descrição>```
|
|
|
|
Onde a descrição explica brevemente o que foi feito e o prefixo corresponde a uma das opções abaixo.
|
|
|
|
|
|
|
|
### Prefixos
|
|
|
|
- feat: trabalho em uma feature nova;
|
|
|
|
- task: adição/alteração não relacionada a código;
|
|
|
|
- fix: correção de algum bug ou problema na aplicação;
|
|
|
|
- test: adição/edição dos testes de uma funcionalidade;
|
|
|
|
- docs: ajustes na documentação/swagger/README.
|
|
|
|
|
|
|
|
### Exemplos
|
|
|
|
- feat: Criando tela de login
|
|
|
|
- fix: Corrigindo erro visual no botão de login
|
|
|
|
- task: Adicionando configuração do swagger para o endpoint de cadastro de suplementos
|
|
|
|
|
|
|
|
## Merge Requests
|
|
|
|
TODO
|
|
|
|
|
|
|
|
## Fluxo de Desenvolvimento
|
|
|
|
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch develop antes de criar uma branch nova:
|
|
|
|
```
|
|
|
|
git pull origin develop
|
|
|
|
```
|
|
|
|
1. Crie uma branch para o seu trabalho seguindo o padrões de nomenclatura
|
|
|
|
2. Commite as alterações periodicamente seguindo o padrão de mensagens de commit
|
|
|
|
3. **Crie os testes necessários** :warning:
|
|
|
|
4. Atualize sua branch com as mudanças da develop e resolva os conflitos
|
|
|
|
`git pull origin develop`
|
|
|
|
5. Abra o MR para a develop
|
|
|
|
6. Mova o Card da tarefa para *In Review*
|
|
|
|
7. Corrija/discuta os comentários feitos no MR
|
|
|
|
8. Realize o merge da tarefa **quando três pessoas aprovarem** |
|
|
\ No newline at end of file |
