|
|
|
| [Home](home) | [Escopo](escopo) | [Gerência](gerência) | [Processo](processo) | [Mockups](mockups) | [Configuração](configuração) | [Arquitetura](arquitetura) | [DataBase](database) |[Infraestrutura](infraestrutura) |
|
|
|
|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:| |
|
|
\ No newline at end of file |
|
|
|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|
|
|
|
|
|
|
|
# Processo de Desenvolvimento
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
Esta seção é dedicada a apresentar o processo de desenvolvimento de código.
|
|
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
|
|
- [Git Workflow](#git-workflow)
|
|
|
|
|
|
|
|
## Git Workflow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Gitflow
|
|
|
|
O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (main e develop). Todas as novas branchs de desenvolvimento devem ser criadas abaixo da develop.
|
|
|
|
|
|
|
|
## Branches protegidas:
|
|
|
|
|
|
|
|
As branches "main" e "develop" não devem ser apagadas e possuem regras de proteção específicas para garantir que apenas usuários com papéis específicos possam realizar certas alterações:
|
|
|
|
|
|
|
|
#### main
|
|
|
|
|
|
|
|
É a branch principal do projeto. Esta branch deve sempre conter o código rodando no ambiente de produção, sem bugs. A branch é protegida e só pode ser alterada a partir de Merge Requests (MRs) vindo diretamente da branch **develop**. Apenas AGES III e IV podem realizar o merge dos MRs e realizar alterações nessa branch.
|
|
|
|
|
|
|
|
#### develop
|
|
|
|
|
|
|
|
É a branch para desenvolvimento, onde o código é continuamente atualizado e onde são realizados todos os MRs. Esta deve ser a branch de partida de todas as outras branches do projeto. Essa branch é protegida, o que significa que as alterações só podem ser feitas através de Merge Requests. Qualquer usuário com acesso ao projeto pode criar um MR para esta branch.
|
|
|
|
|
|
|
|
|
|
|
|
## Branches não protegidas (feature/fix/update):
|
|
|
|
|
|
|
|
**Feature:** branches para implementação de funcionalidades novas.
|
|
|
|
|
|
|
|
**Fix:** branches para correção de bugs.
|
|
|
|
|
|
|
|
**Update:** branches para atualizações.
|
|
|
|
|
|
|
|
Todos os MRs dessas branches devem sempre ser abertos para **develop**.
|
|
|
|
|
|
|
|
|
|
|
|
## Nomenclatura padrão para criação de branches:
|
|
|
|
|
|
|
|
tipo_da_branch/numero_da_us/o_que_sera_feito
|
|
|
|
|
|
|
|
exemplo: feat/us1/botao-login
|
|
|
|
|
|
|
|
|
|
|
|
## Como posso criar uma branch?
|
|
|
|
|
|
|
|
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch develop antes de criar uma branch nova:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git pull origin dev
|
|
|
|
```
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
Este comando garante que você esteja trabalhando com a versão mais atualizada do projeto. Depois, para criar a nova Branch na qual você realizará sua tarefa, execute o comando:
|
|
|
|
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git checkout -b feature/<nomeDaBranch>
|
|
|
|
```
|
|
|
|
</div>
|
|
|
|
|
|
|
|
Após a criação da branch, é necessário usar o comando \`push\` para publicar sua branch:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git push --set-upstream origin feature/<nomeDaBranch>
|
|
|
|
```
|
|
|
|
</div>
|
|
|
|
|
|
|
|
Pronto! Agora você já pode começar a programar na sua Branch.
|
|
|
|
|
|
|
|
### Commits
|
|
|
|
|
|
|
|
Para garantir que o commit a ser realizado terá apenas o código necessário para funcionamento da tarefa, use o comando `add` apenas nos arquivos **essenciais** para a tarefa:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git add <nomeDoArquivo>
|
|
|
|
```
|
|
|
|
</div>
|
|
|
|
|
|
|
|
Depois de adicionar todos os arquivos que deseja commitar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git commit -m 'descrição da tarefa'
|
|
|
|
```
|
|
|
|
<div>
|
|
|
|
|
|
|
|
Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso, use o comando `push`:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
<div>
|
|
|
|
|
|
|
|
|
|
|
|
### Merge Requests
|
|
|
|
|
|
|
|
Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:
|
|
|
|
|
|
|
|
#### Criando o Merge Request
|
|
|
|
|
|
|
|
A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão `New Merge Request` siga os seguintes passos:
|
|
|
|
|
|
|
|
1. Selecionar a branch de origem (sua branch de desenvolvimento);
|
|
|
|
2. Selecionar a branch de destino (branch dev);
|
|
|
|
3. Selecione `Compare branches and continue`
|
|
|
|
4. Em `Title`, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
|
|
|
|
5. Em `Description`, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
|
|
|
|
6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
|
|
|
|
7. Na seção `Assignee`, selecione `Assign to me` para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
|
|
|
|
8. Em `Milestone` selecione a Sprint em que a tarefa foi realizada;
|
|
|
|
9. Em `Labels`selecione qual é o tipo de tarefa que foi realizada;
|
|
|
|
10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em `Submit Merge Request`.
|
|
|
|
|
|
|
|
#### Revisando o Merge Request
|
|
|
|
|
|
|
|
A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.
|
|
|
|
|
|
|
|
Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no [Trello](https://trello.com/b/iVdoIjGJ/decolar-onboarding).
|
|
|
|
|
|
|
|
Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração. |
|
|
\ No newline at end of file |
