Central de Erros

Objetivo

Em projetos modernos é cada vez mais comum o uso de arquiteturas baseadas em serviços ou microsserviços. Nestes ambientes complexos, erros podem surgir em diferentes camadas da aplicação (backend, frontend, mobile, desktop) e mesmo em serviços distintos. Desta forma, é muito importante que os desenvolvedores possam centralizar todos os registros de erros em um local, de onde podem monitorar e tomar decisões mais acertadas. Neste projeto vamos implementar um sistema para centralizar registros de erros de aplicações.

A arquitetura do projeto é formada por:

Backend - API

Criar endpoints para serem usados pelo frontend da aplicação criar um endpoint que será usado para gravar os logs de erro em um banco de dados relacional a API deve ser segura, permitindo acesso apenas com um token de autenticação válido

Frontend

deve implementar as funcionalidades apresentadas nos wireframes deve ser acessada adequadamente tanto por navegadores desktop quanto mobile deve consumir a API do produto desenvolvida na forma de uma Single Page Application

Observações

Se a aceleração tiver ênfase no backend (Java, Python, C#, Go, PHP, etc) a equipe deve obrigatoriamente implementar a API. A implementação do frontend é considerado um bônus importante Se a aceleração tiver ênfase em frontend (React, Vue, Angular, etc) a equipe deve obrigatoriamente implementar o frontend da aplicação e o backend pode ser substituido por uma aplicação mock. A implementação da API é considerado um bônus importante

Wireframes

Os wireframes a seguir servem para demonstrar as funcionalidades básicas da aplicação.

Documento Codenation - Central de Erros

Git Guidelines

Todo commit deve ter um comentário que possua o mínimo de informações sobre as modificações feitas, lembre-se de dar um git pull na branch master antes de criar uma nova branch ou dar um git push na master.

Ferramentas

Solução

Classe Log

Devemos criar um pacote utilitário com métodos que retornem s mensagens de log para cada caso de uso: Backend, FrontEnd e Mobile e Desktop, portanto ela deve ter métodos static que implementem a geração de Logs.

A classe de Log pode ser abstract para que as classes que utilizarem o Log implementem os métodos de Log de forma personalizada.

Entidade,
Timestamp,
Descrição,

Lista de Tarefas

Criar a modelagem conceitual do BD;
Criar as entidades em java com base na modelagem feita (André);
Criar Repository(Guilherme) e Service(Eduardo);
Definir as rotas (controller) (Leonardo/Eduardo);
Testar as rotas com Postman(Ariel);
Autenticação e Autorização;
Criar as telas de front-end:
- Cadastro de Usuário;
- Login;
- Consulta de erros;
- (Opcional) Arquivo com erros que irão popular o banco de dados em x minutos;
Deploy (Heroku?)
Testes (Opcional)
Slides da apresentação;

roupa_de_sapo

Squad 1 Aceleradev Java Florianópolis

Fluxo de trabalho

Todas as novas branches devem ser criadas a partir da staging, para isso execute os seguintes comandos no seu terminal:

git checkout staging -> entra na branch staging
git pull origin staging -> atualiza seu repositório local com as modificações da staging
git checkout -b nome_da_sua_branch_de_trabalho -> cria e entra na sua branch de trabalho, (é aqui onde você irá realizar todas as suas modificaçes, irá fazer commits e push).
Ao finalizar seu trabalho em sua branch local você pode fazer o merge dela com a staging.

Merge com staging

Entre em: https://github.com/Guiarrd/roupa_de_sapo/branches.

Na seção Active branches procure a sua branch e aperte no botão New pull request.

Você será redirecionado para uma nova página. Logo abaixo do título Open a pull request tem dois botões de spinner com uma seta <- entre eles. O da direita deve estar selecionado com a sua branch de trabalho e o da esquerda deve estar com a branch staging selecionada, caso não esteja assim selecione estas opções no spinner. Escreva uma mensagem sobre este pull request e aperte no botão Create pull request. Caso sua branch de trabalho possua algum conflito com a staging você não poderá dar o merge automaticamente, mas ainda poderá criar o pull request.

Com o pull request criado caso não haja conflitos aperte no botão de merge na página do pull request criado e fim. Se houver conflitos você precisará resolvê-los localmente.

Resolução de conflitos com IntelliJ

Abra o intelliJ, execute os comandos:

git checkout staging -> entra na branch staging
git pull origin staging -> atualiza seu repositório local com as modificações da staging
git checkout nome_da_sua_branch_de_trabalho -> entra na sua branch de trabalho
No canto inferior direito na barra de navegação click em Git: nome_da_sua_branch, no menu que abrir selecione a branch staging e aperte em Merge into current. Resolva os conflitos que surgirem e faça um push.

Swagger

Nesse projeto foi utilizado o editor Swagger para a validação e documentação da API desenvolvida pelos integrantes da squad. Nesse editor estão descritos todos os endpoints com os métodos que executam e os respectivos parâmetros. Inclui também os modelos do banco de dados utilizado.

Pode ser acessado no endpoint: https://rds-backend.herokuapp.com/swagger-ui.html.

Testando

Para testar com o Swagger você pode utilizar o usuário pré cadastrado. Basta fazer uma requisição POST a rota /login onde o JWT está rodando. Lá devemos passar um JSON com os seguintes dados:

{

fullName: "John",
username: "john@domain.com",
password: 123456 }

Essa requisição terá como resposta um token no formato: {Bearer }. Essa resposta deve ser copiada na opção authorize para que o token seja enviado em qualquer operação da aplicação garantindo o acesso.

amandabacelli/squad-1-ad-java-softplan-1