La integración continua (CI) se ha convertido en uno de los pilares fundamentales para equipos de desarrollo modernos, especialmente en entornos donde la agilidad y rapidez en la entrega de software son esenciales. Sin embargo, muchas organizaciones enfrentan un desafío común: el tiempo excesivo que consumen sus flujos de CI y los costos asociados a esta infraestructura. La historia de cómo un equipo logró reducir el tiempo de ejecución de sus procesos de integración continua en un 80% y sus costos en un 45% ofrece un caso práctico y valioso para cualquier desarrollador o responsable de DevOps que busque optimizar su pipeline. El equipo trabajaba con un repositorio monolítico donde coexistían múltiples proyectos, entre los cuales destacaba una aplicación web basada en SvelteKit que se ejecutaba en aproximadamente 17 minutos durante cada compilación de CI. Este tiempo se volvía frustrante debido a la frecuencia con la que se activaba el flujo de trabajo, llegando a ejecutarse entre 50 y 100 veces en una sola jornada laboral.
El flujo de trabajo original constaba de siete etapas distintas, siendo la instalación y compilación de dependencias las que más tiempo consumían, casi cinco minutos. La solución aplicada consistió en una combinación de cambios estratégicos y tecnológicos que implicaron una revisión profunda del proceso de CI. El primer salto de eficiencia se logró al cambiar el gestor de paquetes de NPM a PNPM. La diferencia entre ambos radica en cómo manejan la instalación y el almacenamiento de dependencias. Mientras NPM instalaba cada dependencia repetidamente para cada paquete dentro del monorepo, PNPM utiliza un almacén global y enlaces simbólicos (symlinks), lo que no solo reduce el espacio ocupado en disco, sino que también acelera el proceso de instalación al evitar duplicidades innecesarias.
Esta transición permitió que el tiempo invertido en la preparación del entorno de CI disminuyera alrededor de un 74%. Además, PNPM ofreció nuevas funcionalidades que simplificaron el mantenimiento de scripts personalizados, como la opción de filtrar y construir únicamente las dependencias necesarias para un paquete específico, facilitando la gestión y aumentando la velocidad general. Más allá de acelerar la instalación, el equipo implementó un sistema de caché para las dependencias y los artefactos de compilación. La particularidad de PNPM de almacenar las dependencias en un entorno centralizado facilitó enormemente esta tarea. Al guardar estos datos en un caché y restaurarlos en cada ejecución de CI, se evitó la necesidad de reinstalar y recompilar constantemente, especialmente útil cuando los cambios en el código eran mínimos y las dependencias permanecían iguales.
Este método se extendió a las bibliotecas compartidas dentro del monorepo, asegurando que sus compilaciones se reutilizaran cuando no hubiera modificaciones relevantes, evitando así tiempo muerto. Con la instalación y compilación optimizadas, la atención se desplazó a la estructura completa de los flujos de trabajo. En un inicio, todas las etapas se ejecutaban de forma secuencial, lo que generaba esperas innecesarias. Con el entorno más ágil, fue posible dividir el flujo en múltiples trabajos que se ejecutan en paralelo. Esto no solo redujo el tiempo total de ejecución en función del trabajo más largo, sino que también mejoró significativamente la percepción de velocidad para los desarrolladores.
Sin embargo, paralelizar flujos trajo el reto de incrementar los costos, dado que el uso simultáneo de más recursos implica un mayor gasto. Aquí fue donde una transición a otro proveedor de runners tuvo un impacto decisivo. Blacksmith, una plataforma emergente que ofrece una compatibilidad total con GitHub Actions pero con mejor rendimiento y precios más competitivos, fue la solución para mitigar el aumento de costes provocado por la paralelización. Cambiar a Blacksmith implicó modificar de forma sencilla la configuración del entorno, reemplazando versiones de runners y de acciones específicas, logrando un entorno más eficiente y económico. La migración produjo un aumento del rendimiento del 22%, algo inferior al doble prometido, pero aún así un salto considerable.
Lo más relevante fue la reducción del gasto en infraestructura en un 45%, lo que tradujo en un ahorro sustancial para la empresa. Con todas estas mejoras combinadas, el equipo pasó de esperar 17 minutos en cada ejecución de CI a tiempos significativamente menores, liberando a los desarrolladores de las esperas interminables y permitiéndoles centrarse en el verdadero trabajo creativo: construir y mejorar el producto. Esta historia muestra la importancia de analizar y optimizar cada componente del pipeline de integración continua, desde la elección del gestor de paquetes hasta la selección de la infraestructura para ejecutarlas. Además, demuestra que cada decisión técnica puede tener un impacto directo y notable en la productividad y en los costes operacionales. Finalmente, aunque estas mejoras han sido fundamentales, el equipo reconoce que todavía hay aspectos por mejorar.
