¿Cómo Linear Cut redujo el tiempo de espera de más de 6 minutos a menos de 5? )

Linear, la herramienta de gestión de proyectos, ha publicado una publicación de ingeniería titulada «Los costos de CI son altos», y el título es preciso: la compañía explica cómo redujo su tiempo de espera de integración continua de más de 6 minutos a poco más de 5, al mismo tiempo que redujo a la mitad el tiempo de ejecución por prueba. La publicación es una clase magistral en optimización del rendimiento, y vale la pena leerla para cualquiera que haya visto cómo las canalizaciones de CI se ralentizan a medida que crece su base de código.

El problema era sencillo. Los desarrolladores de Linear estaban introduciendo código en producción más rápido de lo que el sistema podía verificarlo en busca de errores. Las solicitudes de extracción aún debían pasar por CI, pero a medida que la velocidad de desarrollo aumentaba, la canalización comenzó a ralentizarse, convirtiéndose en un cuello de botella. Eso elevó los costos de infraestructura y dejó a los agentes esperando más tiempo para recibir comentarios, lo cual es lo contrario de lo que se supone que debe hacer CI.

Los Cuatro Caminos hacia un CI Más Rápido

Se probaron cuatro enfoques distintos, cada uno de ellos desglosado con cifras específicas en la publicación, a medida que los ingenieros de Linear avanzaban por todos los frentes.

1. Actualización de la infraestructura y las herramientas
2. Optimización de los trabajos que bloquean a otros trabajos
3. Reducción de la configuración repetida
4. Mejora de la eficiencia de la ejecución de pruebas

Los elementos más interesantes son los dos primeros, ya que requieren cambios reales en el sistema en lugar de simplemente ajustar el código. Los dos últimos se tratan más sobre la refactorización y el proceso, pero aún marcaron una diferencia.

Actualización de las Máquinas

Linear obtuvo sus primeras ganancias al eliminar sus cargas de trabajo de CI de GitHub Actions y trasladarlas a corredores de terceros que ofrecían CPUs más rápidas, almacenamiento de mayor rendimiento e infraestructura de caché mejorada. Una comparación de «uno a uno» de los dos días antes y después del cambio mostró que los trabajos se ejecutaban un 34% más rápido en promedio. Algunos trabajos, como tsc, vieron reducciones en la duración de 52%.

Ese es el tipo de victoria que se produce cuando deja de alquilar las máquinas lentas de otra persona y compra las suyas propias. Esto no requirió casi ningún ajuste de CI en sí mismo, lo cual es algo raro.

El cambio de compilador que movió el cuello de botella.

El cambio de compilador fue el siguiente. Linear pasó a tsgo, el compilador nativo de TypeScript, y ese cambio redujo el valor semanal medio de tsc check en un 73%. La reducción fue suficiente para eliminar por completo el cuello de botella de la verificación de tipos.

Realmente se siente como magia cuando cambias una herramienta y la canalización deja de verse ralentizada por un paso que antes consumía la mayor parte de su tiempo. La publicación no hace ningún esfuerzo para suavizar la escala del cambio — un 73% no es un pequeño ajuste, es una transformación completa.

«Obtén solo lo que cada trabajo necesita».

Linting Sin el Verificador de Tipos.

Corregir el problema de memoria con el linting fue otro objetivo temprano. Varias de las reglas de linting personalizadas de Linear dependían de la información de tipo de TypeScript, ya sea para aplicar una restricción o aplicar una autocorrección. Entonces, cada ejecución de lint tenía que construir el gráfico de tipos completo antes de evaluar esas reglas, y eso hizo que el linting fuera uno de los trabajos de CI más intensivos en memoria.

ESLint eliminó TypeScript después de que Linear utilizó el análisis estático del árbol de sintaxis abstracta para detectar estructuras similares a funciones y patrones de protección sin requerir información de tipo. Ese enfoque redujo el tiempo de linting de la API en un 68%, redujo el tiempo de linting de todo el repositorio en un 55% y redujo sustancialmente el uso de memoria.

