Compare commits
No commits in common. "6f60b9eef069e3ad5655753e0079559036ca1142" and "823ad242d2541efa354b9bc8a4564fb09ac12c6a" have entirely different histories.
6f60b9eef0
...
823ad242d2
|
|
@ -143,4 +143,3 @@ data/
|
|||
*.bak
|
||||
*.backup
|
||||
.playwright-mcp/
|
||||
.playwright/
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
|------------|----------------|
|
||||
| .NET SDK | 10.0 |
|
||||
| Node.js | 22.x |
|
||||
| SQL Server | 2017 |
|
||||
| SQL Server | 2022 |
|
||||
| Docker | 24.x |
|
||||
| Docker Compose | 2.x |
|
||||
|
||||
|
|
|
|||
|
|
@ -1,227 +0,0 @@
|
|||
# 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
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
# 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
|
||||
Loading…
Reference in New Issue