Projeto em desenvolvimento, fruto de uma parceria entre o IFPB (Campus Esperança) e a APAE.
Este projeto tem como objetivo o desenvolvimento de dois sistemas para a APAE, o primeiro focado no gerenciamento de pacientes e o outros na exibição de informações. O projeto está sendo desenvolvido em colaboração com o IFPB (Campus Esperança).
O projeto foi automatizado para rodar com o mínimo de comandos utilizando pnpm Workspaces:
-
Terminal na pasta raiz:
cd APAE1.1. Caso esteja no Windows, acessar terminal via GitBash
-
Setup Inicial:
pnpm install -
Rodar Tudo (Docker + Back + Front):
pnpm dev
ℹ️ Algumas funcionalidades, como envio de e-mails, utilizam configuração opcional de variáveis de ambiente. Veja a seção Configuração do Projeto.
pnpm dev:backend: Executa apenas o backend (api).pnpm dev:apae: Executa apenas o frontend (apae).pnpm docker:up: Sobe apenas o banco de dados e MinIO.pnpm docker:down: Para os containers e os remove da memória.pnpm docker:drop: Para os containers, os remove e apaga os volumes associados.pnpm db:seed: Cria um usuário admin e views em mock no banco de dados para fins de testes.
- Email:
[email protected] - CPF:
123.456.789-00 - Senha:
123456
ℹ️ É necessário criar o usuário teste a partir do comando
pnpm db:seed.
Ao fazer um commit, siga o seguinte padrão:
<tipo>[escopo]: <descrição>
<Corpo Opcional>
Exemplo:
feat[service]: adiciona login de usuário
Observações: Adicione o corpo do commit somente quando necessário para fornecer um contexto adicional para a alteração. Para adicionar uma quebra de linha na mensagem do commit pelo terminal, use "\n".
- feat: Adição de uma nova funcionalidade ou recurso no projeto.
- fix: Correção de um bug ou problema.
- chore: Pequenas alterações de manutenção e ajustes.
- refactor: Refatoração de código sem adicionar novas funcionalidades ou corrigir bugs.
- style: Alterações na formatação do código, lint e outros (não afeta a funcionalidade).
- docs: Mudanças na documentação (exemplo: README).
- test: Modificações ou adição de testes.
- perf: Melhoria de desempenho.
- ci: Alterações relacionadas a CI/CD (GitHub Actions, Jenkins, etc.).
- build: Mudanças relacionadas a build e dependências.
- revert: Reversão de um commit anterior.
- cleanup: Remoção de códigos comentados ou trechos desnecessários.
- remove: Exclusão de arquivos ou funcionalidades obsoletas.
Backend:
- auth: Relacionado à autenticação.
- database: Mudanças no banco de dados.
- api: Mudanças na API.
- service: Alterações na camada de serviços.
- repository: Mudanças na camada de repositório.
- security: Melhorias na segurança.
- cache: Implementação ou alterações no cache.
Frontend:
- ui: Alterações na interface do usuário.
- componentes: Modificações em componentes reutilizáveis.
- layout: Alterações no layout geral.
- styles: Ajustes de CSS, Tailwind, etc.
- state: Alterações no gerenciamento de estado.
- router: Alterações nas rotas da aplicação.
- form: Alterações em formulários.
Mobile:
- android: Alterações específicas para Android.
- ios: Alterações específicas para iOS.
- navigation: Ajustes na navegação do app.
- notifications: Implementação ou correção de notificações push.
- permissions: Mudanças no gerenciamento de permissões.
DevOps:
- ci: Alterações em CI/CD.
- docker: Ajustes em Docker e Docker Compose.
- k8s: Configuração de Kubernetes.
- terraform: Infraestrutura como código com Terraform.
Testes:
- integration: Testes de integração.
- e2e: Testes de ponta a ponta (End-to-End).
Ao criar uma branch, siga a estrutura abaixo:
<número da issue>-<descrição>
Exemplo:
9999-corrige-bug-tela12x
As labels são usadas para categorizar e organizar as issues de acordo com seu tipo e prioridade. Elas são divididas em diferentes grupos:
- mobile – Issues relacionadas ao sistema mobile.
- web – Issues relacionadas ao sistema web (blog).
- back-end – Issues relacionadas ao desenvolvimento back-end.
- front-end – Issues relacionadas ao desenvolvimento front-end.
- database – Issues relacionadas ao banco de dados (modelagem, otimizações, migrations, etc.).
- qa – Issues relacionadas a testes de qualidade (quality assurance).
- feature – Para novas funcionalidades.
- bug – Para correções de erros.
- hotfix – Correções urgentes diretamente na produção.
- release – Preparação para lançar uma nova versão.
- chore – Tarefas gerais de manutenção, ajustes de infraestrutura, etc.
- enhancement – Melhoria de funcionalidades existentes.
- documentation – Relacionado à documentação.
- blocked – Issue bloqueada por algum motivo.
- high – Para issues de alta prioridade.
- low – Para issues de baixa prioridade.
O Kanban é usado para organizar as issues no processo de desenvolvimento. As issues são movidas entre as seguintes raias:
- Backlog: Issues que estão sendo especificadas e preparadas para desenvolvimento.
- Disponível para Desenvolvimento: Issues prontas para os desenvolvedores pegarem e começarem a trabalhar.
- Em Processo: Issues que estão sendo trabalhadas pelos desenvolvedores.
- Review: Issues concluídas e aguardando revisão antes de avançar.
- Represado: Issues que estão bloqueadas ou dependendo de outras tarefas para avançar.
- Aguardando PR: Issues concluídas, aguardando revisão e aprovação via Pull Request (PR).
- Homologação: Issues em testes no ambiente de homologação.
- Disponível para Deploy: Issues prontas para produção, após revisão e testes.
Este projeto automatiza a configuração inicial das variáveis de ambiente.
Ao rodar pnpm dev, o script verifica a existência do arquivo .env.
Caso ele não exista, uma cópia será criada automaticamente a partir do .env.example.
Nota: O script nunca sobrescreverá um arquivo .env já existente.
Caso precise resetar as configurações, delete o .env manualmente, faça as modificações necessárias no .env.example e execute o comando novamente.
O projeto utiliza variáveis de ambiente para configurar serviços externos, como envio de e-mails (SMTP), banco de dados e integrações.
Importante: A configuração dessas variáveis é opcional durante o desenvolvimento.
O sistema funciona normalmente sem elas, porém funcionalidades como envio de e-mails não serão executadas.
- Copie o arquivo de exemplo:
cp .env.example .env- Preencha:
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=[email protected]
MAIL_PASSWORD=sua_senha_de_app
APP_FRONTEND_RESET_PASSWORD_URL=http://localhost:3000/apae-geral/auth/reset-password- Agora pode seguir com a execução normal do projeto, indo para seção Como Executar
- Sem configuração: sistema funciona normalmente, mas não envia e-mails
- Com configuração: envio de e-mails ativo
Adicionar no .gitignore:
.env- Cada dev pode ter seu próprio
.env - SMTP é opcional
- Apenas necessário para testar envio de e-mails
