Industria: Desarrollo de software

Productos de JetBrains utilizados: TeamCity

Tamaño de la organización: 200

País: Estados Unidos

Gradle

Gradle Build Tool es una popular herramienta de automatización de compilación de código abierto utilizada por millones de desarrolladores para compilar, probar y desplegar proyectos de software. Gradle está en el corazón del proceso de Entrega Continua en muchas de las empresas SaaS más populares del mundo, incluyendo LinkedIn y Netflix.

Cómo utiliza TeamCity Gradle Build Tool para ejecutar 30 000 compilaciones verdes al día

Gradle Build Tool es una popular herramienta de automatización de compilación de código abierto utilizada por millones de desarrolladores para compilar, probar y desplegar software. TeamCity es una solución general de CI/CD que permite flujos de trabajo, colaboración y prácticas de desarrollo flexibles.

En este caso práctico, analizaremos en profundidad cómo Gradle Build Tool utiliza TeamCity para ejecutar decenas de miles de compilaciones al día, manteniendo la tasa de fallos bajo control.

«Hemos confiado en TeamCity como nuestro sistema de CI preferido durante más de una década. Proporciona todas las funcionalidades que necesitamos desde el momento de su instalación. También apreciamos su fiabilidad y nos gusta el DSL de Kotlin para configurar nuestros procesos de compilación».

— Piotr Jagielski, Vicepresidente de Ingeniería, Gradle Build Tool

Acerca de Gradle Inc.

Gradle, Inc. es la empresa creadora de Gradle Build Tool, una de las herramientas de automatización de la compilación de código abierto más populares, y Gradle Enterprise es la plataforma de soluciones líder para mejorar la productividad de los desarrolladores. Con sede en San Francisco, California, Gradle emplea a unas 200 personas en 30 países para crear la herramienta de código abierto y la plataforma empresarial que utilizan millones de desarrolladores en todo el mundo.

Gradle cuenta con más de 100 ingenieros que trabajan en dos bases de código principales: Gradle Build Tool y Gradle Enterprise. Cada una incluye millones de líneas de código. La empresa utiliza TeamCity para ambas bases de código, pero este caso práctico se centrará en el desarrollo de Gradle Build Tool.


TeamCity en Gradle Inc.

Durante los últimos 10 años, el equipo de Gradle Build Tool ha confiado en TeamCity para su proceso de CI/CD. Durante ese tiempo, el equipo nunca se ha perdido una actualización de TeamCity. Las actualizaciones periódicas permiten al equipo disponer siempre de la versión más reciente y con más funciones del producto.


Pila tecnológica de Gradle

El equipo de Gradle Build Tool utiliza Git y GitHub como sistema de control de versiones. Escriben código en Java, Kotlin y Groovy. Naturalmente, el equipo utiliza sus propios productos, Gradle Build Tool para la automatización de la compilación y Gradle Enterprise para la aceleración de la compilación y el análisis de fallos. Confían en TeamCity como su solución de CI para ejecutar todo aquello que no deseen ejecutar localmente: compilación, despliegue, cron jobs, aprovisionamiento de agentes, y más.


Proceso de CI de Gradle

Gradle Build Tool cuenta con un completo conjunto de pruebas que verifica que el producto funciona correctamente en diferentes sistemas operativos, versiones de Java y otros componentes. La compilación completa «lista para el lanzamiento» abarca más de 150.000 pruebas. Además, los cambios deben superar con éxito el conjunto de pruebas de rendimiento antes de poder integrarse en la rama principal. Esto requiere una compleja configuración de CI con cientos de agentes de compilación.

Tipos de agentes de compilación

Gradle utiliza agentes de compilación de Windows, Linux y macOS. Aproximadamente la mitad de los agentes son máquinas. El equipo también utiliza agentes puntuales de Amazon EC2. Esto ayuda a Gradle a mantener la velocidad de compilación incluso cuando la demanda es alta.

