Reduciendo a la Mitad Tu CI Pipeline – Estrategias Prácticas de Optimización

Hola, soy Serhii, y hoy vamos a hablar sobre cómo podemos reducir a la mitad tu pipeline de CI con algunas estrategias prácticas de optimización. En nuestra organización, con alrededor de 50 solicitudes de merge al día y 400 pipelines ejecutados, incluidos los merge trains, un minuto de sobrecarga en tu pipeline de CI cuesta casi seis a siete horas de tiempo de ingeniería cada día. Ahora, puedes pensar en tu organización y escalar esto en consecuencia. Esta es una charla sobre cómo reducimos nuestro pipeline de merge train de aproximadamente una hora a 22 minutos. Es una reducción del 64% utilizando un enfoque estructurado priorizado por ROI.

Cinco áreas en el orden en que las usamos, con números reales para nuestro SaaS legal tech de 400 personas donde la mitad de las personas son desarrolladores. Así que esta fue nuestra línea de partida. Pipeline de merge train, aproximadamente una hora. Salud de CI, la tasa de éxito sin reintentos es de alrededor del 82%, $16,000 al mes en AWS compute. Y la queja tonta en nuestra encuesta de experiencia de desarrollador fue simplemente la velocidad del pipeline. Así que el número que más importaba no era la duración, era la tasa de fallos. Casi uno de cada cinco intentos de merge fallaba.

Los reintentos se convirtieron en memoria muscular. La gente dejó de confiar en el sistema. Una vez que los desarrolladores dejaron de confiar en CI, todas las demás métricas de ingeniería comenzaron a deslizarse, también. Ahora, la mayoría de los equipos abordan la optimización de CI generalmente al revés. Comienzan con victorias rápidas y fáciles porque las victorias rápidas se pueden implementar en una tarde. Yo en realidad comencé diferente. Así que comenzamos con una tabla, cada posible optimización calificada por el tiempo esperado de ahorro, esfuerzo y riesgo. Así que la migración de instancias fue la mayor palanca única.

12 minutos, así que fue primero. Ajustes de observabilidad en un minuto y medio fueron después, aunque eran los más fáciles. Así que nos enfocamos primero en el alto impacto, victorias rápidas en paralelo, y ajustes finos al final. Elige las batallas correctas antes de lucharlas. La mayor victoria única vino de la migración de instancias de cómputo para nuestra característica, o de extremo a extremo para probar, como los llames, que siempre se consideran lentos, inestables y pesados. Probé tres configuraciones diferentes alrededor de 10 ejecuciones cada una porque un pipeline lento puede arruinar tu promedio. Así que la primera instancia fue C7a basada en AMD, promedió 25 minutos, pero en realidad osciló entre 22 a 32 minutos, realmente muy variado. La segunda opción fue C7i basada en Intel, y en general fue más lenta, 27 minutos, pero la variación fue solo de 24 a 30. Así que en realidad elegimos Intel. ¿Por qué? En un merge train, la variación es más dañina que el rendimiento medio.

Una sola ejecución lenta bloquea cada merge detrás. Así que tomamos una decisión. Y también, añadimos algunos trabajadores adicionales al C7i, y llegamos a 22 a 36 en promedio, 12 minutos y medio de cada ejecución de merge train.

El siguiente nivel fue el dimensionamiento del entorno de prueba. Teníamos 30 nodos de prueba, y todos llevaban Chrome. Esto tenía sentido para pruebas de características y/o de extremo a extremo, pero no para pruebas de servicio, que nunca abren el navegador. Chrome nos costaba aproximadamente 0.4 gigabytes por trabajador. En todo el pool antiguo, eso era alrededor de 12 gigabytes de sobrecarga del navegador.

No pudimos eliminar todo porque la mayoría de las pruebas aún necesitan Chrome, pero movimos las diapositivas de prueba de servicio a nodos ligeros sin navegador y mantuvimos Chrome solo donde realmente era necesario. Eso recuperó alrededor de 2 gigabytes por ejecución y tomó alrededor de tres minutos del merge train. El único riesgo era la confianza. Cuando divides un conjunto, puedes dejar de probar algo accidentalmente. Así que añadimos un validador de cobertura de línea y rama como barandilla.

Así que la lección fue simple. Eliminar peso innecesario, pero mantener la confianza. Un CI más rápido solo importa si los desarrolladores aún creen en el resultado. Así que tres cambios, cada uno tomando un día para implementar. Uno, nuestra colección de métricas del servicio de observabilidad tomaba 120 segundos por pipeline. Cada ejecución de CI estaba utilizando una API síncrona obsoleta. Así que la migramos a un reemplazo por lotes, reduciendo a 20 segundos.

