|
|
descrição |
|
|
\ No newline at end of file |
|
|
| [Home](home) | [**Escopo**](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Gerência](gerencia) | [Código](codigo) | [BD](Banco de Dados) | [Qualidade](qualidade) | [Frontend](frontend) | [Backend](backend) | [Analytics](analytics)
|
|
|
| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :---------------: | :--------------------: | ------------: |
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
Esta seção da documentação visa apresentar os padrões arquiteturais gerais do projeto, bem como a infraestrutura adotada.
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
- [Arquitetura E2E](#Arquitetura-E2E)
|
|
|
- [Arquitetura de Infraestrutura](#Arquitetura-de-Infraestrutura)
|
|
|
|
|
|
## Arquitetura E2E
|
|
|
Esta subseção visa apresentar o padrão arquitetural front-back adotado.
|
|
|
#### Diagrama em alto nível da arquitetura:
|
|
|

|
|
|
|
|
|
A arquitetura utilizada no projeto é a _Model-View-Controller_, que permite a separação entre as responsabilidades de uma aplicação em três camadas principais que serão responsáveis por organizar o código entre modelos, lógica de negócios e interfaces de forma separada.
|
|
|
|
|
|
#### Models
|
|
|
As _Models_ representam a camada de dados da aplicação, representando a lógica de negócios, acesso aos dados além de sua validação e manipulação. Uma de suas responsabilidades é gerenciar o comportamento dos dados e atualizar o banco de dados com as informações mais recentes ou alteradas.
|
|
|
|
|
|
#### Views
|
|
|
A camada de _Views_ é responsável por exibir os dados ao usuário final. Ela representa a interfaces do projeto, recebendo as interações do usuário e retornando respostas de acordo com o planejamento das interações.
|
|
|
|
|
|
#### Controller
|
|
|
A camada de _Controllers_ age como um intermediário entre as camadas de _Models_ e _Views_, recebendo as interações do usuário e enviando para a fonte de dados ou solicitando dados ao modelo para que eles possam ser exibidos em tela.
|
|
|
|
|
|
No projeto Globo Aplausos, o usuário acessa o Frontend via plataforma web (_Views_) que contém componentes reutilizáveis e que se comunicam com as _Controllers_ do Backend para buscar ou atualizar os dados presentes nos modelos (_Models_) inseridos no banco de dados.
|
|
|
|
|
|
## Arquitetura de Infraestrutura
|
|
|
Esta subseção visa apresentar o padrão arquitetural de infraestrutura adotado.
|
|
|
#### Diagrama em alto nível da arquitetura:
|
|
|

|
|
|
|
|
|
|
|
|
#### Instâncias utilizadas:
|
|
|
- **AWS EC2.** É um serviço de computação em nuvem escalável sob demanda. Esta instância será utilizada para hospedar os containers Docker do Backend, Banco de dados, Cypress e demais Runners do GitLab (CI/CD).
|
|
|
|
|
|
- **AWS ECR.** É um serviço de registro de contêineres que oferece hospedagem para implantar imagens e artefatos de aplicações. Esta instância será utilizada para armazenar as imagens Docker do projeto.
|
|
|
|
|
|
- **AWS S3.** É um serviço de armazenamento de objetos. No projeto Globo Aplausos, a S3 será utilizada para armazenar as imagens de usuários e produtos que podem ser cadastrados pelo administrador.
|
|
|
|
|
|
#### Vercel
|
|
|
|
|
|
Vercel é uma plataforma de hospedagem e automação para o desenvolvimento de plataformas web, com foco na entrega contínua de projetos realizados em estruturas de Next.js. No caso do Globo Aplausos, o Vercel é utilizado como ambiente de produção do `Frontend`, que é atualizado a cada sprint com as alterações enviadas à branch principal do projeto.
|
|
|
|
|
|
|
|
|
#### Fluxo de Deploy
|
|
|
Nesta seção será apresentado o fluxo de deploy da aplicação do projeto Globo Aplausos.
|
|
|

|
|
|
|
|
|
Observando a imagem acima, quando uma mudança nova é realizada e adicionada à branch _main_ do `Frontend` ou `Backend` o pipeline realiza os `jobs` específicos para realização do deploy da aplicação. No `Frontend`, o pipeline realiza o deploy para o Vercel, a partir da conexão realizada entre o repositório e a cloud, utilizando as configurações estabelecidas no ambiente e no arquivo `.vercel`. Para o Backend, o processo de deploy segue o mesmo padrão inicial, porém, em vez de mandar as mudanças para o Vercel, o runner do GitLab constrói uma imagem do Backend utilizando a `CLI` da ECR, envia a imagem para AWS que então é utilizada para gerar um novo container do Backend da aplicação. |
|
|
\ No newline at end of file |