Product Documentation - iNineBD/Track-5Sem2025Main GitHub Wiki

Product Documentation - Track Project

1. Visão Geral do Produto

Objetivo do Sistema

O Track é uma plataforma de gerenciamento e monitoramento de performance de projetos que oferece visibilidade e insights dinâmicos sobre métricas e indicadores. O sistema integra-se com ferramentas de gestão como Taiga e Jira, permitindo a visualização centralizada de dados como número de cards criados/concluídos, tempo médio de execução, distribuição por colaborador, entre outros indicadores relevantes.

Público-Alvo

  • Administradores: Acesso completo a todos os projetos e métricas
  • Gerentes: Visualização de indicadores da própria equipe e projetos sob sua responsabilidade
  • Operadores: Acesso limitado aos próprios indicadores de performance

Principais Funcionalidades

  • Dashboard interativo com métricas em tempo real
  • Visualização de cards por tag, colaborador e status
  • Análise de tempo médio de execução e retrabalhos
  • Controle de acesso baseado em roles
  • Integração com múltiplas plataformas de gestão

Contexto do Problema

Equipes de desenvolvimento enfrentam dificuldades para:

  • Ter visibilidade clara da performance dos projetos
  • Identificar gargalos e padrões nos processos
  • Tomar decisões baseadas em dados concretos
  • Centralizar informações de diferentes ferramentas de gestão

2. Arquitetura do Sistema

2.1 Componentes Principais

graph TB
    A[Frontend - Vue/Nuxt] --> B[Backend - Golang]
    B --> C[Data Warehouse - PostgreSQL]
    D[ETL - Python] --> C
    E[Taiga API] --> D
    F[Jira API] --> D
    
    subgraph "Deployment"
        H[GitHub Actions CI/CD]
        I[DigitalOcean Droplets]
    end
    
    A --> I
    B --> I
    C --> I
    H --> I

2.2 Tecnologias Utilizadas

2.2.1 Frontend

  • Nuxt 3 - Framework baseado em Vue.js
  • Vue.js - Framework JavaScript progressivo
  • TypeScript - Tipagem estática (opcional)
  • Tailwind CSS - Framework de estilos utility-first
  • Node.js - Runtime JavaScript
  • npm - Gerenciador de pacotes

2.2.2 Backend

  • Go (Golang) - Linguagem de programação principal
  • PostgreSQL - Banco de dados relacional
  • Swagger - Documentação de API
  • GitHub Actions - CI/CD
  • golangci-lint - Linter para Go

2.2.3 ETL (Extract, Transform, Load)

  • Python 3.10+ - Linguagem principal
  • SQLAlchemy - ORM para Python
  • Pandas - Manipulação e análise de dados
  • Requests - Cliente HTTP para Python
  • psycopg2 - Conector PostgreSQL
  • pytest - Framework de testes
  • flake8 - Linter para Python
  • python-dotenv - Variáveis de ambiente

2.2.4 Banco de Dados

  • PostgreSQL - Data Warehouse principal
  • Schema customizável - Organização por ambiente
  • Índices otimizados - Performance em consultas analíticas

2.2.5 DevOps e Deploy

  • Docker - Containerização
  • Docker Compose - Orquestração local
  • GitHub Actions - CI/CD pipeline
  • Git - Controle de versão
  • GitHub - Repositório e colaboração
  • Variáveis de ambiente - Configuração segura
  • Testes automatizados - Cobertura de código
  • Linting - Qualidade de código
  • DigitalOcean - Hospedagem

3. Componentes da Arquitetura

3.1 Frontend (Track-5Sem2025Front)

Características:

  • Interface moderna e responsiva
  • Arquitetura modular baseada em componentes Vue
  • Integração com API REST do back-end
  • Configuração via variáveis de ambiente

Estrutura de Deployment:

  • Servidor de desenvolvimento: localhost:3000
  • Build otimizado para produção
  • Configuração via .env para URL da API

3.2 Backend (Track-5Sem2025Server)

Características:

  • API RESTful com documentação Swagger
  • Arquitetura em camadas (handlers, services, repositories)
  • Conexão com PostgreSQL via drivers nativos
  • Validação de dados e tratamento de erros

