En la lección anterior definimos qué son la Integración Continua, la Entrega Continua y el Despliegue Continuo. Ahora toca la pregunta incómoda: ¿merece la pena?. Montar un pipeline cuesta tiempo, hay que mantenerlo, consume minutos de máquina que se facturan y, si se hace mal, genera más frustración que valor. Esta lección es deliberadamente honesta: primero recorreremos los beneficios reales —con el detalle de cómo se mide cada uno, porque un beneficio que no se mide es una opinión—, y después pondremos sobre la mesa los costes y los escenarios donde CI/CD aporta poco. Usaremos como hilo el caso de Reservalia, cuyo punto de partida conocemos: despliegues manuales de 3 horas los viernes y dos incidencias graves el último trimestre. Al terminar, tendrás argumentos concretos para defender —o para descartar razonadamente— una inversión en CI/CD.

1. La balanza: dos columnas, no una
2. Reducción del tiempo de entrega
3. Detección temprana de defectos y el coste creciente por fase
4. Menor riesgo gracias a lotes pequeños
5. Repetibilidad y trazabilidad
6. Feedback objetivo para el equipo
7. Moral del equipo y carga del on-call
8. Tabla resumen: beneficio → cómo se mide → riesgo si no se hace
9. Los costes, sin edulcorar
10. Cuándo CI/CD aporta poco
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

La mayoría de material sobre CI/CD presenta una lista de beneficios y se queda ahí. Eso produce equipos que montan un pipeline por moda, lo abandonan a los tres meses y concluyen que "CI/CD no funciona". La realidad es una balanza:

La respuesta suele ser "sí", pero no siempre, y desde luego no en la misma medida para un equipo de 3 personas con un proyecto interno que para uno de 40 con un SaaS de pago. La sección 10 aborda las excepciones.

El tiempo de entrega no es el tiempo de programar. Es el tiempo total desde que el código está escrito hasta que el usuario lo está usando. En Reservalia, hoy, ese recorrido es así:

Fíjate en dónde está el bloque más largo: no es programar, es esperar. El cambio de Diego está terminado el martes y llega a los usuarios el viernes de la semana siguiente. La ventana de despliegue impone una espera de hasta 9 días para un cambio que tarda 3 días en escribirse.

Y esa espera no es neutral: mientras el cambio espera, se acumula con otros cambios, formando el lote grande del que hablaremos en la sección 4.

Un pipeline automatizado ataca dos cosas a la vez:

1. Elimina la ventana de espera. Si desplegar cuesta 8 minutos y no requiere que nadie se coordine, no hace falta agrupar despliegues los viernes.
2. Elimina el tiempo de ejecución manual. Las 3 horas de Diego pasan a ser tiempo de máquina, y además tiempo de máquina en paralelo con otro trabajo.

El antes/después de Reservalia, con las cifras de su propio caso:

Esas 156 horas son casi un mes de trabajo a jornada completa dedicado exclusivamente a copiar ficheros. Es la cifra que Marta llevará a la reunión de presupuesto.

Cuidado con las cifras. Las de esta tabla salen del caso de Reservalia, que es ficticio pero coherente. Evita citar porcentajes genéricos del tipo "CI/CD mejora la productividad un 40 %": son números que circulan sin fuente y que no resisten una pregunta. Mide tu proceso. La lección 01-05 te dará el instrumental para hacerlo.

Un defecto no cuesta lo mismo según cuándo se descubre. La razón es puramente práctica: cuanto más tarde aparece, más contexto se ha perdido y más personas hay implicadas.

No hace falta ningún estudio para entender la curva: arreglar un fallo que descubres a los 4 minutos de escribirlo es incomparablemente más barato que arreglar el mismo fallo tres semanas después, de madrugada, en una base de código que ya ha cambiado.

La Integración Continua actúa desplazando la detección hacia la izquierda de esa línea. En inglés se llama shift left, y es la razón principal por la que CI existe.

Una de las dos incidencias graves del trimestre fue esta: Diego cambió el tipo de la columna duracion_minutos de integer a numeric para admitir citas de 90,5 minutos. Había un test que lo detectaba... pero nadie ejecutó los tests aquel viernes. La aplicación estuvo devolviendo error 500 al crear cualquier cita durante 40 minutos, hasta que un cliente llamó.

