Home	Escopo e Cronograma	Processo	Design/Mockups	Configuração	Arquitetura	Código	BD	Qualidade	Utilização

Board

Para o gerenciamento do projeto e acompanhamento das tarefas, foi criado um board no Notion 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, crie uma tarefa nova.

Para acessar o board, clique aqui

GitFlow

No projeto, seguimos o GitFlow conforme a imagem abaixo:

Padrão de nomenclatura

Branches

Toda branch terá todo seu texto em minúsculo com palavras separadas por -. A única seção é no id da US que podemos usar letras maiúsculas.

Commits

Todo commit deverá possuir a seguinte estrutura:
{prefixo}({_item alterado/funcionalidade}): {id-us} Descrevendo o que foi feito no gerúndio

Prefixos

• feat: trabalho em uma feature nova
• test: criação/edição dos testes de uma funcionalidade
• fix: correção de algum bug ou problema na aplicação
• chore: alterações relacionadas a configuração/código que não vai para produção
• refactor: refatoração de alguma parte do código
• docs: ajustes na documentação/swagger/README
• style: ajustes na formatação do código
• build: ajustes referentes a CI/CD

Exemplos de mensagem de commit

• feat(cadastro): Criando componente de tela de login
• fix(cadastro): Corrigindo erro ao passar CPF vazio
• chore(cadastro): Adicionando configuração do swagger para o endpoint de cadastro de usuário

main

Branch principal do projeto, apenas código testado e validado com o cliente pode ir para a main.

feat/{id-us}-{nome-tarefa}

Feature branches são onde iremos desenvolver o código referente a uma funcionalidade.

Uma vez que o código tenha testes unitários e integração(backend), abrimos um Merge Request para a develop

Exemplos de nome são:

• feat/VDC-01-criar-tela-login
• feat/VDC-02-criar-endpoint-login

develop

Branch de integração dos códigos desenvolvidos durante uma sprint. Todo MR de funcionalidades e correções é aberto para a develop e então, no final da sprint, um MR é aberto da develop para uma branch de release

release/{numero-sprint}

Branches de release servem para agrupar o código desenvolvido até o code freezing de uma sprint e fazer o deploy na AWS.

Uma vez feito o deploy e validado com os clientes, abrimos um MR da release branch para main

Exemplos de nome são:

• release/1
• release/2

Desenvolvendo uma US

Escolhendo uma tarefa

1. Acesse o board
2. Crie/Escolha uma tarefa
3. Ponha seu usuário como Assignee
4. Mova a tarefa para In Progress quando iniciar o desenvolvimento

Fluxo de Desenvolvimento

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. Rode na branch da tarefa para atualizar ela com outras mudanças da develop:
   git fetch
git merge origin/develop
5. Abra o MR para a develop preenchendo o template de MR
6. Corrija eventuais conflitos/peça ajuda
7. Mova o Card da tarefa para In Review
8. Corrija/discuta os apontamentos feitos no MR
9. Realize o merge da tarefa quando duas pessoas aprovarem
10. Mova o Card da tarefa 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 até mesmo porque algumas coisas foram alteradas.

• Caso tenha trabalhado em uma tela, forneça screenshots das telas criadas/alteradas caso tenha alguma mudança visual
• Caso tenha criado um endpoint e haja alguma mudança no contrato, explique a mudança e até mesmo forneça exemplos de requisição no Postman/Swagger

Check-List aprovação do PR:

• Conter Testes
• Revisado por no minimo 2 pessoas (1 AGES III obrigatório)
• Sem conflitos
• Comentários Respondidos(se houver)

Definition of Done(DoD):

Descrição:

A Definition of Done (DoD) é um conjunto de “combinados” entre o Scrum Team (PO + Devs + SM) que cada item de backlog que é produzido no Sprint Planning deve atender para ser dado como pronto (serviço concluído).

Check-List:

• Estar condizente com o Design
• Cumprir critérios de Aceitação
• Conter Testes
• Develop estar revisada
• Integração de Front-end e Back-end