Endpoints Principais:

  • Consulta de projetos
  • Estatísticas de cards por tags
  • Estatísticas de cards por usuários
  • Estatísticas de cards por status

Configuração:

  • Variáveis de ambiente para database e email
  • Servidor padrão: localhost:8080
  • Documentação disponível em /swagger/index.html

3.3 ETL (Track-5Sem2025ETL)

Características:

  • Pipeline ETL robusto para extração de dados
  • Integração com APIs Taiga e Jira
  • Transformação de dados para insights analíticos
  • Carregamento otimizado no data warehouse

Processo ETL:

  1. Extract: Coleta dados das APIs Taiga/Jira
  2. Transform: Normalização e enriquecimento dos dados
  3. Load: Inserção no PostgreSQL data warehouse

4. Requisitos Funcionais e Não Funcionais

4.1 Requisitos Funcionais

RF01 - Cards by tag

  • Descrição: The system must display the number of cards per tag registered in the kanban. This information must be presented visually, in a vertical bar graph.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O gráfico deve apresentar todas as tags registradas no kanban.
    • O número de cards por tag deve ser atualizado automaticamente conforme o kanban é alterado.
    • O gráfico deve ser exibido em formato de barra vertical.
    • O usuário deve conseguir visualizar a quantidade ao passar o mouse sobre as barras (tooltip).

RF02 - Cards per employee

  • Descrição: The system should display the number of cards assigned to each employee. This information should be presented visually, in a horizontal bar chart, making it easier to compare workload between team members.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O gráfico deve listar todos os colaboradores com cards atribuídos.
    • O número de cards deve refletir o estado atual do kanban.
    • O gráfico deve ser exibido em formato de barra horizontal.
    • O usuário deve conseguir comparar facilmente a carga de trabalho entre os membros da equipe.

RF03 - Cards by status (Kanban columns)

  • Descrição: The system should display the number of cards by status, based on the Kanban board columns (In Progress, In Review, Completed, etc.). This information should be presented visually, in a donut chart, providing an overview of the distribution of tasks between the different stages of the workflow.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • Todas as colunas do kanban devem estar representadas no gráfico.
    • O gráfico deve ser exibido em formato de donut chart.
    • O sistema deve atualizar o gráfico em tempo real conforme mudanças no status dos cards.
    • O usuário deve poder visualizar os valores percentuais e absolutos ao interagir com o gráfico.

RF04 - Cards created by period

  • Descrição: The system must display the number of cards created in a given period selectable by the user. This information must be presented in a highlighted numeric box format, clearly showing the total number of new cards created in the specified period.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O usuário deve selecionar o intervalo de datas desejado.
    • O número de cards criados nesse período deve ser exibido em destaque.
    • O valor deve ser recalculado imediatamente após a seleção do novo período.

RF05 - Cards completed by period

  • Descrição: The system must display the number of cards completed in a given user-selectable period. This information must be presented in a highlighted numeric box format, clearly showing the total number of cards completed in the specified period.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O usuário deve selecionar o intervalo de datas desejado.
    • O número de cards finalizados nesse período deve ser exibido em destaque.
    • O valor deve ser recalculado automaticamente com base no período selecionado.

RF06 - Average card execution time

  • Descrição: The system should display the average time it takes for cards to be completed. This information should be presented in a table format, containing two columns: one with the name of the card and another with the time it took to complete, allowing a detailed analysis of the efficiency in executing the tasks.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • A tabela deve listar todos os cards concluídos.
    • Cada linha da tabela deve conter o nome do card e o tempo total de execução (data de início até a finalização).
    • O tempo médio geral deve ser calculado e exibido separadamente.
    • O usuário deve poder ordenar a tabela por tempo ou por nome do card.

RF07 - Reworks

  • Descrição: The system should display the number of cards that have been reworked (cards that have returned from the Completed column to In Progress). This information should be presented in a table format, containing two columns: one with the card name and another with the number of times the card has been returned for rework, allowing for the identification of difficulty patterns in specific tasks.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • A tabela deve conter todos os cards que passaram da coluna "Completed" para "In Progress".
    • Cada linha deve exibir o nome do card e o número de vezes que ele foi reaberto.
    • Os dados devem ser atualizados automaticamente conforme ocorrem reaberturas.

