Comment l'équipe IntelliJ Infrastructure réduit le temps d'exécution des builds de 30 % grâce à TeamCity

Le défi : gérer des pipelines de CI/CD pour des centaines de développeurs

Avec une grande équipe de développeurs qui envoient constamment des modifications, maintenir des pipelines de CI/CD rapides, fiables et évolutifs n'est pas simple. L'équipe IntelliJ Infrastructure a besoin d'une solution capable de gérer une échelle massive, avec la possibilité d'exécuter des milliers de builds par jour sans surcharger les ressources disponibles. Elle a également besoin d'une automatisation intelligente pour minimiser les interventions manuelles tout en garantissant la livraison d'un code de haute qualité.

La prise en charge de divers environnements d'infrastructure, notamment les agents sur site, AWS, macOS, Linux et Windows, est également cruciale. Pour maintenir une qualité de code élevée, l'équipe doit gérer des centaines de milliers de tests automatisés et minimiser les échecs de tests bancals.

TeamCity, une puissante solution de CI/CD développée par JetBrains, s'est avérée être la solution idéale pour relever ces défis.

« Nous créons des IDE et tout ce qui s'y rapporte dans TeamCity, comme les services internes, les services de statistiques, etc. Je suis très habitué à TeamCity et j'ai l'impression que c'est comme un marteau dans ma main : on peut tout faire avec. »

— Dmitrii Panov, responsable technique IntelliJ Infrastructure

Comment TeamCity aide l'équipe IntelliJ Infrastructure

Safe Push

Le processus de l'équipe IntelliJ élargie implique actuellement que chaque développeur pousse le code dès qu'il est prêt, sans accumuler toutes les modifications dans une branche et attendre qu'elles soient testées ensemble.

Pour prendre en charge ce workflow, l'équipe IntelliJ Infrastructure a implémenté le mécanisme Safe Push, qui est essentiellement un ensemble de configurations de build composites dans TeamCity. Pour les utilisateurs, le processus est assez simple : ils envoient simplement les modifications en mode push via leurs IDE et c'est tout.

En arrière-plan, un service interne dédié analyse l'ensemble des modifications Safe Push et utilise l'API REST TeamCity pour déclencher les builds nécessaires afin de tester les modifications. Il redémarre également les builds ayant échoué pour réessayer les tests bancals.

En permettant de réutiliser les builds réussis, TeamCity accélère considérablement les Safe Push et réduit leur coût, car le build des tests Safe Push peut contenir jusqu'à 700 000 tests. La fonctionnalité de réutilisation des builds réutilise les artefacts, les dépendances et les résultats de test au lieu de tout générer à partir de zéro. Cela améliore l'efficacité du build, accélère les pipelines de CI/CD et réduit la consommation de ressources.

Économies de ressources grâce à la réutilisation des builds

La réutilisation des builds est l'une des fonctionnalités de TeamCity que l'équipe trouve particulièrement utile. Voici à quoi ressemble typiquement une chaîne de build TeamCity.

Lorsqu'une chaîne de test ne réussit pas à la première tentative, le mécanisme Safe Push la réessaie deux fois de plus pour confirmer qu'il y a bien un problème.

Considérons un push typique pour voir comment la réutilisation des builds optimise les nouvelles tentatives. Lors de la première tentative, les 329 builds de la chaîne sont exécutés. 319 réussissent, mais 10 échouent, donc la chaîne est relancée. Cette fois, seuls les 10 builds ayant échoué sont exécutés : le reste est réutilisé. 6 autres réussissent, mais il en reste 4. Ainsi, à la troisième tentative, les 4 derniers doivent être exécutés, mais 325 sont réutilisés.

Cela réduit radicalement la charge qui pèse sur les agents de build et accélère considérablement les délais avant nouvelle tentative. Au lieu d'exécuter trois tentatives complètes (prenant chacune environ 3 heures), la réutilisation du build réduit le temps d'exécution d'environ 30 %.

Prise en charge d'une évolutivité massive avec des performances sans faille