Gracias a la compatibilidad integrada con instancias puntuales de TeamCity, el equipo nunca tiene problemas con la desconexión de los agentes. TeamCity reinicia automáticamente las compilaciones si desaparece una instancia puntual.

Métricas clave de CI/CD

La configuración de TeamCity para Gradle Build Tool está disponible públicamente y visible para cualquiera. La rama principal (master) consta de unas 500 configuraciones de compilación establecidas en una cadena muy sofisticada. Como Piotr señala, «En Gradle, usamos cadenas de compilación en gran medida. De hecho, no podemos vivir sin ellas».

Debido a la complejidad de la cadena, Gradle se basa en el DSL de Kotlin para configurar sus procesos.

Parte de la cadena de compilación de Gradle Build Tool. Acceda a la versión completa aquí. Puede iniciar sesión como invitado para verla.
Parte de la cadena de compilación de Gradle Build Tool. Acceda a la versión completa aquí. Puede iniciar sesión como invitado para verla.

Gradle tiene 200 agentes de compilación fijos y 200 agentes EC2 elásticos adicionales para gestionar los picos conectados a través de perfiles en la nube. El tiempo total de ejecución de compilaciones por semana es de 283 días (o 6.792 horas).

Al mismo tiempo, alrededor de 1636 días al mes están siendo optimizados por TeamCity. Algoritmos inteligentes permiten a TeamCity decidir si la compilación no debe ejecutarse debido a que otra compilación ya se ha ejecutado en la misma confirmación del repositorio.

Gradle utiliza cadenas de compilación, y TeamCity ayuda al equipo a ahorrar una cantidad significativa de tiempo de compilación mediante la reutilización de compilaciones.

El número de agentes utilizados
El número de agentes utilizados

Gracias a la capacidad de TeamCity de proporcionar métricas de servidor compatibles con Prometheus, el equipo puede exportar automáticamente los datos de compilación a Grafana para su posterior visualización y análisis. El equipo realiza un seguimiento de métricas como el tiempo de espera de compilación en cola, el uso de agentes de TeamCity, la longitud de la cola y el número de agentes conectados.

En función de esto, el equipo puede decidir si necesita comprar más agentes de compilación si el uso es demasiado elevado.

Uso del agente TeamCity en Gradle
Uso del agente TeamCity en Gradle

Control del tiempo de respuesta

Proporcionar feedback lo más rápido posible es el núcleo de cualquier solución de CI. Supervisar el tiempo de feedback ayuda al equipo de productividad del desarrollador de Gradle a comprender cuánto tiempo deben esperar los ingenieros antes de que se fusionen sus solicitudes de incorporación de cambios.

Tiempo medio de espera de las compilaciones en cola en Gradle
Tiempo medio de espera de las compilaciones en cola en Gradle

Para controlarlo, el equipo de Gradle Build Tool vigila la compilación Trigger, una compilación compuesta que agrega los resultados de otras compilaciones combinadas por dependencias instantáneas y los presenta en un único lugar.

El tiempo de respuesta varía en función de la complejidad de la solicitud de incorporación de cambios. Las más sencillas reciben respuesta en 10 minutos, mientras que en los casos más complejos puede tardar hasta una hora. Dado que Gradle es de código abierto, todas las solicitudes de incorporación de cambios procedentes de la comunidad de GitHub pasan por el mismo proceso de compilación.

Proyectos de la rama maestra de Gradle Build Tool en TeamCity
Proyectos de la rama maestra de Gradle Build Tool en TeamCity

Desencadenante de compilación

Debido a los costes, no todas las confirmaciones activan compilaciones. En cambio, los desarrolladores pueden activar fácilmente una compilación comentando la solicitud de incorporación de cambios relacionada, y un bot llamará a la API de TeamCity para desencadenarla.

Algunas ramas, como master y release, se tratan de forma diferente. Cualquier push en estas ramas desencadena una compilación en TeamCity.

