05 ‐ CI
A Integração Contínua (CI) é uma prática essencial no desenvolvimento de software, especialmente no contexto do desenvolvimento ágil, onde múltiplos desenvolvedores integram frequentemente suas alterações de código em um repositório compartilhado, geralmente várias vezes ao dia. O principal objetivo da CI é detectar erros rapidamente, melhorar a qualidade do software e permitir que a equipe entregue software funcional e atualizado em intervalos mais curtos. No projeto, a CI é implementada utilizando o GitHub Actions, garantindo que cada alteração no código seja automaticamente verificada, testada e preparada para o deploy de maneira eficiente e consistente.
- Automatizar tarefas repetitivas: tarefas que ocorrem com frequência (como testes e deploys) são automatizadas, economizando tempo e reduzindo a possibilidade de erro humano.
- Assegurar a qualidade do código: os workflows de testes ajudam a identificar problemas rapidamente, garantindo que apenas código funcional seja adicionado ao repositório principal.
- Reduzir o tempo de entrega: com automação de deploy, conseguimos reduzir o tempo entre desenvolvimento e lançamento, facilitando atualizações rápidas e frequentes.
- Facilitar a colaboração em equipe: os workflows oferecem uma estrutura padronizada, permitindo que todos os membros da equipe trabalhem de maneira integrada e com menos fricções.
Logo, o processo de Integração Contínua (CI) para o projeto tem como objetivo primordial, assegurar qualidade, consistência e integridade. Portanto, foi utilizado o GitHub Actions para configurar diferentes pipelines abrangendo as etapas essenciais, sendo elas: a instalação de dependências, verificação de padrões de código (linting), build do sistema e rastreabilidade de requisitos.
A seguir será explanado o fluxo de desenvolvimento esperado, a partir do mesmo e da sua implementação será possível aplicar e moldar as etapas do processo de CI.
| Fluxo Inicialㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ |
|---|
| Etapa | Responsáveis |
|---|---|
| Levantamento de requisitos | P.O em conjunto com o parceiro |
| Definição do backlog do produto, user story e tasks | P.O e Scrum Master |
| Definição das tecnologias, validação das dependências utilizadas e preferencias do cliente | P.O e Equipe |
| Construção de um ambiente de testes para validação | Equipe de teste |
| Estruturação dos testes, escrita e definição da aceitação dos mesmos | Equipe de teste |
| Planejamento das entregas por meio da elaboração do MVP | P.O |
| Validação com a equipe | Equipe |
| Validação dos artefatos com o parceiro | P.O e parceiro |
| Separação das tasks por sprint | Scrum Master |
| Distribuição de prioridades, grau de dificuldade e ordenação de responsáveis pela task | Scrum Master e Equipe |
| Desenvolver requisitos | Equipe |
| Fluxo de Desenvolvimentoㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ |
|---|
| Etapa | Responsáveis |
|---|---|
| Configuração do ambiente de versionamento | Equipe |
| Abertura de uma task no Github Projects | P.O e Scrum Master |
| Atribuição da task | Desenvolvedor |
| Abertura de uma branch para desenvolvimento da task | Desenvolvedor |
| Instalação de dependências do projeto incluindo o husky | Desenvolvedor |
| Desenvolvimento da task | Desenvolvedor |
| Abertura do pull-request | Desenvolvedor |
| Validação e review do que foi desenvolvido com o DoD da task | Desenvolvedor |
| Execução dos testes unitários e testes de qualidade | CI ou Desenvolvedor |
| Merge para branch develop, caso esteja validado e tenha passado pelos testes | Desenvolvedor |
| Fechamento da branch utilizada para o desenvolvimento da task | Desenvolvedor |
| Conclusão do card da task | Desenvolvedor |
| Abertura do pull-request da branch develop -> main | Desenvolvedor |
| Execução dos testes de integração | CI ou Desenvolvedor |
| Merge para main, caso esteja validado os testes de integração | Desenvolvedor |
| Build e deploy do novo código que chegou na main | CI |
Com esse fluxo, é possível detalhar quais as principais etapas que precisam ser automatizadas:
| Pipeline | Descrição | Quando | Por que? |
|---|---|---|---|
| Testes unitários | Estes testes são executados para validar a uma unidade de código, com o intuito de validar funções/métodos | Ao abrir um pull-request com destino para a branch develop (branch de homologação), assim que aberto o pull-request. Ele rodará a pipeline validando não só o teste unitário da task atual, mas todos os testes unitários anteriores | Com a garantia de que todas as funções e unidades funcionam, fica faltando apenas uma etapa que será testar a funcionalidade dessa unidades/métodos como um módulo, conversando entre si. |
| Teste de qualidade | Estes testes são executados para validar a saúde do código, verificar identações, tipagens, funções sem retorno e etc. | Executados também quando o pull-request é aberto com destino a develop | Com estes testes de qualidade, garantimos que será mais entendível o código |
| Teste integração | Estes testes são para garantir a funcionalidade dos módulos que foram desenvolvidos e sua integração | Estes testes são executados manualmente pelo testador assim que ele for fazer a validação de quaisquer task | Como os testes de unidade funcionando, falta apenas garantir o funcionamento em conjunto dos mesmos, usando da integração. |
| Build do projeto | Checagem da configuração do projeto | Sempre que um código chega na main | É uma etapa importante, pois garante que as configurações estão ok, e que não haverá problemas ao rodar o projeto no seu deploy |
| Deploy | Envio do código em sua ultima versão de produção já passado pela homologação e assegurado pelas validações | Sempre que um código novo chega na branch main | Para automatizar e garantir a versão atualizada do código, com as funcionalidades implementadas |
name: Lint and Unit Tests
on:
pull_request:
branches:
- develop
jobs:
lint-and-test:
runs-on: ubuntu-24.04
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '20'
- name: Install dependencies
run: npm install --prefix tupan --legacy-peer-deps
- name: Run linting
run: npm run lint --prefix tupan
- name: Run Jest tests
run: npm test --prefix tupanname: Integration Tests
on:
workflow_dispatch:
jobs:
integration-tests:
runs-on: ubuntu-24.04
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '20'
- name: Install dependencies
run: npm install --prefix tupan --legacy-peer-deps
- name: Run integration tests
run: npm run test:integration --prefix tupanname: Build and Deploy
on:
pull_request:
branches:
- main
jobs:
build-and-deploy:
runs-on: ubuntu-24.04
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '20'
- name: Install dependencies
run: npm install --prefix tupan --legacy-peer-deps
- name: Run build
run: npm run build --prefix tupan
- name: Set permissions for private key
run: |
echo "${{ secrets.KEYAWS }}" > key.pem
chmod 600 key.pem
- name: Create target directory on AWS instance
run: |
ssh -o StrictHostKeyChecking=no -i key.pem ubuntu@${{ secrets.EC2_IP }} 'mkdir -p /home/ubuntu/tupan/'
- name: Transfer code to AWS instance
run: |
scp -o StrictHostKeyChecking=no -i key.pem -r ./tupan/ ubuntu@${{ secrets.EC2_IP }}:/home/ubuntu/tupan
- name: Create .env file
run: |
echo "BACKEND_URL=${{ secrets.EC2_IP }}:${{ secrets.BACKEND_PORT }}/" >> tupan/.env
- name: SSH into AWS and build Docker image
run: |
ssh -o StrictHostKeyChecking=no -i key.pem ubuntu@${{ secrets.EC2_IP }} 'cd /home/ubuntu/tupan/tupan && sudo docker build -t tupan-front .'
- name: Stop running container
run: |
ssh -o StrictHostKeyChecking=no -i key.pem ubuntu@${{ secrets.EC2_IP }} 'sudo docker stop tupan-front || true'
ssh -o StrictHostKeyChecking=no -i key.pem ubuntu@${{ secrets.EC2_IP }} 'sudo docker rm tupan-front || true'
- name: Run new container
run: |
ssh -o StrictHostKeyChecking=no -i key.pem ubuntu@${{ secrets.EC2_IP }} 'sudo docker run -d --restart always --name tupan-front -p 80:3000 tupan-front'
- name: Cleanup SSH key
run: |
rm -f key.pem