Ciclo de Vida del Software (SDLC)

El ciclo de vida del software en HERA sigue un modelo DevOps iterativo que integra desarrollo, seguridad y operaciones en un flujo continuo y automatizado.

1 Plan Backlog · Arquitectura

2 Develop Feature branches · MR

3 Build Compilar · Docker image

4 Test Unit · Integration · QA

Feedback Loop

8 Monitor Datadog · Cloud Mon.

7 Operate HPA · Incidentes

6 Deploy DEV → QA → PRD

5 Release Tag · Changelog · Aprov.

Mensaje clave 8 fases iterativas. El ciclo no termina en deploy — Monitor alimenta Plan para la siguiente iteración.

---

1. Plan (Planificar)

Objetivo: Definir requerimientos y diseñar la solución.

• Actividades: Definición de historias de usuario, diseño de arquitectura, y dimensionamiento de infraestructura usando el HERA Calculator.
• Responsables: Product Owner, Arquitecto, Tech Lead.
• Entregable: Un backlog priorizado y un diseño técnico aprobado.

2. Develop (Desarrollar)

Objetivo: Escribir código de alta calidad siguiendo nuestros estándares.

• Actividades: Desarrollo en ramas de feature a partir de develop, commits siguiendo el estándar Conventional Commits, y creación de Merge Requests para revisión.
• Responsables: Desarrolladores.
• Herramienta Principal: GitLab.

3. Build (Construir)

Objetivo: Compilar y empaquetar la aplicación en un artefacto desplegable.

• Actividades: El pipeline de CI se dispara automáticamente para compilar el código y construir una imagen de contenedor Docker.
• Responsables: Proceso Automatizado (Pipeline CI).
• Entregable: Una imagen de Docker versionada y almacenada en Artifact Registry.

4. Test (Probar)

Objetivo: Validar la calidad, funcionalidad y seguridad del código.

• Actividades: Ejecución automatizada de pruebas unitarias, análisis SAST (SonarQube), SCA (Docker Scout), Secret Detection (TruffleHog), etc.
• Responsables: Proceso Automatizado (Pipeline CI).
• Entregable: Un reporte de pruebas y un Quality Gate que aprueba o rechaza el build.

5. Release (Liberar)

Objetivo: Preparar y aprobar el artefacto para su despliegue en producción.

• Actividades: Generación automática de changelog, creación de un tag de Git, y aprobación de un Merge Request de develop a main.
• Responsables: Tech Lead, QA, Product Owner (aprobadores).
• Entregable: Una versión del software etiquetada y lista para producción.

6. Deploy (Desplegar)

Objetivo: Poner la aplicación en ejecución en los diferentes ambientes.

• Actividades: El pipeline de CD despliega el contenedor en GKE.
• Responsables: Proceso Automatizado (Pipeline CD).
• Flujo:
  • Automático a DEV/QA: Al hacer merge a develop.
  • Manual/Automático a PRD: Al hacer merge a main.

7. Operate (Operar)

Objetivo: Mantener la aplicación funcionando de manera confiable y escalable.

• Actividades: Gestión de configuración, auto-escalado (HPA), gestión de incidentes.
• Responsables: SRE, Equipo de Plataforma.
• Herramientas: Kubernetes, PagerDuty, Slack.

8. Monitor (Monitorear)

Objetivo: Observar el comportamiento de la aplicación para garantizar el cumplimiento de los SLOs y detectar problemas proactivamente.

• Actividades: Recolección de métricas, logs y trazas.
• Responsables: SRE, Equipo de Desarrollo.
• Herramientas: Datadog, Cloud Monitoring.

El círculo se cierra

La información recolectada en la fase de Monitor se convierte en Feedback que alimenta la fase de Plan, ya sea para corregir bugs o para diseñar nuevas funcionalidades, cerrando así el ciclo de mejora continua.