Skip to content

GitLab

Open
Created by Lucas Ramon Schnorrenberger@lucas.schnorrenbergerOwner
Report abuse

feat: Configura pipeline de CI/CD e infraestrutura Serverless na AWS

  • bem formatadinho com o GPT para facilitar a leitura

🚀 Configuração Completa de Infraestrutura como Código e Pipeline CI/CD na AWS

Este Merge Request introduz a configuração completa da infraestrutura como código e da pipeline de CI/CD para o deploy automatizado do backend (aiprodutor-backend) na AWS.

O objetivo é automatizar todo o processo, desde o push no GitLab até a publicação de uma nova versão da aplicação, que agora roda em um ambiente serverless.

🏗️ 1. Arquitetura Serverless na AWS

A aplicação foi totalmente adaptada para rodar em um ambiente escalável e seguro:

  • AWS Lambda: A aplicação agora é executada em um container dentro do Lambda.
  • Amazon ECR: Configurado para armazenar de forma privada as imagens Docker da aplicação.
  • Amazon API Gateway: Responsável por expor a aplicação de forma segura via endpoint REST.
  • Amazon RDS (PostgreSQL): Banco de dados configurado e gerenciado pela AWS.
  • AWS Secrets Manager: Armazena de forma segura as credenciais do banco de dados.
  • Security Groups e IAM Roles: Criadas permissões de rede e acesso entre os serviços para garantir comunicação segura.

⚙️ 2. Ajustes na Aplicação para Compatibilidade com a Nuvem

Foram realizadas diversas modificações para preparar a aplicação Nest.js para o ambiente AWS Lambda:

  • Dockerfile: Novo arquivo criado para empacotar a aplicação em uma imagem otimizada.
  • src/lambda.ts: Novo entrypoint que adapta o ciclo de vida do Nest.js ao Lambda.
  • package.json / package-lock.json: Adicionadas dependências para integração serverless.
  • nest-cli.json / tsconfig.json: Ajustados para incluir os arquivos necessários no build.
  • entrypoint.sh: Lógica de migração movida para a pipeline de CI/CD.
  • app.controller.ts: Adicionada rota /health para monitoramento e status da API.

🔄 3. Fluxos da Pipeline (CI/CD)

A pipeline foi projetada para lidar com três cenários principais, garantindo qualidade, rastreabilidade e automação contínua.

🧩 3.1. Abertura de um Merge Request para developer

  • Gatilho: Quando um desenvolvedor abre ou atualiza um MR a partir de uma branch feature/... para developer.
  • Objetivo: Garantir que o novo código não quebre a aplicação antes da integração.
  • Ações executadas:
    • npm run test e npm run lint: Executa automaticamente os testes e ESLint.

💾 3.2. Merge da Branch para developer

  • Gatilho: Após o Merge Request ser aprovado e mesclado na branch developer.
  • Objetivo: Manter um backup atualizado do código de desenvolvimento no GitHub.
  • Ações executadas:
    • sync_to_github: Executa um push forçado (git push --force) para o repositório espelho no GitHub.

☁️ 3.3. Merge da developer na main (Deploy em Produção)

  • Gatilho: Quando a branch developer é mesclada na main.
  • Objetivo: Realizar o deploy automatizado da nova versão na AWS.
  • Ações executadas:
    • migrate_database: Aplica novas migrações Prisma no RDS.
    • seed_database (manual): Etapa opcional para popular o banco.
    • build_and_push_to_ecr: Constrói a imagem Docker e publica no Amazon ECR — a função Lambda atualiza automaticamente.
    • sync_to_github: Backup final do código de produção no GitHub.

✅ Resultado Esperado

Com esta implementação, o fluxo completo — desde o desenvolvimento até o deploy — é automatizado, rastreável e seguro, garantindo entregas mais rápidas, consistentes e com menor risco operacional.