RF08 - Access control by levels

  • Descrição: The system must manage the display of indicators and metrics at different access levels (administrator, manager and operator), allowing customization of the display of information according to the profile of the logged-in user and their responsibilities within the team.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O sistema deve reconhecer e aplicar três níveis de acesso: administrador, gerente e operador.
    • Cada nível deve ter permissões específicas para visualização e interação com os indicadores.
    • Usuários devem visualizar apenas os dados que correspondem ao seu nível de acesso.

RF09 - Integration with other systems

  • Descrição: The system must create an API for integration with other systems, such as Jira, allowing the import and export of data between platforms to centralize metrics from different task management tools.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • A API deve permitir importação e exportação de dados com plataformas externas (como Jira).
    • A integração deve seguir um formato padronizado (ex: JSON) e conter autenticação.
    • A documentação da API deve descrever claramente os endpoints usados para integração.

4.2 Requisitos Não Funcionais

RNF01 - API Documentation

  • Descrição: The API must have clear and detailed documentation, containing three main components: process documentation (detailing flows and interactions), product documentation (detailing endpoints, parameters, and responses), and DevOps documentation (detailing configuration, deployment, and maintenance).
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • Deve haver documentação pública e acessível para os endpoints da API.
    • A documentação deve incluir exemplos de requisições e respostas.
    • Os três tipos de documentação (processo, produto e DevOps) devem estar disponíveis em um repositório ou portal.
    • A documentação deve ser atualizada sempre que houver mudanças significativas na API.

RNF02 - Responsiveness

  • Descrição: The system must be responsive and accessible on different devices (Desktop and Mobile), automatically adapting to the screen size of the device used, ensuring a consistent user experience across all platforms.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O sistema deve se adaptar automaticamente a resoluções mobile e desktop.
    • Não deve haver sobreposição de elementos em diferentes tamanhos de tela.
    • Todos os componentes visuais devem estar acessíveis e legíveis em smartphones.
    • Testes em múltiplos navegadores e dispositivos devem ser realizados e aprovados.

RNF03 - User Manual

  • Descrição: The system must have a manual to guide users on how to use the system, including step-by-step tutorials for key features, usage tips and common troubleshooting.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O manual deve estar disponível online (PDF ou página web).
    • Deve conter instruções passo a passo com imagens ilustrativas.
    • Deve ser possível encontrar seções específicas via índice ou busca.
    • O manual deve incluir uma seção de perguntas frequentes e solução de problemas comuns.

RNF04 - Database Modeling

  • Descrição: The system must create an efficient database model (DW - Data Warehouse) to store all project information, allowing quick queries and complex analysis of the data collected from the kanban.
  • Status: ✅ Implementado
  • Critérios de Aceitação:
    • O modelo de dados deve estar documentado com diagrama ER ou estrela/floco de neve.
    • A estrutura deve suportar agregações e filtros complexos sem perda de performance.

5. Fluxos de Uso e Casos de Uso

5.1 Fluxo Principal de Navegação

graph TD
    A[Acesso ao Sistema] --> B{Usuário já registrado?}
    B -->|Não| C[Tela de Primeiro Acesso]
    B -->|Sim| D[Tela de Login]
    C --> E[Inserir Email]
    E --> F[Receber Token por Email]
    F --> G[Criar Senha]
    G --> D
    D --> H[Autenticação]
    H --> I{Credenciais Válidas?}
    I -->|Não| D
    I -->|Sim| J[Dashboard Principal]
    J --> K[Visualizar Métricas]
    J --> L[Aplicar Filtros]
    K --> N[Análise Detalhada]
    L --> K

5.2 Casos de Uso Detalhados

