Domaine : Développement de logiciels

Produits JetBrains utilisés : TeamCity

Taille de l'organisation : 200

Pays : États-Unis

Gradle

Gradle Build Tool est un outil d'automatisation de build open source populaire utilisé par des millions de développeurs et développeuses pour créer, tester et déployer des projets logiciels. Gradle est au cœur du pipeline de livraison continue de plusieurs des sociétés SaaS les plus populaires au monde, notamment LinkedIn et Netflix.

Comment Gradle Build Tool utilise TeamCity pour exécuter 30 000 builds fonctionnels par jour

Gradle Build Tool est un outil d'automatisation de build open source populaire utilisé par des millions de développeurs pour créer, tester et déployer des logiciels. TeamCity est une solution de CI/CD polyvalente qui permet de gagner en souplesse pour les workflows, la collaboration et les pratiques de développement.

Dans cette étude de cas, nous examinerons en profondeur l'utilisation de TeamCity par Gradle Build Tool pour exécuter des dizaines de milliers de builds par jour, tout en gardant le taux d'échec sous contrôle.

« TeamCity est notre système de CI de choix depuis plus d'une décennie. Il fournit d'emblée toutes les fonctionnalités dont nous avons besoin. Nous apprécions également sa fiabilité et utilisons le DSL Kotlin pour configurer nos pipelines de build. »

— Piotr Jagielski, vice-président de l'ingénierie, Gradle Build Tool

À propos de Gradle Inc.

Gradle, Inc. est l'entreprise à l'origine de Gradle Build Tool, l'un des outils d'automatisation de build open source les plus populaires, et Gradle Enterprise est la principale plateforme de solutions permettant d'améliorer la productivité des développeurs. Gradle a établi son siège social à San Francisco, en Californie, et emploie environ 200 personnes dans 30 pays pour créer son outil open source et sa plateforme d'entreprise, qui servent des millions de développeurs dans le monde.

Gradle compte plus de 100 ingénieurs qui travaillent sur deux bases de code principales : Gradle Build Tool et Gradle Enterprise. Chacune d'elle comprend des millions de lignes de code. La société utilise TeamCity pour ses deux bases de code, mais cette étude de cas se concentre sur le développement de Gradle Build Tool.


TeamCity chez Gradle Inc.

Depuis 10 ans, l'équipe Gradle Build Tool confie son processus de CI/CD à TeamCity. Pendant tout ce temps, l'équipe n'a jamais manqué une mise à jour de TeamCity. Grâce à ces mises à jour régulières, l'équipe dispose toujours de la version la plus récente et la plus riche en fonctionnalités du produit.


Pile technologique de Gradle

L'équipe Gradle Build Tool utilise Git et GitHub comme système de contrôle de version. Ses membres écrivent du code en Java, Kotlin et Groovy. Naturellement, l'équipe utilise ses propres produits, Gradle Build Tool pour l'automatisation de build et Gradle Enterprise pour l'accélération des builds et l'analyse des échecs. Ils utilisent TeamCity comme solution de CI pour exécuter tout ce qu'ils ne souhaitent pas exécuter localement : build, déploiement, tâches cron, provisionnement d'agents, etc.


Pipeline CI de Gradle

Gradle Build Tool dispose d'une suite de tests complète qui vérifie que le produit fonctionne correctement sur plusieurs systèmes d'exploitation, versions de Java et autres composants. Le build complet « prêt à être publié » comprend plus de 150 000 tests. De plus, les modifications doivent réussir la suite de tests de performance avant de pouvoir être intégrées dans la branche principale. Cela nécessite une configuration de CI complexe avec des centaines d'agents de build.

Types d'agents de builds

Gradle utilise des agents de build Windows, Linux et macOS. Environ la moitié des agents sont des machines bare metal. L'équipe utilise également des agents ponctuels Amazon EC2. Cela aide Gradle à maintenir la vitesse de build même lorsque la demande est élevée.

