Instruções para edição: A atualização desta seção deve ser realizada preferencialmente pelos membros da equipe Ages III, ou sob sua supervisão direta. Os exemplos apresentados servem apenas como referência e devem ser substituídos por informações completas e precisas.
A documentação da Wiki é um recurso público e desempenha um papel essencial no projeto. Ela será amplamente utilizada nos relatórios individuais da equipe, além de ser referenciada por clientes e pelo público externo. Portanto, é fundamental que seu conteúdo seja elaborado com precisão técnica, clareza e atenção aos detalhes.
Recomendamos o uso de uma linguagem técnica adequada e a inclusão do máximo de informações relevantes. Uma documentação bem estruturada e bem escrita não apenas facilita a compreensão do projeto, mas também contribui diretamente para sua credibilidade e sucesso.
Seja meticuloso e comprometido ao editar esta seção.

Processo de Desenvolvimento e Qualidade de Software

Descrição

Este documento descreve o fluxo de trabalho adotado para o desenvolvimento de software, incluindo organização de branches, padrões de commits, revisão de Merge Requests (MR) e controle de qualidade.

Sumário

• Processo de Desenvolvimento e Qualidade de Software
  • Descrição
  • Sumário
  • Fluxo de Trabalho com Git
    • Branches
      • Criação de Branch
    • Commits
    • Merge Requests
    • Code-Lock
  • Qualidade de Software
    • Ferramentas
    • Testes
    • Padronização de Código

Fluxo de Trabalho com Git

Branches

Utilizamos um padrão consistente para nomeação de branches:

<prefixo>/<identificador>-<descricao>

Exemplos:

• feature/US06-component-navbar
• bugfix/US09-page-creations
• hotfix/13-endpoint-cadastro-produto

Criação de Branch

1. Atualize a branch dev:

   git pull origin dev

2. Crie uma nova branch:

   git checkout -b <nomeDaBranch>

3. Registre a branch no repositório remoto:

   git push --set-upstream origin <nomeDaBranch>

Commits

Adotamos o padrão Conventional Commits:

<tipo>: <descrição curta>

Tipos mais comuns:

• feat: Nova funcionalidade
• fix: Correção de bug
• refactor: Refatoramento de código
• docs: Atualização de documentação
• test: Adição ou ajuste de testes
• style: Ajustes de formatação
• chore: Manutenção sem impacto na aplicação

Exemplo de commit:

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

Merge Requests

1. Crie um Merge Request (MR) para a branch dev.
2. Preencha os seguintes campos:
   • Title: Resumo da alteração
   • Description: Justificativa da modificação
   • Milestone: Sprint correspondente
   • Labels: Ex.: feature, bugfix
3. Checklist para revisão:
   • O commit segue o padrão?
   • A branch está atualizada?
   • Os critérios de aceitação foram atendidos?
   • Foram incluídos testes?
   • A documentação foi atualizada?
   • Os testes automatizados passaram?
   • A funcionalidade foi validada localmente?
4. Pelo menos um desenvolvedor nível AGES III ou IV deve aprovar o MR.

Code-Lock

Nos dois dias anteriores à apresentação aos stakeholders e no dia do evento, novos MRs não serão aprovados para evitar problemas de infraestrutura e garantir estabilidade.

Qualidade de Software

Ferramentas

Para garantir qualidade e manutenibilidade do código, utilizamos:

• Jest: Testes unitários
• Insomnia/Postman: Testes de integração
• Eslint: Análise de sintaxe
• Prettier: Formatação automática
• Husky: Hooks para validação pré-commit
• Lint-Staged: Verificação de arquivos modificados

Testes

1. Testes Unitários: Desenvolvidos pelo autor da funcionalidade usando Jest.
2. Testes de Integração: Validação do sistema como um todo por meio de Insomnia/Postman.

Padronização de Código

Nosso fluxo de validação de código ocorre em dois momentos:

1. Localmente (pré-commit): Husky, Eslint e Prettier garantem conformidade antes do commit.
2. No GitLab (pós-push): O CI/CD valida novamente a qualidade do código.

                                                                                                         Topo