Con CI, ese fallo se habría manifestado antes de fusionar el pull request, con Diego mirando la pantalla y el contexto fresco. Coste: cinco minutos. Sin CI: 40 minutos de caída, reservas perdidas, una llamada de un cliente enfadado y una tarde de post mortem.

La diferencia no está en la calidad del test. El test ya existía. La diferencia está en que un humano tiene que acordarse de ejecutarlo, y un pipeline no.

Cuando Diego despliega el viernes, no despliega un cambio: despliega todo lo acumulado durante la semana. Supongamos 14 commits de 3 personas.

Si algo se rompe, ¿cuál de los 14 cambios es el culpable? Nadie lo sabe. Empieza la fase de bisección manual, en producción, con usuarios afectados y prisa.

Comparemos las dos formas de trabajar:

La paradoja que a mucha gente le cuesta aceptar es esta: desplegar más veces reduce el riesgo total, aunque aumente el número de despliegues. Porque el riesgo no está en el acto de desplegar, sino en la cantidad de cambio no verificado que ese acto libera de golpe.

Las dos incidencias graves del trimestre ocurrieron ambas en un despliegue de viernes. No es casualidad estadística: los únicos despliegues que hacen son de viernes, y cada uno de ellos libera una semana de cambios sin verificar. Reducir el tamaño del lote es la palanca más directa que tiene el equipo para reducir su change failure rate (lo mediremos en 01-05).

Hoy en Reservalia, si Diego está de vacaciones, nadie sabe desplegar. El conocimiento vive en su cabeza y en un documento de Notion desactualizado. Eso es un riesgo de negocio, no solo técnico: se llama bus factor de 1.

Un pipeline convierte ese conocimiento tácito en código versionado y ejecutable:

• Está en el repositorio, cualquiera lo lee.
• Se revisa en pull requests, como cualquier otro cambio.
• Se ejecuta igual lo lance quien lo lance.
• Si algo cambia en el proceso, queda registrado en el historial con autor y motivo.

Estas son preguntas que Nuria, la SRE, no puede responder hoy y que con un pipeline se contestan en segundos:

Un ejemplo de la información que un pipeline deja registrada por cada despliegue —usaremos esta estructura en la lección 01-05 para calcular métricas:

Con solo este registro, repetido en cada despliegue, ya puedes responder a todas las preguntas de la tabla anterior. Y además, como veremos, calcular tres de las cuatro métricas DORA.

Uno de los beneficios menos citados y más transformadores: el pipeline sustituye opiniones por hechos.

Sin CI, las conversaciones de un equipo suenan así:

• — "Yo creo que esto está listo."
• — "A mí me funcionaba ayer."
• — "Habría que probarlo más a fondo, ¿no?"

Con CI, suenan así:

• — "El PR está verde: build, 340 tests, cobertura y lint."
• — "Falla crearCita › rechaza solapamientos, línea 88."

La diferencia es que la segunda conversación no tiene ego. El pipeline no critica a nadie: informa. Esto tiene tres efectos concretos:

1. Despersonaliza la crítica. No es "Marta dice que tu código está mal": es "el paso de tipos ha fallado". La revisión humana queda libre para lo que de verdad aporta —diseño, legibilidad, decisiones de producto— en vez de gastarse en formato y erratas.
2. Da un criterio de "hecho" compartido. Definir hecho como "el pipeline está verde y el PR aprobado" elimina discusiones interminables.
3. Hace visible el estado real del proyecto. Cualquiera puede mirar el historial de ejecuciones y ver si el proyecto está sano o si lleva tres días en rojo.

Este beneficio es difícil de cuantificar y, sin embargo, suele ser el que decide si un equipo persevera con CI/CD o lo abandona.

Vuelve al viernes por la tarde de Diego. Lo que la hoja de cálculo no recoge:

