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.

Padrões utilizados

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
• chore/12
• spike/11

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.

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, ...).