L'équipe IntelliJ exécute plus de 158 000 builds pour plus de 180 utilisateurs uniques par jour. L'efficacité est donc essentielle. Grâce aux capacités de réutilisation des builds de TeamCity :

• 75 % des builds n'ont pas besoin d'être entièrement réexécutés lors de l'échec d'un test.
• Les délais de nouvelle tentative baissent de 30 % en moyenne, ce qui réduit considérablement les goulets d'étranglement.
• Les développeurs peuvent fusionner en continu sans se bloquer mutuellement, car plus de 90 tests Safe Push peuvent s'exécuter en même temps.

DSL Kotlin

L'équipe IntelliJ Infrastructure gère TeamCity à l'aide du DSL Kotlin. Grâce au DSL Kotlin, vous bénéficiez de tous les avantages d'un langage de programmation complet, associés à ceux d'un DSL conçu pour créer des pipelines en tant que code.

Actuellement, l'instance TeamCity contient plus de 2 000 projets, 15 000 configurations de build et près de 300 racines VCS. L'équipe ne peut pas s'imaginer gérer une instance aussi énorme à l'aide d'autre chose que le DSL Kotlin.

« Nous avons également près de 350 tests unitaires uniquement pour les paramètres Kotlin eux-mêmes. Je ne voudrais pas avoir cette expérience en YAML. »

— Dmitrii Panov, responsable technique IntelliJ Infrastructure

Gestion des agents

Les puissantes capacités de gestion des agents de TeamCity rendent la mise à l'échelle des pipelines de CI/CD facile et efficace. Contrairement aux systèmes de CI/CD basés sur YAML qui nécessitent des solutions de contournement complexes, telles que des ancres, des instructions go-to et une logique manuelle de nouvelle tentative, TeamCity simplifie ce processus grâce à l'orchestration d'agents intégrée.

Pour les équipes utilisant AWS, TeamCity s'intègre de manière transparente à l'infrastructure cloud, ce qui permet aux agents d'être automatiquement lancés et gérés en fonction de la demande. Vous pouvez par exemple configurer TeamCity pour qu'il lance exactement le nombre d'agents requis dans une situation donnée et les arrête lorsqu'ils sont inactifs, afin d'optimiser l'utilisation des ressources.

Ce niveau de contrôle précis des agents est beaucoup plus intuitif par rapport à d'autres solutions, dans lesquelles des plugins externes peuvent introduire des problèmes de compatibilité et nécessiter un dépannage supplémentaire.

À grande échelle, TeamCity gère des charges de travail massives : il prend en charge des files d'attente de plus de 10 000 builds et gère jusqu'à 5 000 agents de build de manière dynamique. L'une des fonctionnalités les plus remarquables de TeamCity est sa capacité à travailler avec des instances AWS préemptives. Si une instance est récupérée par AWS, TeamCity peut automatiquement redémarrer le build sur un autre agent, ce qui évite les interruptions et garantit une exécution fluide.

Indicateurs suivis par l'équipe

Lorsque vous gérez une plateforme de CI/CD pour des centaines de développeurs, avec des dizaines de milliers de builds par jour, il est important de garder une trace des métriques les plus importantes. TeamCity fournit un certain nombre d'outils de diagnostic et d'indicateurs prêts à l'emploi. Et comme TeamCity peut également exporter des métriques au format Prometheus, vous pouvez créer des tableaux de bord personnalisés pour des cas d'utilisation plus avancés.

« TeamCity nous fournit quelques éléments de base, par exemple des statistiques pour les builds ou les tests. Nous pouvons ensuite construire quelque chose de plus sophistiqué sur ces structures de base. »

— Aleksei Smirnov, développeur logiciel au sein de l'équipe .NET Infrastructure

Voici les principaux indicateurs que l'équipe IntelliJ Infrastructure surveille de près pour optimiser son processus de CI/CD avec TeamCity.

Nombre de builds par jour