• Ansiedad anticipatoria. Desde el jueves, Diego sabe que le espera el viernes. Trabaja peor el jueves.
• Fin de semana condicionado. Si algo se rompe el viernes a las 19:00, se rompe el fin de semana de alguien.
• Miedo a cambiar cosas. Cuando desplegar da miedo, la gente evita refactorizar, evita actualizar dependencias y acumula deuda técnica. El miedo al despliegue se convierte en un impuesto sobre la calidad del código.
• Concentración de conocimiento. Diego es el único que sabe desplegar y eso, que parece poder, en la práctica es una cadena: no puede desconectar de verdad en vacaciones.
• Rotación. El agotamiento por incidentes evitables es una de las razones habituales por las que la gente cambia de trabajo. Sustituir a un desarrollador cuesta meses de productividad.

Nuria, que lleva las guardias, obtiene mejoras muy concretas:

La frase que resume el cambio cultural: un buen sistema de CI/CD convierte una emergencia en un procedimiento.

CI/CD no arregla una cultura de equipo rota. Si en tu organización se culpa a las personas por los incidentes, automatizar el despliegue solo hará que las culpas lleguen más rápido. La automatización amplifica la cultura existente: si es sana, la refuerza; si es tóxica, la acelera.

Esta tabla es el resumen ejecutivo de la lección. Es exactamente el material que Marta necesita para justificar la inversión:

La forma estándar y reconocida en el sector de medir varios de estos beneficios son las métricas DORA (frecuencia de despliegue, lead time for changes, change failure rate y time to restore service). Las desarrollaremos en detalle en la lección 01-05, junto con la manera práctica de instrumentarlas en Reservalia. De momento quédate con que existen y con que dan un lenguaje común para hablar de esto con dirección.

Todo lo anterior tiene una factura. Ignorarla es la vía rápida al abandono del pipeline a los tres meses.

Escribir el primer pipeline útil no son dos tardes. Para un proyecto del tamaño de Reservalia, un cálculo realista:

Y hay un coste añadido difícil de tragar: durante esas semanas, conviven los dos procesos. Sigues desplegando a mano mientras construyes el automático. Es trabajo doble temporal, y es la fase en la que más proyectos se abandonan.

El pipeline es software y, como todo software, se pudre si no se cuida:

• Las acciones y plugins de terceros publican versiones nuevas y abandonan las antiguas.
• Las imágenes base de los runners cambian (una actualización del sistema operativo del runner puede romper una build).
• Las versiones de Node, Python o Java llegan a fin de vida.
• Las credenciales caducan y hay que rotarlas.
• Cada nueva funcionalidad del producto puede requerir un paso nuevo en el pipeline.

Cuenta con medio día al mes de mantenimiento para un proyecto pequeño, más los picos cuando algo grande cambia. Lo trataremos a fondo en el módulo 4.

Esto es dinero contante. Los proveedores de CI/CD alojados facturan por minuto de ejecución, y las cuotas gratuitas se agotan antes de lo que parece.

Hagamos el cálculo para Reservalia:

Tres mil minutos al mes en un proyecto pequeño. Con runners de mayor tamaño (más CPU y RAM), el precio por minuto se multiplica. Y hay un multiplicador que sorprende a mucha gente: en una matriz de builds (por ejemplo, probar en Node 18, 20 y 22 × Linux y macOS), los minutos se multiplican por el número de combinaciones, y los runners de macOS suelen facturarse a un múltiplo del precio de Linux.

Las palancas para controlarlo —caché de dependencias, ejecución condicional por carpetas modificadas, cancelar ejecuciones obsoletas, paralelizar bien— son materia del módulo 4, lección 04-04.

Una prueba flaky es la que a veces pasa y a veces falla sin que el código haya cambiado. Causas típicas: dependencias del reloj, esperas fijas en pruebas de interfaz, orden de ejecución, estado compartido en la base de datos, condiciones de carrera, llamadas a servicios externos.

Son el veneno más eficaz contra un pipeline, y el mecanismo es psicológico:

El daño no es el tiempo perdido en reintentos: es que destruyen la señal. Un pipeline en el que no se confía es peor que no tener pipeline, porque cuesta dinero y da falsa seguridad. La única política sostenible es tratar un test flaky como un fallo de prioridad alta: se arregla o se pone en cuarentena explícita con un plazo, nunca se "reintenta y a otra cosa". Lo abordaremos en la lección 02-04.

