Compare commits

..

5 Commits

Author SHA1 Message Date
Andrés Eduardo García Márquez 6f60b9eef0 chore: add .playwright to gitignore
CI/CD Pipeline / deploy (push) Successful in 1m15s Details
CI/CD Pipeline / smoke-tests (push) Failing after 44s Details
CI/CD Pipeline / e2e-tests (push) Has been skipped Details
CI/CD Pipeline / rollback (push) Has been skipped Details
Ignore Playwright local browser cache directory.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-09 14:13:11 -05:00
Andrés Eduardo García Márquez 3271380fbd chore(docs): remove obsolete RECOMMENDATIONS.md
Remove outdated recommendations file no longer relevant to project.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-09 14:13:03 -05:00
Andrés Eduardo García Márquez 32d3c67bb0 docs: correct SQL Server version to 2017
Update prerequisite from SQL Server 2022 to 2017 to match
actual deployment configuration.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-09 14:12:55 -05:00
Andrés Eduardo García Márquez 876f8eb4d1 docs: add bug correction process documentation
Document the bug lifecycle from detection through deployment,
including roles (QA, PO, Tech Lead, Dev, DevOps) and checklists.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-09 14:12:47 -05:00
Andrés Eduardo García Márquez 73a193d8ac refactor(docs): move DEV-GUIDE.md to docs folder
Consolidate documentation by moving DEV-GUIDE.md from root to docs/.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-09 14:12:38 -05:00
5 changed files with 229 additions and 185 deletions

1
.gitignore vendored
View File

@ -143,3 +143,4 @@ data/
*.bak
*.backup
.playwright-mcp/
.playwright/

View File

@ -6,7 +6,7 @@
|------------|----------------|
| .NET SDK | 10.0 |
| Node.js | 22.x |
| SQL Server | 2022 |
| SQL Server | 2017 |
| Docker | 24.x |
| Docker Compose | 2.x |

View File