UC01 - Primeiro Acesso

  • Ator Principal: Novo usuário
  • Objetivo: Registrar uma senha de acesso inicial ao sistema
  • Pré-condições:
    • Usuário foi previamente cadastrado por um administrador com um email válido
    • Sistema configurado para envio de email com token
  • Fluxo Principal:
    1. Usuário acessa a tela de primeiro acesso
    2. Informa seu email
    3. Sistema envia um token para o email informado
    4. Usuário acessa o email e copia o token
    5. Usuário acessa a página de definição de senha
    6. Informa o token recebido e define uma senha
    7. Sistema valida o token e salva a senha
    8. Redireciona o usuário para a tela de login
  • Pós-condições:
    • Senha cadastrada com sucesso
    • Usuário pode efetuar login normalmente
  • Fluxos Alternativos:
    • FA001: Email não encontrado - Exibir mensagem de erro
    • FA002: Token expirado ou inválido - Solicitar novo envio
    • FA003: Falha no envio de email - Exibir mensagem e tentar novamente

UC02 - Login no Sistema

  • Ator Principal: Usuário (Administrador, Gerente, Operador)
  • Objetivo: Acessar o sistema Track
  • Pré-condições:
    • Usuário possui credenciais válidas
    • Sistema está disponível
  • Fluxo Principal:
    1. Usuário acessa a página de login
    2. Insere email e senha
    3. Clica em "Entrar"
    4. Sistema valida credenciais
    5. Sistema gera token JWT
    6. Usuário é redirecionado para o dashboard
  • Pós-condições:
    • Usuário autenticado no sistema
    • Token de sessão ativo
  • Fluxos Alternativos:
    • FA001: Credenciais inválidas - Exibir mensagem de erro
    • FA002: Usuário esqueceu a senha - Redirecionamento para recuperação

UC03 - Visualizar Dashboard de Métricas

  • Ator Principal: Usuário autenticado
  • Objetivo: Visualizar indicadores de performance dos projetos
  • Pré-condições:
    • Usuário autenticado
    • Dados sincronizados no sistema
  • Fluxo Principal:
    1. Sistema carrega métricas padrão
    2. Exibe cards com indicadores principais
    3. Gera gráficos de performance
    4. Apresenta distribuições por usuário/status
  • Pós-condições:
    • Dashboard carregado com dados atualizados
    • Métricas visíveis conforme permissões do usuário
  • Fluxos Alternativos:
    • FA001: Sem dados disponíveis - Exibir mensagem informativa
    • FA002: Erro de carregamento - Botão para tentar novamente

UC04 - Aplicar Filtros nos Dados

  • Ator Principal: Usuário autenticado
  • Objetivo: Segmentar dados por critérios específicos
  • Pré-condições:
    • Dashboard carregado
    • Dados disponíveis para filtrar
  • Fluxo Principal:
    1. Usuário seleciona filtros desejados
    2. Define período/data
    3. Escolhe projetos específicos
    4. Seleciona usuários/colaboradores
    5. Aplica filtros
    6. Sistema atualiza visualizações
  • Pós-condições:
    • Dados filtrados conforme critérios
    • Visualizações atualizadas
  • Fluxos Alternativos:
    • FA001: Filtro resulta em dados vazios - Exibir mensagem informativa
    • FA002: Múltiplos filtros - Permitir combinações

UC05 - Sincronização de Dados Externos

  • Ator Principal: Sistema ETL (automatizado)
  • Objetivo: Atualizar dados das APIs externas
  • Pré-condições:
    • Credenciais de API configuradas
    • Conexão com internet disponível
  • Fluxo Principal:
    1. ETL inicia processo de sincronização
    2. Conecta com APIs do Taiga/Jira/Trello
    3. Extrai dados atualizados
    4. Transforma e normaliza informações
    5. Carrega dados no data warehouse
    6. Registra log de sincronização
  • Pós-condições:
    • Dados atualizados no sistema
    • Log de sincronização registrado
  • Fluxos Alternativos:
    • FA001: Erro de conexão - Reagendar tentativa
    • FA002: Dados corrompidos - Pular registro e logar erro

5.3 Jornada do Usuário

5.3.1 Administrador

  1. Login → Dashboard geral
  2. Análise global → Todos os projetos e equipes
  3. Identificação de gargalos → Drill-down em métricas específicas
  4. Tomada de decisão → Exportação de relatórios
  5. Gestão de usuários → Configuração de acessos