Añadir CI/CD añade un sistema más que el equipo debe entender: YAML con su sintaxis y sus trampas, el modelo de ejecución de la herramienta, contenedores, gestión de secretos, permisos en la nube. Para un equipo junior, esto es real y hay que presupuestarlo. La buena noticia es que es conocimiento transferible: los conceptos del módulo 1 valen para cualquier herramienta, como veremos en 01-03.

Con honestidad, hay contextos donde la inversión no compensa —o compensa solo en parte:

Fíjate en un matiz que aparece varias veces: incluso donde el Despliegue Continuo no aplica, la Integración Continua casi siempre sí. El escalón de abajo de la pirámide de 01-01 es rentable en prácticamente cualquier contexto con más de una persona y más de un mes de vida.

Error 1: vender CI/CD con cifras genéricas de internet. "Los equipos que hacen CI/CD despliegan 200 veces más" es un titular sin contexto. Si lo llevas a una reunión, la primera pregunta será "¿de dónde sale?" y no tendrás respuesta. Lleva tus números: 156 horas al año de Diego copiando ficheros es un argumento que nadie discute.

Error 2: presentar solo la columna de beneficios. Si prometes que todo será más rápido y omites las 4 semanas de montaje y los 3.000 minutos al mes, la primera factura destruirá tu credibilidad. Presenta la balanza completa; da mucha más confianza.

Error 3: medir el éxito por "tenemos pipeline". Tener un ci.yml no es un resultado. Los resultados son: el lead time bajó de 9 días a 2 horas, o el número de despliegues fallidos cayó de 2 por trimestre a 0. Define la métrica antes de empezar.

Error 4: automatizar el despliegue antes de tener pruebas. Es el orden equivocado y el más frecuente. Automatizar un despliegue sin pruebas fiables solo consigue llevar los errores a producción más rápido y más a menudo. Primero pruebas, luego automatización del despliegue.

Error 5: tolerar tests flaky "temporalmente". Ese "temporalmente" se convierte en permanente en tres semanas y arrastra la credibilidad del pipeline entero. Trátalos como bugs de prioridad alta desde el primer día.

Consejo 1: mide tu línea base esta misma semana. Cronometra el próximo despliegue manual. Cuenta cuántos días pasan entre commit y producción en los últimos 10 cambios. Sin línea base, dentro de seis meses no podrás demostrar nada.

Consejo 2: empieza por el paso más doloroso. No intentes montar el pipeline completo. Si lo que más duele es que nadie ejecuta los tests, empieza por un workflow que ejecute los tests en cada PR. Un beneficio visible en la primera semana compra el apoyo del equipo para el resto.

Consejo 3: presupuesta el mantenimiento desde el principio. Reserva medio día al mes en la planificación. Si el mantenimiento del pipeline es siempre trabajo "que se hace en los huecos", nunca se hará y el pipeline se degradará hasta que alguien lo desactive.

Consejo 4: cuenta también los beneficios no técnicos. Que Diego pueda irse de vacaciones sin ser el único que sabe desplegar es un beneficio de continuidad de negocio. Suele convencer a dirección más que cualquier argumento técnico.

Marta tiene 15 minutos con la dirección para pedir 4 semanas de trabajo de Diego dedicadas a montar el pipeline. Con los datos del caso —despliegues semanales de 3 horas, dos incidencias graves el último trimestre, equipo de 3 personas—, prepara:

1. El coste anual actual en horas del proceso manual de despliegue.
2. Una estimación del coste de la inversión (montaje + mantenimiento del primer año), en horas.
3. El punto de equilibrio: ¿a partir de cuántos meses la inversión se ha pagado sola, contando solo el tiempo de despliegue?
4. Dos beneficios que no aparecen en ese cálculo pero que deberías mencionar igualmente.

Supón una jornada de 8 horas y 20 días laborables al mes.

Para cada escenario, decide qué recomendarías —CI completa, CI + Entrega Continua, Despliegue Continuo o nada de momento— y justifica en dos o tres frases:

1. Una desarrolladora freelance mantiene un blog personal generado estáticamente. Publica un artículo al mes. No tiene tests.
2. Una startup de 12 personas con un SaaS B2B de pago. Tienen 400 tests y una cobertura razonable. Despliegan cada dos semanas, con estrés.
3. Un equipo de 8 personas que desarrolla el software de dosificación de una bomba de infusión hospitalaria. Cada versión requiere certificación de un organismo regulador.
4. Un equipo de 5 personas que ha heredado un monolito PHP de 12 años sin ninguna prueba automatizada. Despliegan por FTP y quieren "poner CI/CD ya".