Grâce à la prise en charge intégrée des instances ponctuelles de TeamCity, la déconnexion des agents n'est jamais un problème pour l'équipe. TeamCity redémarre automatiquement les builds si une instance ponctuelle a disparu.

Indicateurs clés de la CI/CD

La configuration TeamCity pour Gradle Build Tool est disponible au grand public et visible par tous. La branche principale (master) se compose d'environ 500 configurations de build mises en place dans une chaîne très sophistiquée. Comme le note Piotr : « Chez Gradle, nous utilisons assez intensivement les chaînes de build. En fait, nous ne pouvons pas vivre sans elles. »

En raison de la complexité de la chaîne, Gradle s'appuie sur le DSL Kotlin pour configurer ses pipelines.

Une partie de la chaîne de build de Gradle Build Tool. Accédez à la version complète ici. Vous pouvez vous connecter en tant qu'invité pour l'afficher.
Une partie de la chaîne de build de Gradle Build Tool. Accédez à la version complète ici. Vous pouvez vous connecter en tant qu'invité pour l'afficher.

Gradle dispose de 200 agents de build fixes et de 200 agents EC2 élastiques supplémentaires pour gérer les pics, connectés à l'aide de profils cloud. La durée totale d'exécution des builds par semaine s'élève à 283 jours (ou 6 792 heures).

En parallèle, 1 636 jours par mois environ sont optimisés par TeamCity. Des algorithmes intelligents permettent à TeamCity de décider de ne pas exécuter le build lorsqu'un autre build a déjà été exécuté sur le même commit du référentiel.

Gradle utilise des chaînes de build, et TeamCity permet à l'équipe de gagner beaucoup de temps en réutilisant les builds.

Le nombre d'agents utilisés
Le nombre d'agents utilisés

Grâce à la capacité de TeamCity à fournir des statistiques de serveur compatibles Prometheus, l'équipe peut automatiquement exporter les données de build vers Grafana pour en approfondir la visualisation et l'analyse. L'équipe suit des métriques telles que le délai d'attente des builds dans la file d'attente, l'utilisation des agents TeamCity, la longueur de la file d'attente et le nombre d'agents connectés.

Sur cette base, l'équipe peut décider si elle doit acheter plus d'agents de build quand l'utilisation devient trop élevée.

Utilisation de l'agent TeamCity chez Gradle
Utilisation de l'agent TeamCity chez Gradle

Surveillance du temps de rétroaction

Fournir des retours le plus rapidement possible est au cœur de toute solution de CI. La surveillance du temps de rétroaction aide l'équipe de productivité des développeurs de Gradle à estimer le délai d'attente des ingénieurs avant que leurs requêtes d'extraction ne soient fusionnées.

Durée d'attente moyenne des builds en attente chez Gradle
Durée d'attente moyenne des builds en attente chez Gradle

Pour suivre cela, l'équipe Gradle Build Tool garde un œil sur le build Trigger, un build composite qui regroupe les résultats de plusieurs autres builds combinés par dépendances d'instantanés et les présente en un seul endroit.

Le temps de rétroaction varie en fonction de la complexité de la requête d'extraction. Les requêtes d'extraction plus simples reçoivent un retour en 10 minutes, alors que les cas plus complexes peuvent prendre jusqu'à une heure. Comme Gradle est open source, toutes les requêtes d'extraction provenant de la communauté GitHub passent par le même processus de build.

Projets de branche principale de Gradle Build Tool dans TeamCity
Projets de branche principale de Gradle Build Tool dans TeamCity

Déclencheur de build

Pour des raisons de coût, tous les commits ne déclenchent pas des builds. Au lieu de cela, les développeurs peuvent facilement déclencher un build en commentant la requête d'extraction associée. Un bot appellera l'API TeamCity pour le déclencher.

Certaines branches, comme master et release, sont traitées différemment. Tout envoi push sur ces branches déclenche un build TeamCity.

Le DSL Kotlin : une révolution

