Skip to content

GitLab

Processo · Changes

Page history
feat: add full project documentation layout and structure for Pró-Mata Wiki until AGES' end authored by Saccilotto's avatar Saccilotto
Show whitespace changes
Inline Side-by-side
Processo.md
View page @ 181e3600
| [Home](Home) | [**Escopo**](Escopo) | [Processo](Processo) | [Sprints](Sprints) | [Design](Design) | [Arquitetura](Arquitetura) | [Repositórios](Repositórios) | [Banco de Dados](Banco de Dados) |
| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: |
\ No newline at end of file
# Processo
| [Home](Home) | [Escopo](Escopo) | [**Processo**](Processo) | [Sprints](Sprints) | [Design](Design) | [Arquitetura](Arquitetura) | [Repositorios](Repositorios) | [Gerencia](Gerencia) | [Banco de Dados](Banco-de-Dados) |
| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------: | :--------------------------: | :------------------------: | :---------------: | :--------------: |
## Processo de Desenvolvimento
> Última atualização: 19 de Outubro 2025
## Metodologia
O projeto Pró-Mata utiliza **Scrum adaptado ao contexto acadêmico** com sprints de **~3 semanas** (variando conforme calendário acadêmico da PUCRS).
## Cerimônias Scrum
### Sprint Planning
- **Quando**: Início de cada sprint
- **Duração**: 2h
- **Horário**: 17:30
- **Participantes**: Toda a equipe (AGES I-IV)
- **Responsável**: AGES IV
**Agenda:**
1. Revisão do backlog
2. Seleção de user stories para a sprint
3. Estimativas e capacity planning
4. Definição de critérios de aceitação
5. Divisão de tarefas entre AGES I/II
### Daily Standup
- **Quando**: 2ª-feira, 4ª-feira e Sábado
- **Duração**: ~10min
- **Horário**: 17:40 (2ª/4ª presencial após aula)
- **Participantes**: Equipe de desenvolvimento
- **Responsável**: AGES IV
**3 Perguntas:**
1. O que fiz desde a última daily?
2. O que farei até a próxima?
3. Há impedimentos?
**Observações:**
- Dailys presenciais ocorrem em aulas (2ª e 4ª-feira)
- Dailys de sábado via Discord por texto (organizadas via eventos Discord em canal específico)
- Não são diárias como em Scrum tradicional (adaptação ao calendário acadêmico)
### Sprint Review
- **Quando**: Fim de cada sprint
- **Duração**: 1h
- **Horário**: 17:30
- **Participantes**: Toda equipe + Stakeholder (Prof. Augusto Mussi Alvim)
- **Responsável**: AGES IV
**Agenda:**
1. Demo das funcionalidades implementadas
2. Feedback do stakeholder
3. Validação dos critérios de aceitação
4. Discussão de próximos passos
### Sprint Retrospective
- **Quando**: Após Sprint Review
- **Duração**: 1h
- **Participantes**: Toda a equipe (AGES I-IV)
- **Responsável**: AGES IV
**Formato:**
- O que funcionou bem?
- O que pode melhorar?
- Ações de melhoria para próxima sprint
- Documentação de aprendizados
### Code Review Meeting
- **Quando**: Sexta-feira pré-entrega
- **Duração**: 1-1.5h
- **Participantes**: AGES I, II e III
- **Responsável**: AGES III
**Propósito:**
- Revisão final de PRs críticos
- Validação de padrões de código
- Preparação para deploy
## Workflow de Desenvolvimento
### 1. Planejamento (AGES IV)
- Refinamento de backlog
- Priorização de user stories
- Preparação de Sprint Planning
### 2. Análise de Requisitos (AGES II)
- Detalhamento de user stories
- Validação de regras de negócio
- Modelagem de dados (se necessário)
### 3. Desenvolvimento (AGES I)
```mermaid
graph LR
A[Criar Branch] --> B[Desenvolver]
B --> C[Commits Semânticos]
C --> D[Testes Locais]
D --> E[Push]
E --> F[Abrir PR]
F --> G[Code Review]
G --> H{CI Passou?}
H -->|Sim| I[Merge]
H -->|Não| B
I --> J[Deploy Automático]
```
**Passos Detalhados:**
1. **Criar branch** a partir de `develop`:
```bash
git checkout develop
git pull origin develop
git checkout -b feature/42-login-jwt
```
2. **Desenvolver** seguindo padrões:
- TypeScript strict mode
- Validação com Zod
- Testes unitários (Vitest/Jest)
- ESLint + Prettier
3. **Commits semânticos** (Conventional Commits):
```bash
git commit -m "feat: adiciona autenticação JWT no backend"
git commit -m "fix: corrige validação de datas em reservas"
git commit -m "docs: atualiza README com instruções de setup"
```
4. **Push** para GitHub:
```bash
git push origin feature/42-login-jwt
```
5. **Abrir Pull Request** para `develop`:
- Título claro e descritivo
- Descrição do que foi implementado
- Link para issue relacionada (se houver)
- Screenshots (se UI)
### 4. Code Review (AGES III + AGES IV)
**Checklist do Revisor:**
- [ ] Código limpo e legível
- [ ] Testes adequados (cobertura mantida/aumentada ≥70%)
- [ ] Documentação necessária (README, JSDoc para funções complexas)
- [ ] Segue padrões do projeto (ESLint, Prettier)
- [ ] Tratamento de erros adequado
- [ ] Validações de entrada (Zod)
- [ ] Concordância com critérios de aceitação
- [ ] Documentação Swagger atualizada (endpoints de API)
- [ ] Acessibilidade verificada (frontend)
**SLA**: PRs abertos até 2 dias antes da entrega serão revisados a tempo.
**Aprovações Necessárias**: Mínimo 2 (AGES III/IV)
### 5. CI/CD (AGES III)
**Pipeline de CI** (GitHub Actions):
- **Trigger**: Push em qualquer branch, PR para `develop` ou `main`
- **Jobs**:
- Lint (ESLint + Prettier)
- Test (Jest/Vitest - unit + integration)
- Build (Compilação TypeScript)
- **Requisito**: Pipeline deve passar (green) para merge
**Pipeline de CD**:
- **Trigger**: Merge em `main`
- **Deploy**:
- Frontend → AWS S3 static hosting
- Backend → AWS EC2 (Docker containers)
- Publicação imagens → Docker Hub
### 6. Sincronização (Automática)
- **GitHub → GitLab**: Código, branches, commits, tags
- **GitHub Issues → GitLab Issues**: Sincronização simplificada
- **Frequência**: A cada push/issue criada
## Estrutura de Branches
```plain
main (produção)
↑
develop (integração)
↑
feature/[id]-[descricao]
```
**Convenções:**
- `feature/[numero-issue]-[descricao-curta]`
- Exemplo: `feature/42-login-jwt`
**Não usamos**: `hotfix/*` (ajustes vão na próxima sprint)
## Gestão de Issues
### Criação de Issues (GitHub)
**Template:**
```markdown
## Descrição
[Descrição clara do que precisa ser feito]
## Critérios de Aceitação
- [ ] Critério 1
- [ ] Critério 2
- [ ] Critério 3
## Tarefas Técnicas
- [ ] Tarefa 1
- [ ] Tarefa 2
## Notas Adicionais
[Contexto relevante, links, referências]
```
**Labels:**
- `bug`: Correção de erro
- `feature`: Nova funcionalidade
- `enhancement`: Melhoria de funcionalidade existente
- `documentation`: Documentação
- `test`: Testes
- `frontend`: Frontend (React)
- `backend`: Backend (NestJS)
- `database`: Banco de dados
- `infrastructure`: Infraestrutura/deploy
- `priority:high/medium/low`: Prioridade
### Kanban Board (GitHub Projects)
**Colunas:**
```plain
Backlog → To Do → In Progress → Review → Done
```
**Regras:**
- Apenas 1 issue por pessoa em "In Progress" (WIP limit)
- Issue só vai para "Done" quando PR está merged
- Revisão semanal do backlog (durante Planning)
## Definition of Done (DoD)
Uma tarefa só está **DONE** quando:
- [ ] Código implementado e funcional
- [ ] Testes unitários/integração escritos e passando
- [ ] Cobertura de testes mantida ou aumentada (≥70%)
- [ ] Code review aprovado (mínimo 2 aprovações)
- [ ] CI pipeline passando (green)
- [ ] Documentação Swagger atualizada (endpoints de API)
- [ ] Acessibilidade verificada (frontend - WCAG 2.1 AA quando aplicável)
- [ ] Merge realizado em `develop`
- [ ] Issue/PR fechada no GitHub
- [ ] Sincronização confirmada no GitLab (mirror)
## Padrões de Código
### TypeScript
- Strict mode habilitado
- Evitar `any` (usar `unknown` quando necessário)
- Interfaces para tipos complexos
- JSDoc para funções públicas complexas
### Validação
- Todas as entradas validadas com Zod
- DTOs tipados com `createZodDto`
- Mensagens de erro claras e consistentes
### Testes
- Nomear testes claramente: `describe('Component/Function', () => { it('should...') })`
- Arrange-Act-Assert pattern
- Mocks para dependências externas
- Cobertura ≥70% (linhas/funções), ≥60% (branches)
### Commits
- Conventional Commits obrigatório
- Mensagens em inglês
- Imperativo: "add", "fix", "update" (não "added", "fixed")
- Referência a issues: `feat: adiciona login JWT (#42)`
## Comunicação
### Canais
| Canal | Uso | Frequência |
|-------|-----|------------|
| **GitHub Issues/PR** | Comunicação técnica assíncrona | Contínua |
| **Discord** | Chat rápido, dúvidas, dailys sábado | Diária |
| **WhatsApp** | Avisos urgentes | Ocasional |
| **Email** | Comunicação formal stakeholder/orientador | Ocasional |
| **GitLab Wiki** | Documentação centralizada | Contínua |
### Reuniões Recorrentes
| Evento | Freq | Dia | Hora | Duração |
|--------|------|-----|------|---------|
| Daily (Presencial) | 2x semana | 2ª, 4ª | 17:40 | 10min |
| Daily (Discord) | Semanal | Sáb | Variável | 15min |
| Sprint Planning | A cada 3 semanas | 2ª | 17:30 | 2h |
| Sprint Review | A cada 3 semanas | 2ª | 17:30 | 1h |
| Retrospectiva | A cada 3 semanas | Após Review | - | 1h |
| Code Review Meeting | Semanal | 6ª (pré-entrega) | A definir | 1-1.5h |
## Métricas e Monitoramento
### Métricas de Sprint
- **Velocity**: Story points completados por sprint
- **Burndown**: Progresso diário da sprint
- **Lead Time**: Tempo de "To Do" → "Done" (meta: ≤7 dias)
### Métricas de Qualidade
- **Cobertura de Testes**: ≥70% linhas/funções, ≥60% branches
- **Taxa de Aprovação Code Review**: ≥90% PRs aprovados na 1ª revisão
- **Tempo de Code Review**: ≤2 dias úteis
### Métricas de Deploy
- **Frequência de Deploy**: 1-2 deploys por sprint
- **Taxa de Sucesso Deploy**: ≥95% sem rollback
- **MTTR**: ≤4h (infraestrutura backup disponível)
## Gestão de Riscos
Ver [Gerencia](Gerencia#riscos-e-mitigacoes) para matriz completa de riscos e plano de respostas.
**Principais Riscos do Processo:**
| Risco | Mitigação |
|-------|-----------|
| Indisponibilidade membros (provas) | Calendário acadêmico compartilhado, tarefas distribuídas |
| Atraso entregas | Monitoramento daily, sprints de 3 semanas permitem ajustes |
| Concentração conhecimento | Documentação detalhada, code review, pareamento |
## Ferramentas
### Desenvolvimento
- **IDE**: VSCode (recomendado)
- **Versionamento**: Git + GitHub (desenvolvimento) + GitLab (oficial)
- **Board**: GitHub Projects (Kanban privado)
- **CI/CD**: GitHub Actions
- **Testes**: Vitest (frontend), Jest (backend), Playwright (E2E)
### Comunicação da Equipe
- **Chat**: Discord (canal Pro-Mata)
- **Reuniões**: Discord Voice + Presencial
- **Documentação**: GitLab Wiki (Markdown)
### Infraestrutura
- **Hospedagem**: AWS (S3 + EC2)
- **Containers**: Docker + Docker Hub
- **Monitoramento**: Umami Analytics
## Referências
- **Metodologia Completa**: [Gerencia](Gerencia#metodologia-scrum)
- **Git Flow**: [Gerencia](Gerencia#git-flow-e-processos)
- **Stack Tecnológico**: [Arquitetura](Arquitetura)
- **Convenções Código**: [Gerencia](Gerencia#convencoes-e-padroes)
- **Sprints Detalhadas**: [Sprints](Sprints)
---
**Última Revisão**: 19 de Outubro 2025
**Responsável**: AGES IV (Gerenciamento de Projeto)