@ -0,0 +1,227 @@
# Proceso de Corrección de Bugs en Fábrica de Software
## Flujo General
```
QA detecta → PO prioriza → Tech Lead analiza → Dev corrige → QA valida → DevOps despliega → QA cierra
```
---
## 1. QA / Tester
| Actividad | Entregable |
|-----------|------------|
| Detectar y reproducir el bug | Pasos de reproducción |
| Documentar evidencia | Screenshots, logs, ambiente |
| Registrar en sistema de tracking | Ticket con severidad y prioridad |
| Clasificar impacto | Crítico / Alto / Medio / Bajo |
### Plantilla de Ticket
```
ID: BUG-XXX
Título: [Descripción breve del bug]
Severidad: [Crítica | Alta | Media | Baja]
Ambiente: [Desarrollo | QA | Staging | Producción]
Pasos para reproducir:
1. [Paso 1]
2. [Paso 2]
3. [Paso 3]
Resultado esperado:
[Descripción del comportamiento correcto]
Resultado actual:
[Descripción del comportamiento incorrecto]
Evidencia:
[Screenshots, logs, videos]
Componente afectado:
[Módulo / Servicio / Endpoint]
```
---
## 2. Product Owner / Analista
| Actividad | Entregable |
|-----------|------------|
| Validar impacto en negocio | Usuarios afectados |
| Priorizar en backlog | Posición en sprint |
| Definir criterios de aceptación | AC claros y verificables |
| Aprobar solución propuesta | Sign-off |
### Criterios de Priorización
| Severidad | Tiempo de Respuesta | Ejemplos |
|-----------|---------------------|----------|
| **Crítica** | Inmediato (< 4h) | Sistema caído, pérdida de datos, seguridad |
| **Alta** | 24-48 horas | Funcionalidad core bloqueada |
| **Media** | Sprint actual | Funcionalidad degradada con workaround |
| **Baja** | Backlog | Cosméticos, mejoras menores |
---
## 3. Tech Lead / Arquitecto
| Actividad | Entregable |
|-----------|------------|
| Análisis de causa raíz | Identificar origen del bug |
| Evaluar impacto técnico | Componentes afectados |
| Definir estrategia de solución | Enfoque técnico |
| Estimar esfuerzo | Story points / horas |
| Asignar a desarrollador | Responsable |
### Técnicas de Análisis de Causa Raíz
1. **5 Whys**: Preguntar "¿por qué?" hasta llegar a la raíz
2. **Diagrama de Ishikawa**: Categorizar causas potenciales
3. **Revisión de logs**: Trazabilidad del error
4. **Debugging**: Reproducir en ambiente controlado
---
## 4. Desarrollador
| Actividad | Entregable |
|-----------|------------|
| Reproducir en ambiente local | Confirmación del bug |
| Implementar corrección | Código + tests |
| Code review | PR aprobado |
| Documentar cambios | Changelog / comentarios |
### Checklist del Desarrollador
- [ ] Bug reproducido localmente
- [ ] Causa raíz identificada
- [ ] Solución implementada
- [ ] Tests unitarios agregados/actualizados
- [ ] Tests de regresión pasan
- [ ] Code review solicitado
- [ ] PR aprobado
- [ ] Documentación actualizada (si aplica)
### Convención de Commits
```
fix(módulo): descripción breve del fix
Descripción detallada del problema y la solución.
Fixes: #TICKET-ID
```
---
## 5. QA (Post-fix)
| Actividad | Entregable |
|-----------|------------|
| Verificar corrección en QA/Staging | Test passed |
| Ejecutar regresión | Sin efectos colaterales |
| Aprobar para producción | Sign-off QA |
### Checklist de Validación
- [ ] Bug original corregido
- [ ] Casos de borde probados
- [ ] Regresión ejecutada
- [ ] Performance no degradada
- [ ] Sin nuevos defectos introducidos
---
## 6. DevOps / SRE
| Actividad | Entregable |
|-----------|------------|
| Desplegar a producción | Release ejecutado |
| Monitorear post-deploy | Métricas estables |
| Rollback si es necesario | Plan B listo |
### Checklist de Despliegue
- [ ] Build exitoso
- [ ] Tests CI/CD pasan
- [ ] Backup realizado (si aplica)
- [ ] Deployment ejecutado
- [ ] Health checks OK
- [ ] Métricas monitoreadas (15 min)
- [ ] Rollback plan documentado
---
## 7. QA (Validación Producción)
| Actividad | Entregable |
|-----------|------------|
| Smoke test en producción | Bug corregido |
| Cerrar ticket | Evidencia adjunta |
| Actualizar documentación | Si aplica |
### Cierre del Ticket
```
Estado: CERRADO
Resolución: Corregido
Versión: [v1.2.3]
Fecha de cierre: [YYYY-MM-DD]
Validado por: [Nombre QA]
Evidencia: [Link a screenshot/video]
```
---
## Métricas de Seguimiento
| Métrica | Descripción | Meta |
|---------|-------------|------|
| **MTTR** | Mean Time To Repair | < 24h (críticos) |
| **Escape Rate** | Bugs que llegan a producción | < 5% |
| **Reopen Rate** | Bugs reabiertos | < 10% |
| **First Time Fix** | Bugs corregidos al primer intento | > 85% |
---
## Ejemplo Práctico
### Bug: URL de activación apunta a localhost en producción
**Ticket:**
```
ID: BUG-001
Título: URL de activación apunta a localhost en producción
Severidad: Media
Ambiente: Producción
Pasos para reproducir:
1. Login como admin en https://academia.ingeniumcodex.com
2. Crear nuevo estudiante
3. Observar la URL de activación generada
Resultado esperado:
https://academia.ingeniumcodex.com/activate?code=XXX
Resultado actual:
http://localhost:4200/activate?code=XXX
```
**Análisis de Causa Raíz:**
- Código usa fallback `localhost:4200` cuando `App:BaseUrl` no está configurado
- Variable de entorno faltante en deployment de producción
**Solución:**
- Agregar `App__BaseUrl` en `deploy/k3s/api.yaml`
- Agregar `APP_BASE_URL` en `deploy/docker/docker-compose.yml`
**Commit:**
```
fix(deploy): add App__BaseUrl env var for activation URLs
```
**Validación:**
- Nueva URL generada: `https://academia.ingeniumcodex.com/activate?code=XXX`
- Ticket cerrado con evidencia