El momento de la recompensa llegó después de que Linear cambió a Oxlint, lo que redujo los minutos de ejecución de lint en el corredor de CI.

Corregir la Suspensión del Checkout.

La mejor parte de la historia es la corrección del checkout. Después de que Linear cambió el sistema en el que se ejecuta, la empresa descubrió que el checkout de código estaba tardando más y a veces se detenía. Dado que los corredores de terceros viven fuera de la red de GitHub, dependen de un enlace IP directo para llegar a GitHub. Ese enlace fue la fuente de las suspensiones, según los hallazgos del proveedor.

Varios de los flujos de trabajo de Linear comienzan con un checkout, por lo que una recuperación detenida podría retrasar toda la ejecución de CI. La respuesta de Linear fue reemplazar actions/checkout con una acción compuesta propia que intentó nuevamente con retroceso, y configuró GIT_HTTP_LOW_SPEED_LIMIT y GIT_HTTP_LOW_SPEED_TIME para que una conexión detenida se interrumpa después de aproximadamente 30 segundos en lugar de detenerse. También utilizó la caché de checkout, que mantiene un espejo de git persistente en un disco pegajoso.

Menos ejecuciones vieron una tarea crítica-ruta quedándose inactiva mientras el checkout tomaba su tiempo finalizando.

La Solución de la Cola de Combinación

Linear identificó tareas en la ruta crítica que no eran necesarias. La empresa estaba escribiendo marcadores de caché como parte de la revisión final antes de combinar, lo que significaba que una solicitud de extracción podría permanecer en la cola de combinación incluso después de que sus pruebas hubieran pasado. Desplazar esa escritura a un trabajo que se ejecuta después de que las fragmentaciones de prueba finalicen pero no bloquea nada recortó 42 segundos de la ruta de combinación para cada solicitud de API y entrada de cola de combinación.

Los ajustes combinados redujeron el tiempo de verificación de la solicitud de extracción de API en fallas de caché en aproximadamente un minuto, y también redujeron el número de inicios de runners.

Lo que Esto Significa para Usted

Cualquier persona que construya pipelines de CI debería leer esta historia, ya que los problemas que enfrentó Linear son universales. Los cuellos de botella de CI surgen cuando las pipelines tardan mucho en comenzar, mucho en ejecutarse y mucho en fallar. Linear se enfocó en cada una de esas dimensiones, y los resultados son tangibles.

El rendimiento de CI es un problema del sistema, no un problema de código. No importa cuán rápido se ejecuten sus pruebas si su pipeline pasa la mitad de su tiempo iniciando un runner o descargando un repositorio — las pruebas no significan nada. La tarea real es localizar dónde se está gastando el tiempo y eliminarlo.

Linear se movió con cuidado y deliberación. Midió el terreno primero, le dio un nombre al problema y lo abordó desde varias direcciones a la vez. La publicación es abierta sobre lo que tuvo éxito y lo que fracasó, y da la impresión de un equipo que realmente quería abordar el problema en lugar de simplemente publicar una entrada de blog.

La historia muestra que la optimización del rendimiento no surge de la magia. Se construye a partir de una larga cadena de pequeños cambios graduales que eventualmente se convierten en un resultado importante. El pipeline de CI de Linear ahora es más rápido y rentable, y la empresa dedicó algunos meses para llegar a ese punto.

Esta publicación ofrece una mirada a la fricción que se acumula en una pipeline a medida que se expande una base de código, y demuestra lo que sucede cuando mide esos puntos de fricción y los aborda uno tras otro. Si está configurando CI para una base de código en crecimiento, vale la pena su tiempo.

Los altos costos de CI no ocurrieron por accidente; se permitieron acumularse. Linear no aceptó ese camino. En cambio, midió, optimizó y publicó sus resultados, demostrando que la forma correcta de manejar la ingeniería es a través de la medición y la transparencia en lugar de la aceptación.

Fuente: “La codificación con IA ha convertido el CI en un cuello de botella, por lo que lo rediseñamos para mantener el ritmo”, linear.app.