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

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
• 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 ⚠
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