Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira como o time se organizou e trabalha.

🔖 Sumário

• Git Workflow
  • Definition of Ready
  • Definition of Done
• Padrões Utilizados
  • Branches
  • Commits
  • Merge Requests
• Code Freezing

🚂 Git Workflow

Para que os trabalhos no repositório sigam um fluxo organizado de trabalho, vamos adotar o Git Flow um fluxo de trabalho que consiste em duas principais branches:

• main: A branch principal, tendo todo o código final, validado e testado;
• develop: A branch de desenvolvimento, onde receberá todos as features realizados.
• hml: A branch de homologação, para validarmos em um ambiente real.

🚦 Definition of Ready

Para que uma tarefa seja considerada pronta para desenvolvimento, ela deve seguir as seguintes condições:

• Não possuir nenhuma outra tarefa que dependa dela;
• Comunicar e organizar com os colegas que estão vinculados à tarefa;
• Possuir o ambiente de desenvolvimento configurado de acordo com as regras. Mais detalhes em Instalação.

🏁 Definition of Done

Para que uma tarefa seja considerada concluída ela deve seguir as seguintes condições:

• O código deve estar funcional;
• Toda possível documentação deve ser criada (payloads, endpoints, ...);
• Todas revisões devem ter sido informadas e corrigidas;
• O merge request da tarefa deve ter sido revisado e aprovado por um AGES III;

🛠️ Padrões Utilizados

🌐 Idioma padrão

Como acordo, todas as branches, commits e merge requests devem ser descritos em português.

🔱 Branches

Para criar uma branch e começar a trabalhar nela, 3 comandos git serão essenciais, vejamos abaixo quais são eles:

git checkout hml # Vai para a branch ‘hml’.
git pull # Puxa as modificações remotas.
git checkout -b <NOME_DA_SUA_BRANCH_AQUI> # Cria uma nova branch.

Nos comandos acima, você estará trocando para a branch ‘hml’, puxando todas as modificações remotas, e criando uma nova branch a partir da branch ‘hml’, e também, a branch em uso passa a ser a criada. Você então passará a trabalhar na nova branch criada.

Os nomes das branches devem seguir o formato <tipo>/<breve-descrição>, onde o nome deve ser escrito no padrão kebab case, e os <tipo> são os seguintes:

• feat/breve-descricao-nova-feature
• fix/breve-descrição-do-fix
• refactor/breve-descricao-do-refactor

Ser o mais sucinto possível no nome da branch, caso necessite seja mais descritivo na abertura do MR

📦️ Commits

Para tornar mais consistentes as mensagens de commit, usamos o padrão Conventional Commits. Para seguir esse padrão, as mensagens, em geral, devem escritas seguindo no formato tipo(escopo): descrição, em que:

• o tipo, obrigatório, é um dos tipos possíveis de commit;
• o (escopo), opcional, sempre escrito entre parênteses, contextualiza o commit dentro do projeto, e pode ser tanto uma funcionalidade do produto, quanto uma questão técnica do projeto;
• a descrição, obrigatória, é uma mensagem escrita conforme a vontade do desenvolvedor, e descreve resumidamente o trabalho feito.

Exemplos do uso:

• feat: Implementation of sending the votes of each participant.
• fix(api): Correcting the submission of information to the database.
• docs: Describe commit patterns.
• build: dependencies updates.

A descrição é escrita de acordo com a vontade do desenvolvedor. O escopo não é pré-definido, mas o grupo deve procurar usar o mesmo nome quando falando do mesmo contexto/componente/etc; o escopo deve sempre ser um substantivo.

Os tipos são limitados; o Conventional Commits especifica dois -- "fix", que identifica uma correção em algo já existente, e "feat", que indica a adição de uma funcionalidade nova --, mas o time pode especificar outros, desde que use-os de forma consistente.

Tipos usados no time:

• "fix", para descrever soluções de problemas;
• "feat", para descrever funcionalidades adicionadas;
• "refactor", para descrever refatoração que não implica na funcionalidade da aplicação;

Mais informações estão disponíveis no link: Conventional Commits.

Para commits onde teve participação de mais de um autor. Siga o exemplo abaixo:

Co-Authored-By: Nome Sobrenome <[email protected]>

🤝 Merge Requests

Merge request(MR) deve ser criado apenas ao finalizar a task com todos seus objetivos atingidos. Ao criar o MR, o responsável entende que seu código está pronto para ser entregue em produção.

Cada projeto terá seu template de MR que deverá ser usado para descrever as mudanças realizadas. Campos não obrigatórios estarão descritos em comentários, os demais devem ser preenchidos pelo autor do MR.

O MR deve ser aberto da branch que foi criada por vocês para a branch develop, não deve excluir a branch de origem, deve selecionar algum ages 3 como reviewer do MR e se definir como autor. Se necessário alguma correção o ages 3 que revisou irá descrever o que está faltando ou errado no MR e só será aprovada e mergeada quando tudo estiver correto.

⛄ Code Freezing

É estabelecido um tempo onde se encerram os trabalhos de desenvolvimento antes de uma entrega, para garantir a qualidade da entrega, evitando possíveis bugs e problemas que possam surgir.