Configurar un Pipeline de CI/CD en Dos Horas: Por Qué Solo el 21% lo Consigue
Solo el 21% de los equipos consigue poner en marcha un pipeline de construcción y despliegue en un entorno nuevo en menos de dos horas. El tiempo que falta no es técnico: es la espera entre equipos. Un camino estándar con autoservicio resuelve la mayor parte.
Un servicio nuevo está listo para salir del portátil de quien lo escribió. Falta ponerlo en marcha en un entorno compartido: construir, analizar, probar y desplegar. En la mayoría de las organizaciones, este paso no se mide en minutos. Se mide en solicitudes.
Una solicitud para crear el entorno. Otra para las credenciales. Otra para el análisis de seguridad. Otra para la aprobación de quien gestiona la infraestructura. Cada una con su cola.
Qué dice el informe
La encuesta la realizó Coleman Parkes en febrero de 2026, por encargo de Harness, a 700 profesionales y responsables de ingeniería de grandes empresas de Estados Unidos, Reino Unido, Alemania, Francia e India. Es un valor declarado, no medido, pero el patrón que describe es reconocible.
El mismo informe muestra dónde está el retraso. Más de tres cuartas partes de los encuestados, el 77%, dicen que los equipos esperan a menudo a otros en trabajo de entrega rutinario antes de poder llevar código a producción. Y el 69% admite perder tiempo con pipelines lentos o inestables, que asocia al desgaste de los equipos.
Dos horas como medida de dependencia
El tiempo para poner en marcha un pipeline nuevo rara vez mide la competencia técnica del equipo. Configurar un pipeline de integración y entrega continuas (CI/CD) es conocimiento consolidado. Lo que mide el tiempo es cuántos equipos y cuántas solicitudes hay entre el código y el entorno donde va a ejecutarse.
Por eso, contratar a más personas para atender solicitudes no acorta el camino. Aumenta la capacidad de la cola, pero la cola sigue ahí.
Dónde se pierde el tiempo
Los pasos que suelen depender de otro equipo se repiten de una organización a otra:
- Entorno: crear el espacio donde se ejecutará el servicio, con red y permisos.
- Credenciales y secretos: obtener acceso a bases de datos, colas y servicios externos.
- Seguridad: análisis de dependencias e imágenes antes de cualquier despliegue.
- Configuración del pipeline: escribir, o copiar y adaptar, la definición de construcción y despliegue.
- Aprobación: autorización para el primer despliegue en un entorno compartido.
Cada paso es razonable por separado. El problema es la suma de las esperas.
Y las esperas no se suman de forma lineal. Una solicitud que se queda parada al final del día solo vuelve a moverse a la mañana siguiente. Una solicitud que vuelve con una pregunta regresa al final de la cola. El equipo que espera cambia de tarea mientras tanto y, cuando llega la respuesta, tiene que retomar el contexto. El resultado es que un recorrido de cinco pasos sencillos puede ocupar varios días de calendario sin que nadie haya trabajado en él más de una hora.
Hay además un efecto menos visible. Cuando poner un servicio en marcha es caro, los equipos evitan crear servicios nuevos y añaden funcionalidades a los que ya existen. La arquitectura pasa a decidirse por el coste de la cola, y no por el diseño que tendría sentido.
El camino estándar
La Cloud Native Computing Foundation (CNCF) describe, en su documento sobre plataformas, una respuesta concreta: un flujo reutilizable para construir, analizar, probar, desplegar y observar una aplicación, ofrecido con una plantilla de proyecto inicial y documentación. A este conjunto se le suele llamar camino estándar o "golden path".
En la práctica, el equipo no escribe un pipeline desde cero. Parte de una plantilla que ya integra la construcción, el análisis de seguridad, las pruebas y el despliegue, y ajusta solo lo que es específico del servicio.
Autoservicio con reglas
El mismo documento de la CNCF define dos propiedades que cambian la cuenta del tiempo.
La primera es el autoservicio: quien usa la plataforma debe poder solicitar y recibir capacidades de forma autónoma y automática, sin intervención manual de otro equipo. Un entorno o una base de datos solicitados con un comando o un formulario, y entregados con sus credenciales.
La segunda es la seguridad por defecto. Las reglas de seguridad y las aprobaciones viven dentro de la plantilla, en lugar de solicitarse caso por caso. El equipo de plataforma decide las reglas una vez; cada equipo de producto las aplica al activar la plantilla.
Esta combinación convierte una cadena de solicitudes en un único paso controlado.
Lo que el camino estándar no es
El camino estándar no es una obligación ni una camisa de fuerza. El documento de la CNCF es explícito: la plataforma debe ser opcional y combinable, y permitir que los equipos de producto aporten y gestionen sus propias capacidades fuera de la oferta de la plataforma cuando sea necesario. La plantilla sirve al caso común; el caso inusual sigue siendo posible, con más esfuerzo y más responsabilidad para quien lo elige.
Tampoco traslada la operación a los equipos de producto. La misma fuente establece que la plataforma debe ocultar los detalles de implementación, y que quien la usa no debe ser responsable de operar los servicios que ofrece. El equipo activa la plantilla; el equipo de plataforma mantiene lo que hay debajo.
Cómo medirlo
Tres medidas sencillas bastan para saber si el camino se está acortando:
- Tiempo desde la solicitud hasta el primer despliegue de un servicio nuevo en un entorno compartido.
- Número de pasos con espera a otro equipo en ese recorrido.
- Proporción de pipelines que siguen la plantilla, frente a los escritos desde cero.
A estas se suma la estabilidad. Un pipeline rápido de crear pero lento o inestable al ejecutarse vuelve a generar espera, y ese es el tiempo que el 69% de los encuestados dice perder.
Por dónde empezar
No hace falta construir una plataforma completa para acortar el camino. Un recorrido práctico empieza con cuatro pasos:
- Elegir el tipo de servicio más frecuente, el que la organización crea más veces.
- Mapear el recorrido actual de ese servicio, desde la solicitud hasta el primer despliegue, con cada espera identificada.
- Convertir en autoservicio el paso con más espera, manteniendo las reglas que ya existían.
- Medir de nuevo el tiempo desde la solicitud hasta el primer despliegue y repetir con el paso siguiente.
Cada vuelta elimina una cola del camino. La plantilla completa surge de la suma de estas vueltas, y no de un proyecto diseñado desde cero.
Cinco preguntas antes de declarar la entrega autónoma
- ¿Existe una plantilla de pipeline aprobada que cualquier equipo pueda activar sin solicitud?
- ¿Los análisis de seguridad y las aprobaciones están dentro de la plantilla?
- ¿Un entorno nuevo se crea por autoservicio, con las credenciales incluidas?
- ¿Alguien mide el tiempo desde la solicitud hasta el primer despliegue?
- ¿Hay un equipo o un responsable del mantenimiento del camino estándar?
Conclusión
Dos horas no es un objetivo técnico difícil. Es un objetivo de organización. Mientras poner un servicio en marcha dependa de una cadena de solicitudes, la velocidad de entrega queda limitada por la cola más lenta, y no por el equipo que escribió el código.
La diferencia entre comprar capacidad y montar una plataforma que funcione se explica en externalización de platform engineering, y cuándo tiene sentido reforzar el equipo interno se explica en DevOps as a Service, cuándo tiene sentido. Para revisar el camino hasta producción y diseñar el camino estándar, es posible reservar una Sesión de Orientación, sin compromiso.