Entrega Semana 10 - AndersenCastanedaUniAndes/proyecto-1 GitHub Wiki
Evidencias de avances DevOps
Commits / Pull Request
Flujo de trabajo y estrategia de versionamiento
Flujo de Trabajo GitFlow:
| RAMA | DESCRIPCIÓN | USO |
|---|---|---|
| master | Esta es la rama de producción. Contiene versiones estables, releases y listas para ser lanzadas de la aplicación móvil. | Solo se hace merge en esta rama de las funcionalidades completas después de haber sido probadas y revisadas. Cada commit en esta rama debe corresponder a una nueva versión de la aplicación que se puede liberar al público. Se recomienda proteger esta rama para evitar cambios accidentales. Esto puede incluir requerir revisiones de código antes de realizar merges. |
| develop | Esta rama es la cola de integración y desarrollo. Aquí se integran todas las funcionalidades en desarrollo y se preparan para su lanzamiento en la próxima versión. | Todas las ramas de características (feature/{ID_TAREA}) se mergean en esta rama una vez que están completas y probadas. Se realizan pruebas de integración en esta rama para asegurar que las nuevas funcionalidades funcionan bien juntas. Se debe mantener esta rama actualizada y las características deben ser fusionadas frecuentemente para evitar conflictos. |
| feature/{nombre-del-feature} | Estas son las ramas de características específicas. Cada nueva funcionalidad o tarea se desarrolla en su propia rama, nombrada con el prefijo feature/ seguido de un identificador de tarea. | Una vez que la funcionalidad esté completa, se realiza un pull request (PR) hacia la rama dev para su revisión e integración. Es importante mantener estas ramas actualizadas con dev para evitar conflictos antes de fusionar. |
- master
|___develop
|______featureX
|______featureY
Los features se integran por:
- Feature PR a develop (corre el pipeline del feature): Una vez que el pipeline pasa, se hace review y merge.
- PR de develop a master (corre el pipeline): Una vez que el pipeline pasa, se hace merge.
Como estrategia de versionamiento se usan tags y release
Ejecución de pruebas
Web App
Unit Test
Coverage
Unit Test Productos
Coverage
Unit Test Autenticación
Coverage
Unit Test Inventario
Coverage
--
Avances Cypress
Evidencias cierre de sprint
Enpoint realizados de autenticación
Enpoint realizados de productos
Enpoint realizados para inventario
Parametrización de integración continua / despliegue continuo
Sprint Backlog y asignación por integrante
Evidencias de avance semanal
Calendario
Resumen
Burndown chart
Velocity chart
Release Burndown chart
Code Coverage chart
Value chart
| HU | Puntos de Historia | Valor de Negocio |
|---|---|---|
| MED-138 | 3 | 1 |
| MED-135 | 3 | 1 |
| MED-147 | 8 | 1 |
| MED-140 | 5 | 1 |
| MED-216 | 5 | 1 |
| MED-215 | 5 | 1 |
| MED-136 | 3 | 1 |
| MED-132 | 3 | 1 |
| MED-149 | 13 | 1 |
| MED-148 | 3 | 1 |
| MED-133 | 3 | 1 |
| MED-76 | 3 | 1 |
| MED-150 | 5 | 1 |
| MED-137 | 5 | 1 |
| MED-61 | 3 | 1 |
| MED-65 | 5 | 2 |
| MED-139 | 13 | 1 |
| MED-134 | 5 | 1 |
| MED-60 | 13 | 1 |
| MED-217 | 8 | 2 |
| MED-80 | 3 | 2 |
| MED-198 | 5 | 1 |
| MED-199 | 13 | 1 |
| MED-212 | 8 | 1 |
| MED-197 | 8 | 1 |
| MED-119 | 5 | 1 |
| MED-116 | 5 | 2 |
| MED-220 | 8 | 1 |
| MED-222 | 3 | 1 |
| MED-204 | 3 | 1 |
| MED-219 | 13 | 2 |
| MED-56 | 3 | 1 |
| MED-208 | 8 | 1 |
| MED-202 | 8 | 2 |
| MED-205 | 8 | 1 |
| MED-121 | 3 | 1 |
| MED-122 | 13 | 1 |
| MED-130 | 3 | 1 |
| MED-129 | 13 | 1 |
| MED-123 | 3 | 2 |
| MED-126 | 8 | 1 |
| MED-118 | 8 | 1 |
| MED-86 | 5 | 1 |
| MED-120 | 3 | 1 |
| MED-124 | 3 | 1 |
| MED-221 | 5 | 1 |
| MED-84 | 8 | 1 |
| MED-58 | 3 | 1 |
| MED-64 | 5 | 1 |
| MED-57 | 3 | 1 |
| MED-218 | 13 | 2 |
| MED-142 | 8 | 1 |
| MED-143 | 13 | 1 |
| MED-146 | 8 | 1 |
| MED-145 | 5 | 1 |
| MED-144 | 8 | 1 |
| MED-131 | 8 | 2 |
| MED-128 | 5 | 2 |
| MED-125 | 8 | 1 |
| MED-127 | 3 | 1 |
| MED-101 | 5 | 1 |
| MED-88 | 5 | 2 |
| MED-90 | 5 | 2 |
| MED-54 | 13 | 1 |
| MED-66 | 13 | 1 |
| MED-94 | 8 | 2 |
| MED-78 | 5 | 1 |
| MED-174 | 8 | 1 |
| MED-185 | 3 | 1 |
| MED-175 | 5 | 1 |
| MED-179 | 3 | 1 |
| MED-141 | 8 | 1 |
| MED-187 | 13 | 2 |
| MED-184 | 8 | 2 |
| MED-186 | 3 | 1 |
| MED-181 | 5 | 1 |
| MED-177 | 8 | 1 |
| MED-183 | 5 | 1 |
| MED-171 | 13 | 1 |
| MED-178 | 13 | 2 |
| MED-176 | 13 | 1 |
| MED-173 | 5 | 1 |
| MED-172 | 8 | 1 |
| MED-180 | 5 | 1 |
Retrospectiva – Sprint 1
Resumen general
El equipo completó 84 puntos de historia enfocados en seguridad, autenticación y alta disponibilidad.
Se fortaleció la colaboración técnica, se consolidaron prácticas de CI/CD y se alcanzaron entregables claves de arquitectura.
Lo que salió bien
- Comunicación constante entre desarrolladores, QA y Product Owner.
- Implementación exitosa del login seguro y validación de credenciales.
- Mejora notable en tiempos de despliegue continuo (CI/CD).
- Avance significativo en la arquitectura de alta disponibilidad (Inventario y Productos).
- Integración fluida de nuevas historias sin bloqueos críticos.
Lo que no salió bien
- Sobrecarga de tareas paralelas y tickets clonados dificultaron la trazabilidad.
- Faltaron pruebas unitarias y métricas de cobertura en algunos módulos.
- Retrasos por dependencias externas en configuración de pipelines.
- Falta de alineación entre QA y backend durante la ejecución.
Acciones de mejora
| Acción | Responsable | Sprint objetivo |
|---|---|---|
| Consolidar backlog y eliminar duplicados | PO / Equipo Técnico | Sprint 2 |
| Establecer cobertura mínima del 70 % y reportarla en CI/CD | DevOps / QA | Sprint 2 |
| Implementar dashboard de métricas de rendimiento | Arquitectura | Sprint 2 |
| Balancear esfuerzo técnico y funcional durante la planificación | Scrum Master | Sprint 2 |
| Documentar flujo de despliegue y versionamiento | DevOps | Sprint 2 |
Próximos pasos
- Planificación del Sprint 2 con foco en observabilidad y calidad.
- Activar métricas de cobertura y disponibilidad automáticas.
- Integrar dashboard de monitoreo y alertas.
- Realizar cierre formal del Sprint 1 con informe de valor entregado.