Home

1.1 - Boas-vindas à documentação do projeto!

Fala dev! Este manual foi produzido para ser um meio de comunicação entre o Syntax Squad e você, desenvolvedor(a) que está lendo este documento. Primeiramente, estamos felizes que tenha se interessado pelo nosso projeto!

O principal objetivo deste documento é assegurar o entendimento completo do sistema e oferecer um guia claro para o desenvolvimento. Dito isso, abordaremos uma série de tópicos que vão te ajudar a navegar pelo projeto com facilidade e implementar novas funcionalidades sem dores de cabeça. Vamos lá!

1.2 - Finalidade deste documento

Este documento tem como finalidade:

• Fornecer uma visão geral dos padrões e práticas adotados pela equipe de desenvolvimento.
• Descrever a configuração do ambiente de desenvolvimento e os pré-requisitos necessários.
• Documentar o modelo de banco de dados, suas tabelas e relacionamentos.
• Explicar os workflows de integração contínua e deploy automatizado.
• Definir o processo de deploy para produção e ambientes de homologação.
• Detalhar os testes e estratégias de qualidade que garantem a confiabilidade do sistema.

1.3 - Tópicos que serão abordados a seguir

1.3.1. Padrões de Desenvolvimento da Equipe

1.3.2. Configurações de Ambiente

1.3.3. Banco de Dados

O sistema utiliza o PostgreSQL como SGBD. Abaixo estão as principais tabelas e seus relacionamentos:

• Tabelas:
  • usuario: Armazena os dados dos usuários do sistema.
  • estacao: Representa as estações monitoradas.
  • endereco: Armazena as informações de localização da estação.
  • tipo_parametro: Tabela dedicada a armazenar informações referentes a cada parâmetro que será assosiado a estação.
  • categoria: Registra as categorias de parâmetros. Ex.: Temperatura ºC, Vento Km/h, etc.
  • medicao: Guarda as medições de parâmetros feitos nas estações.
  • estacao_parametro: Tabela intermediária entre estacao e tipo_parametro responsável em relacionar essas partes do sistema.
  • alerta: Configurações de alertas baseados em medições, separados por estação e parâmetro.
  • historico_alerta: Registra as ocorrências de medições que satisfazem as condições definidas em alerta.

Para uma descrição detalhada do modelo de dados, consulte a seção de Banco de Dados.

1.3.4. Workflows

Utilizamos GitHub Actions para realizar a integração contínua (CI) e deploy contínuo (CD).

1.3.5. Deploy

Para o deploy utilizaremos a AWS com:

• Docker para contêinerização
• Instâncias EC2 para rodar os contêineres
• ECS para criar o cluster de contêineres e e configurações de escalonamento
• ECR para armazenar as imagens Docker
• Load Balancer para distribuir o tráfego entre as instâncias
• RDS para o banco Postgres
• ElastiCache para o banco Redis
• Github Actions para buildar as imagens e atualizar as instâncias com a nova imagem sempre que for feito push na main

1.3.6. Testes

Adotamos uma estratégia robusta de testes para garantir a qualidade do software. Nossos testes incluem:

• Testes Unitários: Garantem que cada componente individual funcione como esperado. Deve ser desenvolvido por cada desenvolvedor ao término de cada task e antes de ser aberto o Pull request
• Testes de Integração: Verificam se os diferentes módulos funcionam juntos corretamente. Deve ser escrito por um testador responsável pelo processo de testes do software.
• Execução Automática: Os testes são automaticamente executados em cada push e pull_request.