5.3.2 Gestor

  1. Login → Dashboard da equipe
  2. Monitoramento da equipe → Métricas específicas do time
  3. Análise individual → Performance por colaborador
  4. Feedback e melhorias → Identificação de oportunidades
  5. Relatórios → Exportação para reuniões

5.3.3 Operador

  1. Login → Dashboard pessoal
  2. Acompanhamento próprio → Métricas individuais
  3. Autoavaliação → Comparação com métricas da equipe
  4. Melhoria contínua → Identificação de pontos de melhoria

6. Manual do Usuário

6.1 Tela de Login

Nesta tela, o usuário deve inserir seu e-mail e senha para acessar a aplicação. Caso seja o primeiro acesso, há uma opção "Primeiro acesso?", que redireciona o usuário para o processo de cadastro.

image

6.2 Tela de Primeiro Acesso

O usuário deve informar um e-mail válido e clicar em "Enviar". Um token de verificação será enviado para o e-mail informado, necessário para criar a senha de acesso.

image

6.3 Tela de Definir Senha

Após receber o token, o usuário deve:

  • Informar o e-mail cadastrado
  • Inserir o token de verificação
  • Criar e confirmar uma senha segura Com os dados corretos, será redirecionado à tela de login para acessar a aplicação com as novas credenciais.

image

6.4 Tela de Dashboards

Após o login, o usuário acessa a tela principal da aplicação. Inicialmente, nenhum dado é exibido. Para visualizar as métricas, é necessário selecionar a plataforma, o projeto e o período desejado.

image

6.5 Seleção de Plataforma

Campo onde o usuário escolhe entre as plataformas disponíveis: Taiga ou Jira. A seleção da plataforma é obrigatória para liberar os campos de seleção de projeto e período.

image

6.6 Seleção de Projeto

Após selecionar a plataforma, o sistema exibe todos os projetos disponíveis associados àquela plataforma. O usuário deve selecionar o projeto que deseja visualizar os dados.

image

6.7 Seleção de Período

Campo para definir o intervalo de tempo das métricas exibidas no dashboard. O usuário pode escolher manualmente ou usar os atalhos de datas rápidas, como:

  • "Últimos 7 dias"
  • "Últimos 14 dias"
  • "Últimos 30 dias"
  • "Últimos 3 meses"
  • "Últimos 6 meses"
  • "Último ano"

image

6.8 Visualização do Dashboard

Após definir todos os filtros (plataforma, projeto e período), o sistema carrega as métricas do projeto em formato de gráficos e indicadores, como:

  • Total de cards criados e finalizados
  • Cards por tag, status e responsável
  • Tempo médio de execução
  • Taxa de retrabalho

image

6.9 Gestão de Roles (Apenas para ADMIN)

Tela exclusiva para usuários com permissão ADMIN. Nela, é possível visualizar todos os usuários cadastrados no sistema e alterar seus papéis (roles).

image

6.10 Edição de Função do Usuário

Campo que permite ao administrador selecionar entre as diferentes funções disponíveis no sistema:

  • ADMIN: Acesso total ao sistema, incluindo gestão de usuários
  • GESTOR: Acesso às funcionalidades de visualização e análise de dados
  • OPERADOR: Acesso limitado às operações básicas da aplicação

image

Ao lado do campo de seleção, há um botão de ajuda com informações detalhadas sobre cada função.

image

6.11 Alternância de Tema (Dark/Light Mode)

Todos os usuários podem escolher entre o modo claro (Light) ou modo escuro (Dark), de acordo com sua preferência visual. A opção está disponível no menu superior da aplicação.

image

7. Wireframes e Design de Interface

Link para Protótipos: Figma - Track Project Design System

8. Dependências Externas

8.1 APIs e Integrações

8.1.1 Taiga API

  • URL Base: https://api.taiga.io/api/v1/
  • Autenticação: Token-based authentication
  • Documentação: Taiga API Docs

8.1.2 Jira API

  • URL Base: https://{instance}.atlassian.net/rest/api/3/
  • Autenticação: API Token + Email
  • Documentação: Jira REST API

