El problema que nadie nombra: verde en el pipeline no significa que tu app funciona
Hay una confusión que se repite en casi todos los equipos que trabajan con Kubernetes: ejecutan kubectl apply, ven un resultado exitoso, y asumen que su aplicación está corriendo correctamente. Es un error comprensible, pero costoso.
Un artículo técnico publicado el 28 de julio de 2026 en Dev.to por Bobai Kato documenta un pressure test sobre Hasura usando manifests crudos de Kubernetes, sin Helm ni Docker Compose. El resultado más importante no es técnico en el sentido tradicional: es conceptual. El ejercicio demuestra que un pipeline puede darte tres niveles completamente distintos de evidencia, y que la mayoría de los equipos los trata como si fueran uno solo.
En este artículo analizamos esos tres niveles, qué significa gobernar la ejecución de forma explícita, y cómo este enfoque aplica a equipos de desarrollo en Perú y América Latina que están desplegando en Kubernetes o planean hacerlo.
Los tres niveles de evidencia que tu pipeline confunde
Según el análisis del pressure test, cuando ejecutas un comando de kubectl y obtienes un resultado exitoso, ese resultado puede significar exactamente una de estas tres cosas:
- Nivel 1 — Interpretación local: kubectl procesó el manifest en tu máquina sin contactar ningún cluster. Es como revisar si un formulario tiene los campos bien llenados, sin enviarlo a ningún lado.
- Nivel 2 — Aceptación del cluster: la API de Kubernetes recibió y aceptó los recursos declarados. El formulario llegó a la oficina y fue recibido, pero nadie ha procesado la solicitud todavía.
- Nivel 3 — Readiness de la aplicación: los pods están corriendo, la base de datos conectada, el servicio es alcanzable y la aplicación responde. La solicitud fue aprobada y el servicio está activo.
El pressure test sobre Hasura demostró que el Nivel 1 y el Nivel 2 son verificables de forma automatizada y honesta. El Nivel 3 requiere pruebas adicionales que van mucho más allá de un kubectl apply exitoso. Y la trampa está en que los tres se ven igual en la terminal: verde.
Gobierno de ejecución: separar lo que verifica de lo que muta
Lo más interesante del enfoque documentado en el pressure test es la separación explícita entre tareas non-mutating y tareas cluster-mutating. Esto no es solo una buena práctica de estilo: es una decisión de arquitectura que cambia lo que puedes afirmar sobre tu despliegue.
La verificación local usa kubectl annotate --local, que carga y emite el objeto sin contactar ninguna API de Kubernetes. Esto prueba que el manifest es sintácticamente válido y que kubectl puede interpretarlo, nada más. Es rápido, seguro, y no tiene efectos secundarios.
Las tareas de apply, en cambio, declaran explícitamente que mutan estado externo. En el contrato de Ota, esas tareas quedan excluidas de agent.safe_tasks, lo que significa que un agente automatizado no puede ejecutarlas sin autorización explícita. La intención de cada flujo queda capturada en el contrato mismo, no en la memoria del equipo.
Según el análisis, esta distinción es el resultado de ingeniería más importante del ejercicio: "un Deployment y Service creados son evidencia más fuerte que el manejo local de YAML, pero todavía no son prueba de que Hasura esté listo".
¿Cómo aplica esto a equipos en Perú y América Latina?
En muchos proyectos de software en la región, los pipelines de CI/CD se construyen rápido, bajo presión, y con el objetivo principal de que algo funcione. Eso es entendible. Pero cuando ese pipeline llega a producción y el equipo confía en él para tomar decisiones, la diferencia entre estos tres niveles de evidencia se vuelve crítica.
Un equipo que despliega en Kubernetes en AWS EKS o Azure AKS, por ejemplo, puede tener un pipeline que pasa en verde en cada PR, pero que en realidad solo está validando manifests localmente. Si nadie definió explícitamente qué cuenta como prueba de que el despliegue funcionó, ese equipo está tomando decisiones sobre evidencia incompleta.
El enfoque del pressure test sugiere algo concreto: documentar en el contrato de ejecución cuál es el nivel de evidencia que cada tarea produce. No como documentación estática, sino como parte del pipeline mismo. Eso cambia la conversación entre desarrolladores, DevOps y líderes técnicos: en lugar de "el pipeline pasó", la pregunta correcta es "¿qué nivel de prueba tenemos hoy?".
¿Cómo aplica esto en tu empresa?
Si tu equipo trabaja con Kubernetes, hay tres acciones concretas que puedes tomar esta semana:
- Audita tu pipeline actual: revisa cada paso de CI/CD y clasifícalo según los tres niveles. ¿Cuántos pasos realmente prueban readiness de la aplicación versus aceptación del cluster?
- Separa explícitamente las tareas mutantes: cualquier tarea que modifique estado en un cluster real debe estar marcada como tal, y no debe ejecutarse automáticamente en flujos de verificación rutinaria.
- Define el criterio de "listo para producción": escríbelo. No como un comentario en el código, sino como parte del pipeline. ¿Qué debe ser verdad para que un despliegue cuente como exitoso? ¿Pods en running? ¿Health check respondiendo? ¿Smoke test pasando?
Estos tres pasos no requieren cambiar de herramienta ni reescribir tu infraestructura. Requieren precisión conceptual sobre lo que tu pipeline realmente prueba.
Conclusión
El pressure test sobre Hasura y Kubernetes documenta algo que muchos equipos saben intuitivamente pero pocos han formalizado: verde en el pipeline no es evidencia suficiente. La diferencia entre los tres niveles de prueba no es un detalle de implementación, es una decisión de gobierno que afecta la confiabilidad de cada despliegue.
En Consultoría-Ti acompañamos a equipos técnicos en Perú y América Latina que están construyendo o madurando sus pipelines de CI/CD, arquitecturas en la nube, y procesos de despliegue. Si tu equipo está enfrentando este tipo de decisiones, conversemos.
Contáctanos en Consultoría-Ti y evaluemos juntos qué nivel de evidencia tiene tu pipeline hoy.
Fuentes y Referencias
✨ Contenido generado con ContentFlow — Consultoría-Ti