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
  • Branches
  • Commits
  • Merge Requests
  • Fluxo de aprovação do MR
  • Code-Lock

Observação: Consulte a seção Commits no menu Qualidade 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

<USXX><tipoDeItem>-<nomeDoItem>

• Exemplos de componentes:

  US06-component-navBar
  US07-component-slider

• Exemplos de páginas:

  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:

git pull origin dev

Em seguida, crie a nova branch:

git checkout -b <nomeDaBranch>

Faça o push inicial para registrar a branch no repositório remoto:

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:

<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:

• feat: add navbar component

• fix: resolve user authentication bug

Salvando localmente

Adicione apenas os arquivos relevantes para o commit:

git add <nomeDoArquivo>

Em seguida, faça o commit com uma mensagem conforme o padrão de Conventional Commits:

git commit -m 'feat: add user login functionality'

Salvando remotamente

Depois de concluir os commits locais, envie para o repositório remoto:

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

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