Documentação do negócio

Documentação técnica

\mathbb{PROCESSO \space DE \space DESENVOLVIMENTO}

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

• xxx
• xxx
• Definition of Ready
• Padrões utilizados
• Definition of Done

Definition of Ready

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

• Qualquer tarefa da qual ela tenha dependência.
• O ambiente de desenvolvimento local deve estar devidamente setado.

Definition of Done

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

• O merge request da branch em que a tarefa foi desenvolvida para a develop deve ter sido concluída.
• O código deve ter sido revisado e aprovado.
• O código deve ter testes unitários e ter sido testado manualmente.
• Qualquer documentação necessária deve ter sido escrita (payloads, endpoints, ...).

Padrões utilizados

Idioma padrão:

Como acordo, todas as branches, commits e MR devem ser descritos em inglê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 develop # Vai para a branch ‘develop’.
git pull # Puxa as modificações remotas.
git checkout -b <NOME_DA_SUA_BRANCH_AQUI> # Cria uma nova branch.

Utilizando os comandos acima, você estará indo para a branch ‘develop’, puxando todas as modificações remotas e criando uma nova branch a partir de ‘develop’. Você então passará a trabalhar na nova branch criada.

Os nomes das branches devem seguir o formato <tipo>/<código>, onde os <tipo> são os mesmos tipos usados nas tarefas cadastradas no Trello, e o <código> é o card number, que pode ser encontrado logo abaixo do título do card, seguido de um "#".

Exemplos:

• task/15
• build/12
• spike/11

Excessões

Caso a demanda que está sendo desenvolvida não esteja descrita em uma task em nosso board do Trello, devemos seguir o seguinte padrão:

<tipo>/<descrição_breve>

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 da mesma coisa; 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;
• "docs", para identificar trabalho na documentação do projeto;
• "build", para identificar trabalho na configuração do projeto.

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

Além desse padrão, estamos usando a ferramenta Husky para padronizar os commit. O husky roda dois comandos ao tentar fazer um commit, ele primeiro, verifica a mensagem do commit para ver se está de acordo com o padrão do projeto, e segundo, ele executa o comando lint-staged descrito no package.json

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

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

Merge Request (MR)

Merge request 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.

Ao analisar um MR, caso o revisor note alguma correção a ser feita no código, o autor será avisado pelo canal de MRs do discord, iremos marcar o usuário no discord para enviar uma notificação. Uma vez que forem corrigidos os pontos levantados, o autor deve reagir à marcação feita no canal do discord com um emoji ✅ para sinalizar que o MR está pronto para reavaliação.