... | @@ -14,18 +14,16 @@ |
... | @@ -14,18 +14,16 @@ |
|
[![](https://img.shields.io/badge/Banco_de_dados-000000?style=for-the-badge&logo=markdown&logoColor=white)](banco_dados)
|
|
[![](https://img.shields.io/badge/Banco_de_dados-000000?style=for-the-badge&logo=markdown&logoColor=white)](banco_dados)
|
|
[![](https://img.shields.io/badge/Instalação-000000?style=for-the-badge&logo=markdown&logoColor=white)](instalacao)
|
|
[![](https://img.shields.io/badge/Instalação-000000?style=for-the-badge&logo=markdown&logoColor=white)](instalacao)
|
|
[![](https://img.shields.io/badge/Configuração-000000?style=for-the-badge&logo=markdown&logoColor=white)](configuracao)
|
|
[![](https://img.shields.io/badge/Configuração-000000?style=for-the-badge&logo=markdown&logoColor=white)](configuracao)
|
|
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
# Processo de Desenvolvimento
|
|
# Processo de 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.
|
|
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
|
|
|
|
|
|
- [Git Workflow](#git-workflow)
|
|
Git Workflow é um conjunto de práticas e padrões que as equipes de desenvolvimento usam para colaborar em projetos de software usando o sistema de controle de versão Git.
|
|
- [Template Pull Request](#template-pull-request)
|
|
|
|
|
|
|
|
## Git Workflow
|
|
O Git é uma ferramenta poderosa que permite que os desenvolvedores trabalhem juntos em um mesmo código-fonte sem causar conflitos ou perder trabalho. O Git workflow estabelece uma estrutura para como as alterações no código são gerenciadas, revisadas e implementadas, a fim de garantir que o projeto progrida de maneira organizada e eficiente.
|
|
|
|
|
|
### Nomes das Branches
|
|
### Nomes das Branches
|
|
|
|
|
... | @@ -37,7 +35,7 @@ Para padronizarmos os nomes das branches, deve-se nomeá-las da seguinte forma: |
... | @@ -37,7 +35,7 @@ Para padronizarmos os nomes das branches, deve-se nomeá-las da seguinte forma: |
|
|
|
|
|
Como por exemplo:
|
|
Como por exemplo:
|
|
```
|
|
```
|
|
US04-DesenvolverLogin
|
|
US04-add-login
|
|
```
|
|
```
|
|
|
|
|
|
### Semântica dos Commits
|
|
### Semântica dos Commits
|
... | @@ -55,7 +53,7 @@ Para padronizarmos a descrição dos commits, será utilizado um padrão semânt |
... | @@ -55,7 +53,7 @@ Para padronizarmos a descrição dos commits, será utilizado um padrão semânt |
|
- **refactor:** Tipo utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada;
|
|
- **refactor:** Tipo utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada;
|
|
- **style:** Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.);
|
|
- **style:** Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.);
|
|
- **chore:** Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas que realmente não entram em produção;
|
|
- **chore:** Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas que realmente não entram em produção;
|
|
- **env:** basicamente utilizado na descrição de modificações ou adições em arquivos de configuração em processos e métodos de integração contínua (CI), como parâmetros em arquivos de configuração de containers.
|
|
|
|
|
|
|
|
Exemplo da descrição commit:
|
|
Exemplo da descrição commit:
|
|
```
|
|
```
|
... | @@ -73,3 +71,22 @@ git checkout -b <NOME_DA_SUA_BRANCH_AQUI> # Cria uma nova branch. |
... | @@ -73,3 +71,22 @@ 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.
|
|
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 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, ...)
|
|
|
|
|
|
|
|
### Code freezing
|
|
|
|
|
|
|
|
Code freezing é uma data para congelamento de entrada de código em produção. Após essa data, nenhum merge request será mais aceito. A única coisa que pode passar por esse bloqueio são hotfixes para erros em produção
|
|
|
|
|
|
|
|
### 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 |