El equipo de otra empresa, Citalia, montó CI/CD hace 8 meses. Estos son sus datos actuales:

• El pipeline tarda 47 minutos en un pull request.
• De las últimas 100 ejecuciones, 31 fallaron; al reintentarlas sin cambiar nada, 26 pasaron.
• La política del equipo es "si falla, dale a Re-run jobs".
• La factura de minutos de runner ha subido un 80 % en 4 meses.
• La semana pasada llegó a producción un bug que tenía un test que lo cubría.

Responde:

1. ¿Cuál es el problema raíz y cuáles son consecuencias suyas?
2. ¿Qué beneficio de los de esta lección han perdido, aunque el pipeline "funcione"?
3. Propón tres acciones ordenadas por prioridad.

Solución al Ejercicio 1

1. Coste anual actual del despliegue manual

2. Coste de la inversión (primer año)

3. Punto de equilibrio

Interpretación honesta: el retorno puramente contable llega alrededor del primer año. Esto es importante y hay que decirlo: si vendes "se paga en dos meses", quedas retratado. Lo que hace que la inversión merezca la pena claramente son los beneficios que no están en esta cuenta.

4. Beneficios fuera del cálculo

• Reducción del riesgo de negocio: las incidencias en producción de una plataforma de reservas no cuestan solo horas de ingeniería; cuestan citas perdidas para los clientes de Reservalia y reputación. Una caída de 40 minutos en horario comercial afecta a reservas reales.
• Eliminación del bus factor: hoy, si Diego se pone enfermo, Reservalia no puede desplegar ni siquiera una corrección crítica. Eso es un riesgo de continuidad de negocio, no un inconveniente.
• Velocidad de reacción: con despliegue automatizado, corregir un bug detectado a las 10:00 es cuestión de minutos, no de esperar al viernes.
• Capacidad de crecer: el proceso actual no escala a 6 personas. Si Reservalia contrata, el cuello de botella es estructural.

Solución al Ejercicio 2

1. Blog personal estático: nada de momento, o un CI mínimo. Un artículo al mes, sin tests, sin usuarios que dependan de ello. Lo máximo justificable es un workflow trivial que construya el sitio y despliegue el HTML —que, de hecho, muchos alojamientos estáticos ya ofrecen sin configuración. Montar un pipeline elaborado aquí es un ejercicio de aprendizaje, no una necesidad.

2. Startup SaaS B2B: CI completa + Entrega Continua, con vista al Despliegue Continuo. Es el escenario donde CI/CD rinde más. Tienen tests y cobertura razonable —la base necesaria— y el estrés de las releases quincenales indica lotes demasiado grandes. Recomendación: CI en cada PR desde ya, y automatizar el despliegue hasta staging y hasta producción con puerta manual. Cuando el change failure rate baje de forma sostenida, pueden plantearse quitar la puerta.

3. Bomba de infusión hospitalaria: CI completa, Entrega Continua hasta el entorno de validación, y Despliegue Continuo descartado. El marco regulatorio exige evidencia documentada y certificación por versión; desplegar automáticamente es inviable. Pero CI aporta muchísimo aquí: pruebas exhaustivas automatizadas, trazabilidad completa de qué se construyó y con qué (justo lo que un auditor pide), y builds reproducibles. La puerta manual no es una carencia del pipeline: es un requisito del dominio.

4. Monolito PHP sin tests: CI mínima, pero el orden importa. El error sería automatizar el despliegue primero: conseguirían llevar errores a producción más rápido. Orden recomendado: (a) montar el pipeline de build y ejecución de tests, aunque al principio casi no haya tests; (b) añadir tests de las 5-10 rutas críticas de negocio —lo que un usuario no puede dejar de poder hacer—; (c) añadir análisis estático, que da valor inmediato sin escribir tests; (d) solo entonces, automatizar el despliegue, empezando por un entorno que no sea producción. Este caso concreto lo desarrollaremos en la lección 05-04.

Solución al Ejercicio 3

1. Problema raíz y consecuencias