View File

@ -1,184 +0,0 @@
# Recomendaciones Finales
**Fecha:** 2026-01-08
**Proyecto:** Sistema de Inscripción de Estudiantes
**Versión:** 1.0
---
## Resumen del Estado Actual
El sistema cumple con todos los requisitos funcionales de la prueba técnica:
| Requisito | Estado |
|-----------|--------|
| CRUD de estudiantes | ✅ Implementado |
| Programa de créditos (10 materias, 3 créditos c/u) | ✅ Implementado |
| Máximo 3 materias por estudiante | ✅ Implementado |
| 5 profesores con 2 materias c/u | ✅ Implementado |
| Restricción de mismo profesor | ✅ Implementado |
| Ver compañeros de clase (solo nombres) | ✅ Implementado |
| Autenticación y autorización | ✅ Implementado |
| Recuperación de contraseña | ✅ Implementado |
---
## Recomendaciones Técnicas
### 1. Seguridad
#### Alta Prioridad
- **Rate Limiting:** Implementar limitación de solicitudes en endpoints de autenticación para prevenir ataques de fuerza bruta.
- **Refresh Tokens:** Actualmente solo se usa un token JWT. Implementar refresh tokens para mejor seguridad.
- **Logging de Auditoría:** Agregar logs para acciones sensibles (login fallido, cambio de contraseña, etc.).
#### Media Prioridad
- **CORS Restrictivo:** Revisar configuración de CORS para producción (actualmente permite localhost).
- **Helmet Headers:** Agregar headers de seguridad HTTP en producción.
### 2. Rendimiento
#### Alta Prioridad
- **Paginación:** La query `students` debería usar paginación para escalabilidad.
- **DataLoaders:** Ya implementados, pero verificar N+1 queries en GraphQL.
#### Media Prioridad
- **Caché de Apollo:** Optimizar políticas de caché en frontend para reducir llamadas al servidor.
- **Compression:** Habilitar Brotli/gzip en nginx para assets estáticos.
### 3. Calidad de Código
#### Alta Prioridad
- **Tests E2E:** Los tests de Playwright existen pero deben ejecutarse en CI/CD.
- **Cobertura de Tests:** Aumentar cobertura en Domain y Application layers.
#### Media Prioridad
- **Error Handling Centralizado:** Crear interceptor global para manejo de errores GraphQL.
- **Typing Estricto:** Generar tipos TypeScript desde el schema GraphQL automáticamente.
### 4. DevOps
#### Alta Prioridad
- **Health Checks:** Mejorar endpoint `/health` para incluir dependencias externas.
- **Secrets Management:** No hardcodear credenciales en manifiestos de k8s (usar Sealed Secrets o Vault).
#### Media Prioridad
- **Monitoring:** Agregar métricas con Prometheus y dashboards en Grafana.
- **Logging Centralizado:** Configurar stack ELK o Loki para logs.
---
## Mejoras Funcionales Sugeridas
### Corto Plazo (Sprint actual)
1. **Confirmación de Cancelación:** Agregar diálogo de confirmación antes de desinscribir materia.
2. **Notificaciones Push:** Informar a estudiantes cuando un compañero se inscribe en su clase.
3. **Validación de Email:** Agregar validación de formato de email en frontend.
### Mediano Plazo (2-4 sprints)
1. **Horarios:** Agregar horarios a materias para evitar conflictos.
2. **Waitlist:** Implementar lista de espera para materias muy demandadas.
3. **Reportes:** Dashboard administrativo con métricas de inscripciones.
### Largo Plazo (Roadmap)
1. **Multi-tenant:** Soporte para múltiples instituciones.
2. **Integración LMS:** Conectar con sistemas de gestión de aprendizaje.
3. **App Mobile:** Versión móvil nativa con Flutter/React Native.
---
## Arquitectura
### Fortalezas Actuales
- **Clean Architecture:** Separación clara de capas (Domain, Application, Adapters).
- **CQRS:** Comandos y queries bien separados con MediatR.
- **GraphQL:** API flexible con HotChocolate.
- **Angular Signals:** Estado reactivo moderno y eficiente.
### Áreas de Mejora
1. **Event Sourcing:** Considerar para auditoría completa de inscripciones.
2. **SAGA Pattern:** Para operaciones distribuidas (si se escala a microservicios).
3. **API Gateway:** Si se agregan más servicios, usar Kong o Traefik.
---
## Checklist de Producción
### Pre-Deployment
- [ ] Variables de entorno configuradas (no hardcoded)
- [ ] Connection strings seguros
- [ ] JWT secret rotado
- [ ] CORS configurado para dominio de producción
- [ ] SSL/TLS configurado
- [ ] Rate limiting habilitado
- [ ] Logging en nivel apropiado (Warning en prod)
### Post-Deployment
- [ ] Smoke tests ejecutados
- [ ] Monitoreo activo
- [ ] Alertas configuradas
- [ ] Backup de base de datos verificado
- [ ] Runbook de incidentes documentado
---
## Conclusión
El sistema está **listo para demostración** y cumple con todos los requisitos de la prueba técnica. Las recomendaciones anteriores son para un escenario de producción real y escalamiento futuro.
**Puntos destacados:**
- Arquitectura sólida y mantenible
- Reglas de negocio correctamente implementadas en el dominio
- UI moderna y responsiva
- Buena cobertura de casos de uso
**Próximos pasos inmediatos:**
1. ~~Ejecutar pruebas de regresión tras las correcciones de defectos~~ ✅ Completado
2. Preparar ambiente de demostración
3. Documentar proceso de instalación para evaluadores
---
## Actualización 2026-01-08: CI/CD y Deployment
### Implementaciones Realizadas
#### 1. CI/CD con Gitea Actions
- **Pipeline:** `.gitea/workflows/deploy.yaml`
- **Características:**
- Builds paralelos de API y Frontend
- Caché de Docker layers (GitHub Actions cache)
- Deploy automático en push a `main`
- Health check post-deploy
#### 2. Kubernetes (k3s) Deployment
- **Namespace:** `academia`
- **Servicios:** student-api, student-frontend, sqlserver
- **Ingress:** `academia.ingeniumcodex.com` (Traefik)
- **Seguridad:** NetworkPolicy (default-deny + allow rules)
- **TLS:** Configurado con cert-manager
#### 3. Optimizaciones de Deployment
| Optimización | Beneficio |
|--------------|-----------|
| Builds paralelos | Reduce tiempo de CI ~40% |
| Docker layer cache | Builds incrementales más rápidos |
| Artifact upload/download | Evita rebuild en deploy |
| Rolling updates | Zero-downtime deployments |
### Pruebas de Regresión Completadas
- **Total:** 14 pruebas ejecutadas
- **Resultado:** 100% exitosas
- **Defectos verificados:** DEF-001 y DEF-002 corregidos
- **Reporte:** `docs/qa/QA-REPORT-2026-01-08-REGRESSION-TESTS.md`
### URLs de Producción
| Servicio | URL |
|----------|-----|
| Frontend | https://academia.ingeniumcodex.com |
| GraphQL API | https://academia.ingeniumcodex.com/graphql |
| Health Check | https://academia.ingeniumcodex.com/health |
### Repositorio Git
- **URL:** https://devops.ingeniumcodex.com/andresgarcia0313/academia.git
- **CI/CD:** Auto-deploy en push a main