|
|
|
|
|
|
|
|
|
|
|
[](home)
|
|
|
|
|
|
|
|
# Documentação do negócio
|
|
|
|
[](sprints)
|
|
|
|
[](requisitos)
|
|
|
|
[](processos)
|
|
|
|
[](gerencia)
|
|
|
|
[](horarios)
|
|
|
|
[](squads)
|
|
|
|
|
|
|
|
# Documentação técnica
|
|
|
|
[](arquitetura)
|
|
|
|
[](mockups)
|
|
|
|
[](banco_dados)
|
|
|
|
[](instalacao)
|
|
|
|
|
|
|
|
---
|
|
|
|
# $`\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](#git-workflow)
|
|
|
|
- [xxx](#code-freezing)
|
|
|
|
- [Definition of Ready](#definition-of-ready)
|
|
|
|
- [Definition of Done](#definition-of-done)
|
|
|
|
|
|
|
|
### Criando uma Branch
|
|
|
|
|
|
|
|
Para criar uma branch e começar a trabalhar nela, 3 comandos git serão essenciais, vejamos abaixo quais são eles:
|
|
|
|
|
|
|
|
```sh
|
|
|
|
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.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### 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, ...).
|
|
|
|
|
|
|
|
--- |