Skip to content

GitLab

arquitetura · Changes

Page history
revisão e atualizaçao do gitflow authored by Eduardo Andre Soares's avatar Eduardo Andre Soares
Show whitespace changes
Inline Side-by-side
arquitetura.md
View page @ 19422241
......@@ -126,24 +126,24 @@ Nas sessões abaixo será ensinado a instalação Git em sua máquina de acordo
#### Download
Faça o download e instale o Git a partir deste link, selecionando seu sistema operacional: [aqui](https://git-scm.com/downloads).
Faça o download e instale o Git a partir deste [link](https://git-scm.com/downloads), selecionando seu sistema operacional.
Ao final da instalação, abra o Git Bash (caso esteja usando Windows) ou um terminal e digite `git –version`. Ao retornar a versão do Git, significa que a instalação foi bem sucedida.
Ao final da instalação, abra o Git Bash (caso esteja usando Windows) ou um terminal, e digite `git –version`. Ao retornar a versão do Git, significa que a instalação foi bem sucedida.
> Usuários de Linux e Mac já possuem o Git nativamente. Para verificar, abra um terminal e digite `git –version`. Caso retorne a versão do Git, significa que o mesmo está devidamente instalado em sua máquina.
> **Nota:** Usuários de Linux e Mac já possuem o Git nativamente. Para verificar, abra um terminal e digite `git –version`. Caso retorne a versão do Git, significa que o mesmo está devidamente instalado em sua máquina.
**Configuração Git e GitLab**
### Configuração Git e GitLab
Abaixo será ensinado algumas configurações iniciais do Git, bem como o vínculo do seu ambiente local com o GitLab via SSH.
**Configurações Iniciais**
#### Configurações Iniciais**
Caso esteja utilizando o Git pela primeira vez, rode os comandos abaixo para configurar, respectivamente, seu nome e seu email. Substitua os valores entre aspas pelos seus dados.
- git config --global user.name "${YOUR_FULL_NAME}"
- git config --global user.email "${YOUR_EMAIL}"
**Configurando uma chave SSH**
<!-- **Configurando uma chave SSH**
**Passo 1: Gerando a chave SSH**
......@@ -170,48 +170,47 @@ Entre na sua conta do GitLab e navegue em Preferences > SSH Keys;
Cole o conteúdo copiado do arquivo id_rsa.pub e atribua um título a chave;
Clique em Add Key para salvá-la.
**Nota**: Não é obrigatório atribuir uma data de expiração para a chave.
**Nota**: Não é obrigatório atribuir uma data de expiração para a chave. -->
### Git Branching Model
Utilizaremos o [modelo de gestão de branches tradicional](https://nvie.com/posts/a-successful-git-branching-model/), realizando algumas adaptações. As alterações que faremos são:
Utilizaremos o [modelo de gestão de branches tradicional](https://nvie.com/posts/a-successful-git-branching-model/), realizando algumas adaptações baseadas no Trunked Based Development. As alterações que faremos são:
- Não utilização de branches no modelo `hotfix/*`, visto que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente;
- Não utilizaremos branches de `hotfix/*`, visto que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente;
- Integração da branch de `release/*` com a branch de `develop/*`, com o propósito de unificar suas funcionalidades;
- Substituição da branch de `feature` por um modelo voltado a tarefa, reduzindo seu ciclo de vida e seu número de commits. Esta branch será deletada após o merge.
O desenvolvimento nos repositórios _frontend_ e _backend_ **deverá** seguir o fluxo descrito abaixo:
* 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/t01-login` ou `feature/t05-dropdown-list-login`);
* quando uma feature é finalizada, um PR da branch `feature/` relacionada é aberto com destino à branch `develop`.
- 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. Esta sempre será a branch mais atualizada;
*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/t01-login` ou `feature/t05-dropdown-list-login`);
- Quando uma feature é finalizada, um PR da branch `feature/` relacionada é aberto com destino à branch `develop`.
O código da `develop` é integrado com a `master` ao final da sprint, após validação dos stakeholders do que foi desenvolvido.
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`);
1. criar uma branch para a task com o ID da task (`feature/tXX-YYYYY`);
1. "enviar" a branch para o remoto (`git push -u origin feature/tXX-YYYYY`);
1. desenvolver, commitar mudanças e atualizar o remoto (`push`);
1. voltar para o item **4** até finalizar a task;
1. abrir um PR com destino à branch `develop`;
1. mover o card da task no Trello para a lista *Code Review* e avisar no Discord (canal #code-review) que a task está pronta para review;
1. fim! :smile_cat:
1. Antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch `develop` e pegar as últimas atualizações (`pull`);
1. Criar uma branch para a task com o ID da task (`feature/tXX-YYYYY`);
1. "Enviar" a branch para o remoto (`git push -u origin feature/tXX-YYYYY`);
1. Desenvolver, commitar mudanças e atualizar o remoto (`push`);
1. Voltar para o item **4** até finalizar a task;
1. Abrir um PR com destino à branch `develop`;
1. Mover o card da task no Trello para a lista _Code Review_ e avisar no Discord (canal #code-review) que a task está pronta para review;
### Padrões de Commit
Quando realizar um commit, tente manter o seguinte padrão nas mensagens:
* título: número da task e breve descrição da mudança;
* se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
* se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).
- Título: número da task e breve descrição da mudança.;
- Se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
- Se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).
Exemplo:
Exemplo de mensagem de commit e descrição:
```
#01: Tela de login
#01: Desenvolvimento da tela de login
Criada tela de login e definida rotas, a construção do componente de seleção do perfil não faz parte dessa task.
......@@ -220,18 +219,62 @@ Co-authored-by: Marcos Silva <[email protected]>
### Code Review
Após o desenvolvimento de uma task, um *pull/merge request* (PR) deve ser aberto com destino à branch *develop* do repositório relativo à task: *app* ou *api*. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.
Após o desenvolvimento de uma task, um _pull/merge request_ (PR) deve ser aberto com destino à branch _develop_ do repositório relativo à task. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.
Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até dois dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).
Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:
### Hands On
Esta seção é dedicada ao teste da configuração do seu ambiente, bem como a prática do Gitflow do projeto. O _hands on_ consiste em atualizar o README do repositório da Wiki com o seu nome e seu nível AGES, além de, ao final, submeter seu primeiro Pull Request.
#### Passo 1: Clonar o repositório da Wiki
Efetue o clone do repositorio da Wiki via HTTPS e abra o projeto com um editor de texto. Link: https://tools.ages.pucrs.br/ficai-4.0/ficai-4.0-wiki
#### Passo 2: Criando uma branch nova
A partir da branch main, crie uma nova branch seguindo o comando abaixo:
```sh
git checkout -b seuPrimeiroNome-handson
```
#### Passo 3: Editando o README.md
Abra o arquivo README.md e atualize a tabela de membros com seu nome e seu nível AGES.
#### Passo 4: Commit em suas mudanças
Efetue o commit das suas mudanças rodando os comandos abaixo
```sh
git add .
git commit -m “Add my name to the table”
```
#### Passo 5: Submetendo um pull request
Após efetuar o commit, rode o comando abaixo para enviar suas modificações para o repositório remoto:
```sh
git push origin seuPrimeiroNome-handson
```
> **Nota:** Provavelmente, ao efetuar o push, o GitLab irá requisitar suas credenciais.
Após efetuar, vá no painel do GitLab, procure pelo repositório Ficai-4.0 Wiki e, no menu lateral procure por Merge Request. Na opção “Select source branch” selecione a branch que você criou e clique em “Compare branches and continue”.
Dentro do merge request, mantenha as informações padrão, porém, na opção Reviewer, marque um dos AGES III para fazer a revisão. Após isso, clique em “Create merge request” e aguarde a aprovação.
Com este fluxo completo e bem sucedido, significa que seu ambiente está devidamente configurado para utilizar os repositórios do FICAI 4.0.
* *app*:
<!-- Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:
* *api*:
- _app_:
- _api_:
Essas regras foram adicionadas como template de PR em cada projeto.
Essas regras foram adicionadas como template de PR em cada projeto. -->
## Arquitetura Geral da Aplicação
......