8.2 Bibliotecas e Frameworks

8.2.1 Frontend Dependencies

Core Framework
{
  "nuxt": "^3.15.4",
  "vue": "latest",
  "vue-router": "latest"
}
UI e Styling
{
  "@nuxt/ui": "^2.21.0",
  "@nuxt/image": "^1.9.0",
  "v-calendar": "^3.1.2",
  "vue-chartjs": "^5.3.2",
  "chart.js": "^4.4.8"
}
State Management
{
  "@pinia/nuxt": "^0.11.0",
  "pinia": "^3.0.2",
  "pinia-plugin-persistedstate": "^4.2.0"
}
Authentication & HTTP
{
  "nuxt-auth-utils": "^0.5.19",
  "axios": "^1.8.4"
}
Validation & Utilities
{
  "yup": "^1.6.1",
  "zod": "^3.24.2",
  "date-fns": "^2.30.0"
}
Development Dependencies
{
  "@nuxt/eslint": "^1.3.0",
  "@nuxt/eslint-config": "^1.3.0",
  "@nuxt/test-utils": "^3.17.2",
  "@types/node": "^22.14.0",
  "@vitejs/plugin-vue": "^5.2.3",
  "@vitest/coverage-v8": "^3.1.1",
  "@vue/test-utils": "^2.4.6",
  "@vue/typescript-plugin": "^2.2.8",
  "eslint": "^9.23.0",
  "eslint-config-prettier": "^10.1.1",
  "eslint-plugin-prettier": "^5.2.6",
  "happy-dom": "^17.4.4",
  "jsdom": "^26.0.0",
  "playwright-core": "^1.51.1",
  "prettier": "^3.5.3",
  "sonarqube-scanner": "^4.3.0",
  "typescript": "^5.8.2",
  "vitest": "^3.0.9"
}

8.2.2 Backend Dependencies

Core Framework
module inine-track
go 1.23.4

require (
    github.com/gin-gonic/gin v1.10.0
    github.com/gin-contrib/cors v1.7.4
    github.com/swaggo/gin-swagger v1.6.0
    github.com/swaggo/files v1.0.1
    github.com/swaggo/swag v1.16.4
)
Database e ORM
require (
    gorm.io/gorm v1.25.12
    gorm.io/driver/postgres v1.5.11
)
Authentication & Security
require (
    github.com/golang-jwt/jwt v3.2.2+incompatible
    golang.org/x/crypto v0.37.0
)
Configuration & Email
require (
    github.com/joho/godotenv v1.5.1
    gopkg.in/gomail.v2 v2.0.0-20160411212932-81ebce5c23df
)
Testing Dependencies
require (
    bou.ke/monkey v1.0.2 // indirect
    github.com/DATA-DOG/go-sqlmock v1.5.2 // indirect
    github.com/stretchr/testify v1.10.0 // indirect
)

8.2.3 ETL Dependencies

Core Python & Data Processing
pandas==2.2.3
numpy==1.26.4
SQLAlchemy==2.0.41
Database Connectivity
psycopg==3.2.9
psycopg-binary==3.2.9
psycopg2-binary==2.9.10
asyncpg==0.30.0
aiopg==1.5.0a1
aiosqlite==0.21.0
Web Framework & API
fastapi==0.115.12
uvicorn==0.34.2
starlette==0.32.0.post1
Workflow Management
prefect==2.14.6
alembic==1.15.2
Authentication & Validation
pydantic==2.11.4
pydantic-core==2.33.2
pydantic-extra-types==2.10.4
pydantic-settings==2.9.1
Utilities & Tools
requests==2.32.3
python-dateutil==2.9.0.post0
python-dotenv==1.1.0
pytz==2023.3
Development & Testing
pytest==8.3.5
pytest-cov==4.1.0
black==25.1.0
flake8==7.0.0
autopep8==2.0.4
coverage==7.4.4
Integration & External Services
python-taiga==1.3.2
apprise==1.9.3
docker==6.1.3
kubernetes==28.1.0
Data Formats & Processing
beautifulsoup4==4.13.4
PyYAML==6.0.2
Jinja2==3.1.6
croniter==2.0.7