El problema raíz son las pruebas inestables (flaky): de 31 fallos, 26 pasaron al reintentar sin tocar nada. Eso significa que aproximadamente el 84 % de los fallos son ruido. Todo lo demás es consecuencia:

• La política de "dale a Re-run" es una adaptación del equipo al ruido, no una causa.
• La factura de runners subió un 80 % en parte por los reintentos de ejecuciones de 47 minutos.
• El bug que llegó a producción teniendo un test que lo cubría es la consecuencia final y previsible: el test falló de verdad, alguien reintentó por costumbre, coló en el segundo intento o se ignoró el rojo.

Hay un problema secundario e independiente: 47 minutos de pipeline en un PR es demasiado. Rompe el bucle de feedback rápido —la gente cambia de tarea mientras espera— y multiplica el coste de cada reintento.

2. Beneficio perdido

Han perdido el feedback objetivo (sección 6) y, con él, la detección temprana de defectos (sección 3). El pipeline sigue ejecutándose, pero ha dejado de ser una señal fiable: un rojo ya no significa "hay un problema", significa "vuelve a intentarlo". En el momento en que el equipo deja de creerse el resultado, el pipeline pasa de activo a pasivo: cuesta dinero y da falsa seguridad. Están pagando la columna de costes íntegra sin cobrar la de beneficios.

3. Acciones por prioridad

1. Prohibir el reintento ciego y poner los flaky en cuarentena. Instrumentar la detección de tests inestables (marcar los que fallan y pasan sin cambio de código), sacarlos de la suite bloqueante y meterlos en una lista explícita con responsable y fecha límite. Objetivo inmediato: que un rojo vuelva a significar algo. Sin esto, nada más importa.
2. Arreglar los flaky de verdad, empezando por los más frecuentes. Suelen concentrarse en unos pocos: esperas fijas, dependencias del reloj, estado compartido entre tests. Atacar el top 5 elimina normalmente la mayor parte del ruido.
3. Reducir el tiempo del pipeline por debajo de 10-15 minutos en PR. Paralelizar jobs, cachear dependencias, ejecutar solo lo afectado por los ficheros modificados, y mover las suites lentas (end-to-end completas) a una ejecución posterior al merge o nocturna. Esto reduce a la vez la factura y la tentación de saltarse el proceso.

Una cuarta acción de refuerzo: publicar un panel con el porcentaje de ejecuciones verdes a la primera. Es la métrica que hace visible si el problema está mejorando o no.

En esta lección hemos puesto la balanza completa sobre la mesa:

• Los beneficios son reales y medibles: entrega más rápida (Reservalia recupera ~156 horas al año solo en tiempo de despliegue), detección temprana de defectos —cuyo coste crece drásticamente con cada fase que atraviesan—, menor riesgo por lotes pequeños, repetibilidad que elimina el bus factor, trazabilidad que responde preguntas hoy imposibles, feedback objetivo que despersonaliza la crítica, y un impacto directo en la moral del equipo y en la carga de las guardias.
• Cada beneficio tiene su forma de medirse. Un beneficio que no se mide es una opinión, y las opiniones no sobreviven a una revisión de presupuesto.
• Los costes también son reales: semanas de montaje, mantenimiento continuo, miles de minutos de runner al mes incluso en proyectos pequeños, y sobre todo el veneno de las pruebas inestables, que destruyen la señal y con ella todo el valor del sistema.
• CI/CD no es universalmente rentable. En prototipos, proyectos individuales o software fuertemente regulado, la parte de despliegue continuo aporta poco. La Integración Continua, en cambio, es rentable en casi cualquier contexto con más de una persona implicada.

Hemos mencionado varias veces que existe una forma estándar de medir todo esto: las métricas DORA. Les dedicaremos la lección 01-05 completa.

Pero antes de medir nada hay que decidir con qué herramienta vamos a construir el pipeline, y el panorama es amplio y confuso: GitHub Actions, GitLab CI, Jenkins, CircleCI, Argo CD, Tekton... En la siguiente lección, Herramientas Populares de CI/CD, dibujaremos el mapa completo del ecosistema, veremos qué categorías existen y en qué se diferencian realmente, y justificaremos por qué este curso usará GitHub Actions como herramienta principal.