GitLab

git push

Abrindo um Merge Request

Após a realização do desenvolvimento de uma tarefa e ela estiver de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development, então deve-se abrir um Merge Request.

Para criar o Merge Request devem ser seguidos os seguintes passos:

1. Selecionar a branch de origem (branch de desenvolvimento) e branch (branch de development) de destino.

2. Selecionar Compare branch and continues.

3. No campo Title, preencher com um título que descreva a funcionalidade implementada ou bug corrigido e o número da tarefa que está sendo realizada.

4. No campo Description, preencher utilizando o seguinte template:

## Link da Tarefa
[Inserir link da tarefa do Trello]

## Descrição

[Descreva brevemente o propósito e as principais mudanças e adições que foram feitas nesta solicitação de Merge]

## Checklist

- [ ] Não deixou string literais no código.
- [ ] Utilizou as variáveis padronizadas do design system (cor, títulos/fontes).
- [ ] Não deixou código comentado.


## Screenshots (se aplicável)

[Adicione capturas de tela ou imagens relevantes, se necessário.]

4. Na seção Asignee, selecione Assign to me para que você fique registrado como responsável pelo desenvolvimento daquela tarefa.

5. Em Labels adicione o tipo da tarefa que foi realizado.

6. Revise se os arquivos estão corretos e clique em Submit Merge Request.

Revisando o Merge Request

Antes de abrir o Merge Request clicando no botão de "Submit", os campos abaixo também devem ser preenchidos obrigatoriamente para serem revisados:

• Título - <tipo da tarefa (fix ou feat)>/<descrição da tarefa>
• Descrição - descrição da tarefa e/ou das mudanças no código. Caso seja uma alteração no repositório de frontend, colocar também um print dos estados da tela ou do componente desenvolvido.
• Assignee - integrante da equipe responsável pelo desenvolvimento da tarefa.
• Milestone - sprint na qual a tarefa foi realizada.

Após abertura do Merge Request, o MR será revisado por colegas de equipe.

As revisões serão feitas por apenas um AGES 3, assim devendo ele aprovar ou não. Caso o MR não seja aprovado, a pessoa que o revisou deve destacar nos comentários do MR o motivo para não tê-lo aprovado para que assim a pessoa que o desenvolveu possa fazer os ajustes para aprovação. Dessa forma, o feedback é uma ferramenta fundamental de ambos os lados a fim de garantir o cumprimento das funcionalidades a serem adicionadas pelo MR.

Uma vez que a revisão tenha sido concluída e todos os pontos de ajuste apontados tenham sido commitador na Source Branch, realize o merge e envie as alterações à branch develop.

No final de cada Sprint, para gerar uma nova versão do projeto a ser apresentada para o cliente, deve ser aberto um Merge Request para realizar o merge da branch develop na branch master, atualizando o código de produção com os desenvolvimentos realizados durante a sprint.

O merge deve ser feito com a estratégia squash-commits e as branches devem ser excluídas após o merge para a branch de destino.

Práticas de CI/CD

Para automatizar processos e otimizar o ciclo de desenvolvimento do software do projeto, criou-se uma pipeline de integração contínua (CI) e entrega contínua (CD) no projeto de Backend a partir da ferramenta GitLab CI/CD.

A pipeline criada pode ser vista aqui e contém 4 estágios que serão descritos abaixo:

1. Build: executado para qualquer commit realizado em qualquer uma das branches do projeto, realiza a compilação e o build do projeto de Backend.
2. Test: envolve a execução de testes unitários do projeto de Backend, e a análise estática do código com a ferramenta Checkstyle para verificar se os padrões estão sendo seguidos.
   • A execução de testes unitários é feita para qualquer commit realizado em qualquer uma das branches do projeto.
   • A análise de código é executada apenas na ocorrência de: um Merge Request, um commit na branch develop, ou um commit na branch main.
3. Package: envolve o build da imagem Docker do projeto de Backend e o push desta imagem para o repositório ECR da AWS.
   • Ao realizar um commit na branch develop, realiza-se o push de uma imagem com a tag "develop" para o repositório.
   • Ao se criar uma Tag a partir da branch main, realiza-se o push de uma imagem, identificada pelo nome da tag, para o repositório.
4. Deploy: envolve a conexão SSH com a instância EC2 da AWS para realizar o deploy da nova versão do container do projeto de Backend.
   • Ao realizar um commit na branch develop, realiza-se o deploy da imagem "develop" gerada, para o ambiente de staging.
   • Ao se criar uma Tag a partir da branch main, realiza-se o deploy da imagem identificada pelo nome da tag, para o ambiente de produção.

Os dois primeiros estágios estão relacionados ao processo de integração contínua, ou seja, de integrar novas mudanças no código do repositório de Backend. Por outro lado, os dois últimos estágios estão relacionados à entrega contínua, no sentido que automatizam a liberação do código gerado, incluindo a sua implantação no ambiente produtivo.