Dos, pre-tiered, precached, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered, pre-tiered. Echemos un vistazo a la solicitud de merge solo de documentación. Incluso teniendo algunos observadores al día, se evitaron pipelines completos, ahorrando alrededor de 240 al mes en computación, medio día de trabajo, y combinados 3.5 días de trabajo, 3.5 minutos de cada pipeline, pequeños individualmente pero se combinan juntos. La velocidad fue una mitad fácil. La estabilidad fue una mitad más difícil. Tasa de fallos del 18%.

La gente había aprendido a hacer clic en reintentar sin leer el fallo. Además, teníamos un mecanismo incorporado para reintentar pruebas que estaba añadiendo un bucle adicional de pruebas, y por supuesto, era un proceso que consumía tiempo. Así que construí un sistema que va más allá de los conteos de reintentos ingenuos. Cuando una prueba falla en tres diferentes solicitudes de merge en una ventana de 12 horas, usualmente en divs no relacionados, se marca como persistent flaky. El clasificador utiliza un LLM más el git diff para distinguir un verdadero error de producto de un flake.

Así que las pruebas marcadas se ponen en cuarentena automáticamente. El AirSpec QA Runner, que es nuestro runner personalizado sobre la biblioteca de pruebas Ruby AirSpec, las omite. Redis TTL expira automáticamente la cuarentena si el problema realmente se soluciona. Cada decisión se publica en un mensaje de Slack. ¿Resultado? Más de 30 pruebas inestables se omiten permanentemente y luego se corrigen. La salud de CI pasó del 82 al 94%.

Todo el sistema cuesta alrededor de $100 al mes en llamadas LLM. Aquí está la parte contraintuitiva. Gastamos más en infraestructura porque usamos runners más pesados. Nos cuesta alrededor de $1,680 más por mes. Instancias Intel más grandes, más trabajadores. La factura de infraestructura aumentó aproximadamente un 10%. Pero el tiempo que recuperamos es de alrededor de 1,300 horas de ingeniero al mes. Y a un conservador $50 por hora, eso es en realidad como $65,000 al mes en un problema de productividad. Creo que la lección principal aquí es que optimizar para el costo de CI más bajo no es lo mismo que optimizar para el costo total más bajo. Gastar más en las cosas correctas se paga muchas veces.

Así que los números principales. Merge train de aproximadamente una hora a 22 minutos. Reducción del 64%. Salud de CI del 82% al 94%. La línea interesante está realmente en la parte inferior. Durante el mismo período, nuestra suite de pruebas creció un 90%. De 10,000 pruebas a 19,000. El tiempo de pipeline creció solo un 11%. El trabajo de optimización absorbió el crecimiento de la suite de pruebas. La cobertura de pruebas aumentó, el tiempo de pipeline disminuyó. Ambos a la vez. Entonces, ¿qué deberías llevarte de mi historia? Primero, mide antes de optimizar. No una ejecución, no tres ejecuciones. Suficientes ejecuciones para entender el patrón porque el rendimiento de CI miente cuando solo miras el promedio.

Segundo, prioriza por retorno, no por conveniencia. Algunas soluciones fáciles valen la pena, pero no deberían distraerte de la palanca más grande.

Tercero, optimiza todo el sistema. En nuestro caso, solo la velocidad no habría resuelto el problema. También tuvimos que mejorar la estabilidad, proteger la cobertura y hacer que la compensación de costos fuera viable. Así es como pasamos de un merge train de una hora a aproximadamente 22 minutos y el test suite casi se duplicó.

Así que mi consejo es simple. Vuelve a tu pipeline, mide dónde realmente se va el tiempo, asigna dinero y horas de ingeniería a ello, y probablemente encontrarás uno de los proyectos de ingeniería de mayor retorno en tu base de código. Eso es prácticamente todo. Gracias por ver. Así que los principios que he compartido son portátiles, pero cada pipeline es diferente. Si quieres comparar notas sobre lo que funcionó o no para tu equipo, encuéntrame en LinkedIn en la URL en la pantalla. Estoy feliz de hablar sobre tu tabla de ROI, tus benchmarks en la parte superior, o tu estrategia de pruebas inestables. Hasta entonces, ve y mide tu pipeline. Gracias, GSTation.