Tema • Desafio • Requisitos • Planejamento • Sprints • Tecnologias • Metodologia • Backlog • Equipe
Aplicação Web com BD Relacional (possivelmente pipeline de preparação de dados)
Temos um desafio de sincronização dos dados administrativos, financeiros e operacionais referentes aos serviços prestados pela empresa. A falta de organização dos dados acarreta lentidão para atender chamados, e confusão na interpretação dos indicadores comerciais e financeiros.
Pré-requisitos:
Requisitos Funcionais
- Cadastros de Usuários, Equipamentos e Horários
- Usuários devem ter perfis diferentes (administrador, suporte, cliente)
- Registro de chamados
- Acompanhamento de chamados de ponta a ponta
- Front-End para entrada e interpretação de dados.
Requisitos Não Funcionais
- Linguagem Java Web Server-Side (Requisito Exigido Fatec)
- PL / SQL (Requisito Exigido Fatec)
- GIT (Requisito Exigido Fatec)
- Vue.js ou Flutter (FrontEnd).
🔗 Clique no link abaixo para visualizar o Kanban de atividades da equipe:
-
Kickoff - 15/08/2022 a 19/08/2022
-
SPRINT 1 - 29/08/2022 a 18/09/2022
-
SPRINT 2 - 19/09/2022 a 09/10/2022
-
SPRINT 3 - 13/10/2022 a 06/11/2022
-
SPRINT 4 - 07/11/2022 a 27/11/2022
-
Feira de Soluções - 08/12/2022 às 19h
🔖 SPRINT 1 (Link da Pasta): Concluído ☑️
🔖 SPRINT 2 (Link da Pasta): Concluído ☑️
🔖 SPRINT 3 (Link da Pasta): Concluído ☑️
🔖 SPRINT 4 (Link da Pasta): Concluído ☑️
- Banco de Dados: Oracle Cloud (Requisito Desejável Fatec)
- Back-end: Java e Spring Boot
- Front-end: HTML, JavaScript (Vue.js), CSS, Bootstrap
- Ferramentas: IntelliJ IDEA, Visual Studio Code, GitHub e Figma
- Metodologia Ágil: Framework Scrum
Pré requisitos para rodar o serviço localmente:
- Docker installed (https://docs.docker.com/get-docker/) – Guia de como instalar o docker.
Utilizando docker podemos subir o serviço utilizando linha de comando ou o docker desktop, nosso serviço tem duas imagens dockers que devem ser subidos em containers separados, de acordo com a recomendação da ferramenta.
“Don't make monolithic containers.”
Portanto vamos trabalhar nessa ideia. Para cada sprint temos uma versão de front-end e uma versão de back-end, para utilização completa do serviço, devemos obrigatoriamente utilizar os dois microservices, com as versões corretas.
Na imagem acima vemos quais versões atualmente temos, em ambos os serviços temos lançado até o momento 3 versões, se o desejado é utilizar a versão 2.0.0, por exemplo, ambos os serviços devem ser utilizados na versão 2.0.0, tanto do front-end quanto do back-end.
Fazer pull das images:
docker pull apidocdocker/<service-name>:<tagname>
Subir o Container:
docker run -p <image-port>:<local-port> <service-name>:<tag-name>
Exemplo: Fazer pull e rodar o container do back-end
docker pull apidocdocker/subter-backend:4.0.0
docker run -p 8080:8080 apidocdocker/subter-backend:4.0.0
A aplicação do backend por padrão, dentro do container, roda na porta 8080, quando colocamos "-p 8080:8080" estamos dizendo que queremos que o que esteja rodando na porta 8080 do container reflita para a porta 8080 local, ou qualquer porta desejada.
O mesmo é feito para o front-end, a porta padrão da aplicação é 4200, o que significa que teríamos que utilizar o "-p 4200:4200" ou a porta desejada.
Este projeto está sob a licença MIT - veja o arquivo LICENSE.md para mais detalhes
🔗 Para visualizar a apresentação da Sprint 4 clique aqui