El pipeline de desarrollo también es un sistema en producción

Fuentes: The development pipeline is a production system

La cadena que conecta una petición del cliente con su entrega —desde el sistema de tickets, pasando por el IDE, los compiladores, los repositorios de paquetes, las pruebas automáticas, el entorno de QA y las herramientas de integración y despliegue continuo (CI/CD)— debería tratarse como un sistema en producción: cualquier eslabón roto bloquea al equipo entero. Esta es la tesis central de un artículo firmado por un ingeniero de software que denuncia un desequilibrio habitual en las organizaciones: las caídas del servicio al cliente movilizan al personal con la máxima urgencia, pero los fallos en las herramientas internas que usan desarrolladores, QA y equipos de operaciones rara vez reciben la misma respuesta. Cuando el código no compila, los desarrolladores no pueden trabajar; cuando el servidor de QA está caído, los probadores no pueden validar; cuando una suite de tests falla de forma crónica, nadie debería desplegar a producción. Para estas personas, la avería es, de hecho, un corte de producción, y debería corregirse con la misma prioridad.

El texto compara la situación con la fabricación industrial, donde existen manuales y procedimientos detallados para minimizar el tiempo de inactividad de la línea de montaje, y con la disciplina SRE (Site Reliability Engineering) de Google, que documenta cómo gestionar incidentes de servicio. Sin embargo, la mayoría de estos marcos se centran en las caídas del producto final, no en las herramientas que mantienen en pie a quienes construyen y operan ese producto. La recomendación concreta del autor es que los equipos adopten procedimientos y SLAs de escalado similares para sus propios pipelines, identificando cada componente —issues de GitHub, Jira, IDEs, Gradle, Maven, npm, Maven Central, Jenkins, GitHub Actions y cualquier otro paso que impida desplegar cambios— y tratándolo como infraestructura crítica. La moraleja es directa: un equipo con su pipeline roto no puede producir software, y esa interrupción debe gestionarse como cualquier otra incidencia grave de producción.