9. Guia de Instalação e Configuração

9.1 Pré-requisitos

  • Node.js 18.x ou superior
  • Go 1.19 ou superior
  • Python 3.10 ou superior
  • PostgreSQL 13 ou superior
  • Git para controle de versão

9.2 Clonando os Repositórios

# Frontend
git clone https://github.com/ininetrack/Track-5Sem2025Front.git
cd Track-5Sem2025Front

# Backend
git clone https://github.com/ininetrack/Track-5Sem2025Server.git
cd Track-5Sem2025Server

# ETL
git clone https://github.com/ininetrack/Track-5Sem2025ETL.git
cd Track-5Sem2025ETL

9.3 Configuração do Frontend

  1. Navegue para o diretório do frontend:

    cd Track-5Sem2025Front

  2. Configure as variáveis de ambiente:

    cp .env.example .env

    No arquivo .env, configure:

    # URL to the API server
API_SERVER=http://localhost:8080

  3. Instale as dependências:

    npm install

  4. Execute o projeto:

    npm run dev

  5. Acesse o frontend:

9.4 Configuração do Backend

  1. Navegue para o diretório do backend:

    cd Track-5Sem2025Server/src

  2. Configure as variáveis de ambiente:

    cp .env.example .env

    No arquivo .env, configure:

    # Credentials Database
DB_USER=seu_usuario_db
DB_PASSWORD=sua_senha_db
DB_HOST=localhost
DB_PORT=5432
DB_NAME=track_database
DB_SCHEMA=public
JWT_SECRET=minha_chave_secreta_jwt

# Email
EMAIL_HOST=smtp.gmail.com
EMAIL_PORT=587
[email protected]
EMAIL_HOST_PASSWORD=sua_senha_app
[email protected]

  3. Instale as dependências:

    go mod tidy

  4. Execute o projeto:

    go run main.go

  5. Acesse a documentação da API:

9.5 Configuração do ETL

  1. Navegue para o diretório do ETL:

    cd Track-5Sem2025ETL

  2. Instale as dependências:

    pip install -r requirements.txt

  3. Execute o ETL:

    python main.py

10. Fluxo de Desenvolvimento

10.1 Estrutura de Branches

  • main: Código em produção
  • sprint-X: Branch base para cada sprint
  • feature/TRK-XX-nome: Novas funcionalidades
  • fix/TRK-XX-nome: Correção de bugs
  • hotfix/TRK-XX-nome: Correções urgentes

10.2 Processo de Desenvolvimento

  1. Criar branch feature a partir da sprint atual
  2. Desenvolver funcionalidade
  3. Executar testes localmente
  4. Commit seguindo padrão definido
  5. Abrir Pull Request
  6. Code review obrigatório
  7. Merge após aprovação e CI verde

10.3 Executando Testes

10.3.1 Testes do Frontend

cd Track-5Sem2025Front

# Executar testes com cobertura
npm run test:coverage

# Visualizar relatório de cobertura
# Windows:
start coverage/lcov-report/index.html

# Linux:
xdg-open coverage/lcov-report/index.html

10.3.2 Testes do Backend

cd Track-5Sem2025Server/src

# Verificar código com linter
golangci-lint run ./...

# Corrigir formatação
go fmt ./...

# Executar testes com cobertura
go test -v -coverprofile=coverage_report/coverage.out -covermode=atomic ./...

# Gerar relatório HTML
go tool cover -html=coverage_report/coverage.out -o coverage_report/coverage.html

# Visualizar relatório de cobertura
# Windows:
start coverage_report/coverage.html

# Linux/macOS:
xdg-open coverage_report/coverage.html

10.3.3 Testes do ETL

cd Track-5Sem2025ETL

# Verificar código com linter
flake8 etl_taiga

# Executar testes com cobertura
pytest --disable-warnings --cov=etl_taiga --cov-report=html:coverage_report --cov-report=xml:coverage_report/coverage.xml

# O relatório será gerado em coverage_report/index.html

Documento mantido pela equipe de desenvolvimento do Track Project Última atualização: 27 de maio de 2025 - 21h40 Versão: 1.2