|
|
No processo de deploy descrito no diagrama, o **backend** (APIs) e o **banco de dados** (PostgreSQL) são configurados em _containers_ Docker executados em uma instância EC2. As imagens Docker desses serviços são buildadas a partir dos repositórios GitLab (`revforce-api` e `revforce-front`) por meio de um **GitLab Runner** também em container. Após cada build de backend, a EC2 puxa a imagem mais recente do **Amazon ECR** e inicia o container das APIs, garantindo que a versão em produção esteja sempre atualizada. Para o **frontend**, o fluxo de deploy faz com que, a cada push no repositório `revforce-front`, o GitLab Runner gere os arquivos estáticos e transfira tudo para um bucket **Amazon S3**, permitindo que o site seja servido diretamente de um storage estático. Esse conjunto de serviços automatiza completamente o ciclo de CI/CD: do commit no GitLab até a aplicação em produção, contemplando banco, APIs e front-end.
|
|
No processo de deploy descrito no diagrama, o **backend** (APIs) e o **banco de dados** (PostgreSQL) são configurados em _containers_ Docker executados em uma instância EC2. As imagens Docker desses serviços são buildadas a partir dos repositórios GitLab (`revforce-api` e `revforce-front`) por meio de um **GitLab Runner** também em container. Após cada build de backend, a EC2 puxa a imagem mais recente do **Amazon ECR** e inicia o container das APIs, garantindo que a versão em produção esteja sempre atualizada. Para o **frontend**, o fluxo de deploy faz com que, a cada push no repositório `revforce-front`, o GitLab Runner gere os arquivos estáticos e transfira tudo para um bucket **Amazon S3**, permitindo que o site seja servido diretamente de um storage estático. Esse conjunto de serviços automatiza completamente o ciclo de CI/CD: do commit no GitLab até a aplicação em produção, contemplando banco, APIs e front-end.
|
