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: Implementa envio dos votos de cada participante.
• fix(api): Corrige envio das informações de cadastro de ao banco.
• docs: Descreve padrões de commit.
• build: Atualiza dependências.

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