Pour l'équipe Gradle, le DSL Kotlin révolutionne la gestion de la complexité des dépendances de build. En stockant la configuration du projet sous forme de code, l'équipe peut répliquer efficacement la logique de build entre les projets, appliquer de manière cohérente les mises à jour à plusieurs configurations et gérer systématiquement ses pipelines.

Avec l'aide du DSL Kotlin, l'équipe peut générer et tester des dépendances de build avec beaucoup moins d'effort. L'équipe utilise le DSL Kotlin avec l'édition par interface utilisateur web désactivée pour presque tous ses projets.


Gradle Build Tool + TeamCity : la plus grande réussite

TeamCity accélère l'ensemble du processus de CI/CD pour Gradle. Avec l'aide de TeamCity, Gradle Build Tool exécute avec succès 30 000 builds fonctionnels par jour tout en gardant le taux d'échec sous contrôle.

Les riches fonctionnalités de TeamCity permettent d'en faire un guichet unique pour l'équipe Gradle. Il possède toutes les fonctionnalités des autres outils, ainsi que bon nombre de celles qu'ils n'ont pas.

Le DSL Kotlin donne à Gradle Build Tool un niveau de flexibilité sans précédent, qui permet à l'équipe de créer rapidement une chaîne de build complexe et de la tester. L'équipe effectue également des tests sur les fichiers de configuration du DSL Kotlin. La configuration TeamCity de Gradle est open source et disponible sur GitHub.

Enfin, l'équipe Gradle Build Tool apprécie la fiabilité de TeamCity. L'équipe opère une mise à jour vers chaque nouvelle version de TeamCity dès qu'elle est disponible et rencontre rarement des problèmes. TeamCity gère plus de 400 agents de build, mais l'équipe n'a presque jamais à résoudre de problèmes de connexion ou d'agent de build.


Faire évoluer l'infrastructure à l'avenir

L'équipe Gradle Build Tool s'engage à faire évoluer son infrastructure au fil de la croissance de l'équipe. Même si la taille de l'équipe double à l'avenir, Gradle vise à maintenir le temps de rétroaction actuel ou à le réduire encore davantage.

L'équipe Gradle Build Tool prévoit d'atteindre cet objectif ambitieux en adoptant pleinement les pratiques de Developer Productivity Engineering, en augmentant l'automatisation pour éliminer l'intervention humaine et en ajoutant davantage d'agents de build dans l'ensemble du processus de CI/CD.

Témoignages de clients similaires

Picnic

Ivan Babiankou, ingénieur logiciel en chef chez Picnic

Nous recherchions une solution gérée pour tous nos cas d'utilisation de CI. Nous avions également besoin d’agents autohébergés pour contrôler les logiciels que nous exécutons et les outils précis utilisés. TeamCity Cloud, combiné à des agents autohébergés, a fourni une solution sur mesure. Notre équipe de plus de 300 ingénieur·es l’utilise avec plaisir et elle booste notre productivité.

Gearbox

Phillip Peterson, Release Engineer senior

Nous avions un produit que nous utilisions en interne depuis longtemps. Nous avons cherché à passer à un autre concurrent, mais aucun ne faisait vraiment l’affaire. C’est alors que des collègues qui venaient d’une autre société de jeux nous ont dit : « Nous utilisions ce produit qui s’appelle TeamCity ». Nous nous sommes penchés sur la question et avons compris que TeamCity résolvait beaucoup de nos problèmes.

Playrix

Yuri Trufanov, directeur exécutif technique de la plateforme technologique

Nous nous sommes retrouvés avec une solution de cloud hybride incluant TeamCity Cloud Profiles et AWS. En plus de cela, nous disposions d’ordinateurs sur site pour les agents de build. Cette association nous a permis de prendre en charge un nombre illimité de builds tout au long de la journée, et fournit également un nombre d'agents de base pour les heures creuses. Nous pouvions ainsi exécuter ce que nous voulions, où nous le voulions.

Plus de témoignages