Skip to content

GitLab

processo · Changes

Page history
Update processo authored by João Vianna Moog Brentano's avatar João Vianna Moog Brentano
Hide whitespace changes
Inline Side-by-side
processo.md
View page @ f7dfc7d9
......@@ -14,130 +14,29 @@ Esta seção é dedicada a apresentar o processo de desenvolvimento do time, jun
- [Plano de Comunicação](#plano-de-comunicação)
- [Plano de Riscos](#plano-de-riscos)
## Git Workflow
## Git Branching Model
### Branches
O modelo de gestão das branches do Git é baseado no [Git Flow "tradicional"](https://nvie.com/posts/a-successful-git-branching-model/) com adaptações. Não é previsto o uso de branches `hotfix/*`, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.
#### Nomes
O desenvolvimento nos repositórios devem seguir o fluxo de Git aqui definido:
Como padrão para nomes de branches, foi decidido o seguinte:
* uma branch `master` com o código atualmente em produção;
* uma branch `develop` com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
* feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, `feature/t06-login` ou `feature/t24-reports-ui`);
* quando uma feature é finalizada, um PR da branch `feature/` relacionada é aberto com destino à branch `develop`.
```
<tipoDeItem>-<nomeDoItem>
```
O código da `develop` é integrado com a `master` ao final da sprint, após validação dos stakeholders do que foi desenvolvido.
Exemplo de Componentes:
```
component-navBar
component-slider
```
Exemplo de Páginas:
```
page-recipes
page-creations
```
#### Criação
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:
```
git pull origin dev
```
Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:
```
git checkout -b <nomeDaBranch>
```
Assim que criar a branch, é necessário fazer um `push`para garantir que a mesma estará remota:
```
git push --set-upstream origin <nomeDaBranch>
```
Pronto! Agora você já pode começar a programar na sua Branch.
### Commits
Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de `commit` e `push`
#### Salvando Localmente
Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando `add` apenas nos arquivos **essenciais** para a tarefa:
```
git add <nomeDoArquivo>
```
Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:
```
git commit -m 'descrição da tarefa em português'
```
Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento
#### Salvando Remotamente
Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando `push`:
```
git push
```
### 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 [Airtable](https://airtable.com/tblV0c8w2YX9PZAAC/viw4mJkZmd28WlplE?blocks=hide).
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.
## Matriz de Responsabilidade
Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
| **Atividades** | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
| -------------------------- | :--------: | :---------: | :----------: | :---------: |
| Alimentar a wiki | R | R | R | R/A |
| Definir squads | I/C | C | C | R/A |
| Definir marcos da sprint | I/C | I/C | I/C | R/A |
| Quebra de tasks | I/C | I/C | R/A | R/A |
| Desenvolvimento | R | R | R/A | I |
| Code review | I | I | R/A | I |
| Executar testes funcionais | I | R/A | C | |
| Deploy da aplicação | | C | R/A | C |
| Apresentação da review | | | | R/A |
- I: Deve ser informado
- C: Deve ser consultado
- R: Responsável
- A: Aprova
Dessa forma, o fluxo usual de trabalho é o seguinte:
1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch `develop` e pegar as últimas atualizações (`pull`);
2. criar uma branch para a task com o ID da task (`feature/tXX-YYYYY`);
3. "enviar" a branch para o remoto (`git push -u origin feature/tXX-YYYYY`);
4. desenvolver, commitar mudanças e atualizar o remoto (`push`);
5. voltar para o item **4** até finalizar a task;
6. abrir um PR com destino à branch `develop`;
7. mover o card da task no Trello para a lista *Code Review* e avisar no Slack (canal #code-review) que a task está pronta para review;
8. fim! :smiley:
## Plano de Comunicação
......