L'équipe surveille environ 158 000 builds par jour pour comprendre la charge de travail et les performances. Bien que le nombre de builds ne soit pas en soi un indicateur auquel l'équipe accorde une attention particulière, cela reste une métrique importante pour prédire la charge de travail des agents de build.

Simultanéité des envois Safe Push

À tout moment, 80 à 90 vérifications Safe Push s'exécutent simultanément. Il est important pour l'équipe de suivre la durée de chaque vérification Safe Push : plus elle s'exécute vite, plus le build s'exécute vite.

Efficacité de la réutilisation des builds

L'équipe analyse le nombre de builds réutilisés lors des nouvelles tentatives, ce qui réduit le besoin d'exécution redondante et économise des ressources.

Exécution des tests

Il y a près de 700 000 tests dans un même build composite dans le projet TeamCity d'IntelliJ.

L'équipe suit plus de 700 000 tests par chaîne Safe Push pour identifier les défaillances. L'équipe mesure également l'instabilité des tests, en réessayant automatiquement les tests ayant échoué et en ignorant les tests instables pour une enquête ultérieure plus approfondie.

L'une des métriques que l'équipe essaie d'améliorer est le nombre de tentatives nécessaires pour une exécution réussie. Cela l'aidera à économiser des ressources et du temps à chaque exécution.

Utilisation des agents

L'équipe surveille plus de 5 000 agents de build AWS et physiques, en optimisant l'allocation des ressources grâce à des fonctionnalités telles que la réutilisation des builds, ce qui permet de réduire le temps de build d'environ 30 %.

Pistes d'amélioration pour TeamCity

Bien que l'équipe IntelliJ Infrastructure utilise TeamCity au quotidien pour un grand nombre de tâches et remarque que cela l'aide à résoudre de nombreux problèmes, il y a quelques éléments qu'elle aimerait y voir ajoutés.

Fonctionnalités spécifiques à l'équipe

Bien que TeamCity permette d'accéder à toutes les chaînes de builds et à tous les projets au sein d'une organisation, les développeurs ont souvent besoin d'une vue plus ciblée des builds qui les concernent. Par exemple, un développeur travaillant sur PyCharm devrait idéalement ne voir que les builds, tests et configurations spécifiques à PyCharm sans avoir à naviguer dans des projets sans aucun rapport.

Un tableau de bord simplifié, affichant uniquement les informations pertinentes en matière de configurations de build, de tests et de tests ignorés, améliorerait considérablement la convivialité. L'équipe a tenté de résoudre ce problème en créant une solution basée sur Grafana, mais une approche plus intégrée et conviviale au sein de TeamCity serait idéale.

Gestion des tests ignorés

L'équipe estime que TeamCity bénéficierait grandement d'un système de gestion des tests ignorés. Compte tenu du volume élevé de tests automatisés, certains tests doivent inévitablement être ignorés. Bien que TeamCity offre une fonctionnalité permettant d'ignorer des tests, il est toujours très facile d'ignorer un test et d'oublier de le réactiver, ce qui complique le travail des collègues qui doivent aussi l'utiliser.

Un système de gestion dédié pour les tests ignorés, permettant aux équipes de facilement visualiser, gérer et suivre les tests ignorés pertinents pour leurs projets, contribuerait à une meilleure responsabilisation et une plus grande transparence.

Conclusion

L'équipe IntelliJ Infrastructure a atteint une efficacité de CI/CD à grande échelle avec TeamCity, en rationalisant les builds, en optimisant l'utilisation des ressources et en réduisant considérablement les temps d'exécution. Grâce à Safe Push, à la réutilisation des builds et à l'automatisation des nouvelles tentatives de test, elle a réduit de 30 % les temps d'exécution des builds, ce qui permet à 700 à 800 développeurs d'apporter des modifications en mode push avec fluidité.

Le témoignage de l'équipe IntelliJ Infrastructure prouve que TeamCity n'est pas qu'un outil de CI/CD : c'est l'épine dorsale du développement de logiciels à grande échelle.