Processo

Esta página descreve os processos utilizados pelo time ao longo do projeto.

Sumário

• Desenvolvimento
  • Fluxo de trabalho no Git
  • Práticas de CI/CD

Desenvolvimento

Fluxo de trabalho no Git

Como modelo de fluxo de trabalho no Git iremos nos basear no Git Flow, para termos um maior controle sobre as alterações sendo realizadas no projeto, por meio de Merge Requests, e para conseguirmos lidar bem com muitas pessoas realizando alterações em um repositório ao mesmo tempo.

Branches

Neste modelo, cada repositório possui duas branches principais:

• develop - branch utilizada durante o desenvolvimento, onde todas as novas funcionalidades e correções que ainda não foram publicadas no ambiente de produção serão mergeadas.
• master - branch cujo código é utilizado no ambiente de produção (AWS), onde novas versões/releases serão mergeadas quando estiverem prontas para serem publicadas.

Além disso, para realizar alterações no projeto, podem ser criados outros 2 tipos de branch:

• feature branch - branch criada a partir da develop para desenvolvimento de uma nova funcionalidade.
• fix branch - branch criada a partir da develop para desenvolvimento de correções de bugs.

Por padrão, o nome destas duas últimas branches deve iniciar com o tipo de branch (feat ou fix), seguido pelo identificador da User Story presente no Azure DevOps, seguido por fim pelo identificador da Task/Bug presente no Azure DevOps. Por exemplo, no caso da tarefa de criação de rota de login abaixo, o nome da branch deveria ser feat/us02-42.

Passo-a-passo

Quando precisar fazer uma alteração em um dos repositórios do projeto, o primeiro passo será garantir que você está com o seu repositório local atualizado. Para isso, vá até a branch main e atualize o seu respositório local a partir do repositório remoto, utilizando os comandos abaixo:

git checkout main
git pull origin main

Em seguida, crie uma branch de feature ou fix a partir da branch develop:

git checkout develop
git checkout -b <nome-da-nova-branch>

Após a criação envie esta nova branch para o repositório remoto, para que o restante da equipe também consiga visualizar esta branch:

git push --set-upstream origin <nome-da-nova-branch>

Concluídas essas etapas, você pode iniciar o desenvolvimento na nova branch, realizando commits periodicamente para registrar suas alterações no Git e evitar que o código seja perdido em caso de imprevistos.

IMPORTANTE: Certifique sempre que as alterações sendo commitadas são necessárias e não possuem dados sensíveis! Use sua IDE como apoio para visualizar as mudanças feitas

#Adicionar arquivo a staging area para ser registrados no próximo commit
git add <nome-de-arquivo>
#Realizar commit
git commit -m"Mensagem do commit"
#Envie commits para repositório remoto
git push origin <nome-da-nova-branch>

Quando o desenvolvimento na nova branch foi concluído, deve-se então abrir um Merge Request para solicitar que esta branch seja mesclada com a develop. Para isso, acesse a seção "Merge Requests" da página do repositório no GitLab, conforme imagem abaixo:

Nesta seção, selecione a opção "New Merge Request":

Então, clique no botão "Change branches" para selecionar as branches as quais você deseja mesclar. Neste momento, devem ser selecionadas:

• Source branch - sua feature ou fix branch onde foram implementadas as novas alterações
• Target branch - develop

Selecionadas as branches, confira os arquivos sendo alterados em "Compare branches", e então continue.

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 e AGES 4, 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.

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.