El DSL de Kotlin: una revolución

El DSL de Kotlin supone una gran diferencia a la hora de ayudar al equipo de Gradle a gestionar la complejidad de las dependencias de compilación. Al almacenar la configuración del proyecto como código, el equipo puede replicar eficazmente la lógica de compilación en todos los proyectos, aplicar actualizaciones de forma coherente a varias configuraciones y gestionar sistemáticamente sus procesos.

Con la ayuda del DSL de Kotlin, el equipo puede generar y probar dependencias de compilación con mucho menos esfuerzo. El equipo utiliza el DSL de Kotlin con la edición de la interfaz de usuario web desactivada para casi todos sus proyectos.


Gradle Build Tool + TeamCity: El mayor logro

TeamCity acelera todo el proceso de CI/CD para Gradle. Con la ayuda de TeamCity, Gradle Build Tool ejecuta correctamente 30 000 compilaciones verdes al día manteniendo la tasa de fallos bajo control.

TeamCity es una ventanilla única para el equipo de Gradle debido a la riqueza de sus funcionalidades. Tiene todas las características que tienen otras herramientas, además de muchas de las que no tienen.

El DSL de Kotlin proporciona a Gradle Build Tool un nivel de flexibilidad sin precedentes, que permite al equipo crear rápidamente una cadena de compilación compleja y probarla. El equipo también ejecuta pruebas en los archivos de configuración del DSL de Kotlin. La configuración de TeamCity de Gradle es de código abierto y está disponible en GitHub.

Por último, el equipo de Gradle Build Tool valora la fiabilidad de TeamCity. El equipo se actualiza a cada nueva versión de TeamCity tan pronto como está disponible y rara vez sufre algún problema. TeamCity gestiona más de 400 agentes de compilación, pero el equipo casi nunca tiene que solucionar problemas de conexión o de agentes de compilación.


Ampliación de la infraestructura

El equipo de Gradle Build Tool se ha comprometido a garantizar que su infraestructura se adapte al crecimiento del equipo. Incluso si el tamaño del equipo se duplica en el futuro, Gradle pretende mantener el tiempo de respuesta actual o reducirlo aún más.

El equipo de Gradle Build Tool planea alcanzar ese ambicioso objetivo adoptando plenamente las prácticas de ingeniería de productividad del desarrollador, aumentando la automatización para eliminar la intervención humana y añadiendo más agentes de compilación a todo el proceso de CI/CD.

Historias de clientes similares

Picnic

Ivan Babiankou, ingeniero de software de Picnic

Buscábamos una solución gestionada para todos nuestros usos de IC. Además, necesitábamos agentes autohospedados para controlar qué software se ejecuta y qué herramientas exactas se utilizan. TeamCity Cloud con agentes autohospedados es una solución a medida que encanta a nuestro equipo, compuesto por más de 300 ingenieros, y que mejora muchísimo nuestra productividad.

Gearbox

Phillip Peterson, ingeniero sénior de versiones

Teníamos un producto que habíamos utilizado internamente durante mucho tiempo. Intentamos cambiar a otro producto de la competencia, pero ninguna de las dos opciones funcionó. Así que unos colegas nuestros que venían de otra empresa de juegos nos dijeron: «Solíamos utilizar eso que llaman TeamCity». Lo investigamos y comprendimos que TeamCity resolvía muchos de nuestros problemas.

Playrix

Yuri Trufanov, director técnico ejecutivo de la plataforma tecnológica

Terminamos con una solución de nube híbrida que incluía TeamCity Cloud Profiles y AWS. Además, disponíamos de ordenadores locales para los agentes de compilación. Esta combinación nos permitió acomodar cualquier número de compilaciones a lo largo del día, al tiempo que nos proporcionaba un mínimo de agentes para las horas no laborables. Así que podíamos ejecutar lo que quisiéramos donde quisiéramos.

Más historias de clientes