| ... | ... | @@ -10,6 +10,7 @@ Esta seção apresenta como a gerência do projeto foi feita, como o time está |
|
|
|
- [Matriz de Responsabilidade](#matriz-de-responsabilidade)
|
|
|
|
- [Plano de Comunicação](#plano-de-comunicação)
|
|
|
|
- [Plano de Riscos](#plano-de-riscos)
|
|
|
|
- [Git Workflow](#git-workflow)
|
|
|
|
|
|
|
|
## Organização do Time
|
|
|
|
Nas _sprints_ de desenvolvimento do projeto, o time se organiza em 3 diferentes equipes: A primeira responsável pelas tarefas de _backend_, e a segunda e a terceira equipes sendo responsáveis pelo _frontend_ do aplicativo e do gerenciador web respectivamente. A escolha dos membros que compõem cada uma das equipes varia de sprint para sprint, levando em consideração as dificuldades das _user stories_ atribuídas para cada equipe e o interesse dos membros do time pelas tecnologias e paradigmas que serão utilizados para o desenvolvimento. Isso cria um ambiente mais saudável, onde cada membro possui mais liberdade para a escolha de tarefas e poderá aprender todas as tecnologias utilizadas no projeto.
|
| ... | ... | @@ -83,3 +84,104 @@ Para mitigar os riscos identificados, serão implementadas as seguintes estraté |
|
|
|
- Restrições de recursos: O cronograma e os custos do projeto serão revisados regularmente e os ajustes serão feitos conforme necessário para garantir que os recursos sejam alocados adequadamente.
|
|
|
|
- Problemas de comunicação: canais de comunicação claros serão estabelecidos e atualizações de status regulares serão fornecidas a todas as partes interessadas.
|
|
|
|
- Problemas de integração: o teste de compatibilidade será realizado no início do processo de desenvolvimento, e a comunicação e a colaboração dos membros da equipe serão incentivadas.
|
|
|
|
|
|
|
|
|
|
|
|
## Git Workflow
|
|
|
|
|
|
|
|
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 (Master e DEV).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Branches
|
|
|
|
|
|
|
|
Cada branch relacionada à features será criada a partir da branch dev. Nos tópicos abaixo será explicado as nomenclatura que serão utilizadas para o desenvolvimento.
|
|
|
|
|
|
|
|
#### Nomes
|
|
|
|
|
|
|
|
O nome da branch será em inglês e deve seguir o padrão **feature/nome-da-feature**, onde os nomes das features podem ser encontrados no [Trello](https://trello.com/b/nGQNLhKU/meu-mundo-azul-ages). Quando for necessário fazer alguma correção, o prefixo utilizado deverá ser **fix/nome-da-feature**.
|
|
|
|
|
|
|
|
#### 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 criar a Branch, para isso, execute o seguinte comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
git checkout -b <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Commits
|
|
|
|
|
|
|
|
Após criar a sua branch de desenvolvimento, faça as alterações necessárias no código e commite as mudanças:
|
|
|
|
|
|
|
|
Para adicionar as mudanças é possível utilizar dois comandos:
|
|
|
|
|
|
|
|
O comando `git add .` , faz com que todas as alterações que foram feitas localmente sejam commitadas no repositório remoto.
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
git add .
|
|
|
|
```
|
|
|
|
|
|
|
|
O comando `git add <nomeDoArquivo>` , faz com que apenas as alterações do arquivo informado seja commitado no repositório remoto.
|
|
|
|
|
|
|
|
```
|
|
|
|
git add <nomeDoArquivo>
|
|
|
|
```
|
|
|
|
Após adicionar as alterações é necessário commitar elas usando o comando `git commit-m"comentario-do-commit"`
|
|
|
|
|
|
|
|
```
|
|
|
|
git commit-m"comentario-do-commit"
|
|
|
|
```
|
|
|
|
|
|
|
|
O comentário deve descrever o que foi alterado no código e deverá ser em inglês.
|
|
|
|
|
|
|
|
Após, se for o primeiro commit dessa branch:
|
|
|
|
|
|
|
|
```
|
|
|
|
git push --set-upstream origin nome-da-branch
|
|
|
|
```
|
|
|
|
|
|
|
|
Caso contrário utilize:
|
|
|
|
|
|
|
|
```
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
|
|
|
|
**Importante**: Sempre envie seus commits para o repositório remoto após realizar o seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.
|
|
|
|
|
|
|
|
### Merge Requests
|
|
|
|
|
|
|
|
Depois da sua issue 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 dev.
|
|
|
|
|
|
|
|
Antes de abrir a MR certifique-se que, não irá ocorrer conflitos da sua branch com a `development`, para isso, siga os seguintes passos:
|
|
|
|
|
|
|
|
```
|
|
|
|
git checkout development
|
|
|
|
git pull
|
|
|
|
git checkout <nome-da-branch>
|
|
|
|
git merge development
|
|
|
|
```
|
|
|
|
Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab:
|
|
|
|
|
|
|
|
`git push`
|
|
|
|
|
|
|
|
|
|
|
|
#### 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 development);
|
|
|
|
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**, marcar o responsável pela tarefa.
|
|
|
|
8. Na seção **Reviwers**, marcar os AGES 3 (Arthur, Martin e Sofia). |
