Saltar a contenido

Ciclo de vida DevOps

El ciclo reúne decisiones de producto, cambios de código, entrega de artefactos y observación del resultado. Cada fase produce evidencia que puede alimentar la siguiente iteración. El orden conceptual del ciclo no coincide necesariamente con los nombres de las etapas de CI: la imagen se construye y publica en el mismo job, y los análisis de código ocurren antes de construirla.

De la planificación a la operación

Fase Trabajo del equipo Implementación y evidencia Límite relevante
Plan Definir tareas, hitos y prioridad Memoria y 12 issues públicos consultados el 26/10/2026 Nueve cerrados, tres abiertos; hito de infraestructura todavía activo
Code Editar código, manifiestos e IaC Repositorios separados; uso histórico del editor y Web IDE La política completa de revisión de MR no queda descrita en código
Build Compilar y empaquetar Maven genera el JAR; Docker construye la imagen -DskipTests omite los tests en el job de compilación
Test Analizar calidad y seguridad Plantillas GitLab y parsers de informes JSON Los parsers comparten allow_failure: true
Release Hacer disponible el artefacto Push a GitLab Container Registry con referencia por SHA No se crea un objeto GitLab Release versionado semánticamente
Deploy Promover y aplicar versión Commit en repo de manifiestos y kubectl apply Un destino por ejecución; no espera explícita de rollout en el job
Operate Inspeccionar recursos y ejecutar cambios Agente GitLab, contextos CI y recursos de Kubernetes Las acciones dependen de RBAC y permisos del agente
Monitor Observar ejecución y alimentar tareas Logs/eventos, probes y evidencia histórica de ingestión OTLP No se ha encontrado instrumentación OTLP de la aplicación en los repos revisados

Planificación observada

El inventario público conserva cuatro hitos: preparación de la aplicación, pipelines y manifiestos cerrados; infraestructura activo. Los tres issues abiertos pertenecen a IaC. Una tarea histórica menciona Azure, pero el código implementa AWS y GCP; esa tarjeta no amplía el alcance entregado. La relación con la memoria explica esta diferencia entre planificación e implementación.

Cadena de trazabilidad

La referencia de imagen sigue esta expresión:

$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA

El job update-k8s-manifests sustituye la imagen en deployment.yaml y crea un commit cuyo mensaje es el SHA de la aplicación. El job deploy vuelve a clonar main del repositorio de manifiestos y aplica sus ficheros al destino elegido. Para investigar una entrega hay que conservar la relación entre commit fuente, pipeline, referencia de imagen, commit de manifiestos y clúster.

Esa cadena es útil para localizar qué se pidió desplegar. No equivale a verificar que todos los pods completaran el cambio ni a fijar la imagen por digest: el job final ejecuta kubectl get all, pero no kubectl rollout status. Una ejecución verde debe complementarse con la verificación operativa.

Cuándo se ejecuta cada parte

La plantilla de despliegue vigente ejecuta los jobs de promoción y aplicación cuando la rama es main y está protegida. Sus reglas no contienen when: manual; son automáticos cuando se cumplen las condiciones. La memoria contiene una versión anterior con una promoción manual, que se recoge en el mapa de diferencias.

La infraestructura funciona de otra forma: create selecciona validación, plan y aplicación; los jobs de aplicación se ofrecen manualmente sobre main, con allow_failure: false. Cada raíz debe completarse antes de continuar con la siguiente. Las acciones destroy siguen el orden inverso y también requieren aplicación manual. Revisa el pipeline de infraestructura antes de lanzar una ejecución.

Los análisis de calidad/secretos/contenedor incluyen condiciones de rama protegida y variables de habilitación. La inclusión de SAST se apoya en una plantilla externa de GitLab; su comportamiento completo depende de la plantilla resuelta por la instancia. La guía de calidad y seguridad distingue los jobs propios de los heredados.

Dos ciclos que se encuentran

La infraestructura no necesita reconstruirse en cada cambio de texto del frontend. Mientras sus contratos sigan vigentes, una nueva imagen puede desplegarse sobre el clúster existente. Un cambio en red, base de datos, versión de clúster o bootstrap de plataforma sigue el pipeline IaC y debe evaluarse con su plan.

La aplicación depende del namespace, secretos, contexto del agente y red creados o configurados durante el bootstrap. Por eso el primer despliegue establece primero la base, comprueba el acceso y luego permite ejecutar los pipelines de aplicación.

Cerrar una iteración

Después de desplegar, verifica disponibilidad de pods, errores de arranque, acceso a base de datos y el recorrido funcional de usuario. Registra los fallos como nuevas tareas relacionadas con el commit y la ejecución. Un rollback de aplicación debe cambiar la referencia versionada y reaplicarla; no revierte automáticamente el esquema ni el contenido de MySQL.

El mantenimiento de esta documentación forma parte del mismo ciclo: los cambios en contratos, variables y procedimientos deben actualizarse en ambos idiomas y pasar por el pipeline de publicación de documentación.

Fuentes