Industrie: Software­entwicklung

Verwendete JetBrains-Produkte: TeamCity

Organisationsgröße: 200

Land: Vereinigte Staaten

Gradle

Gradle Build Tool ist ein beliebtes Open-Source-Automatisierungstool, das millionenfach zum Erstellen, Testen und Bereitstellen von Softwareprojekten verwendet wird. Gradle bildet das Herzstück der Continuous-Delivery-Pipeline bei vielen der weltweit populärsten SaaS-Unternehmen, darunter LinkedIn und Netflix.

Wie Gradle Build Tool mit TeamCity 30.000 grüne Builds pro Tag ausführt

Gradle Build Tool ist ein beliebtes Open-Source-Automatisierungstool, das millionenfach zum Erstellen, Testen und Bereitstellen von Software verwendet wird. TeamCity ist eine universell einsetzbare CI/CD-Lösung, die Flexibilität für Workflows, Teamwork und Entwicklungsabläufe bietet.

In dieser Fallstudie sehen wir uns detailliert an, wie Gradle mit TeamCity Zehntausende Builds pro Tag erstellt und dabei die Fehlerquote niedrig hält.

„TeamCity ist seit mehr als einem Jahrzehnt unser CI-System der Wahl. Es enthält standardmäßig alle Funktionen, die wir benötigen. Wir schätzen auch seine Zuverlässigkeit und nutzen Kotlin-DSL gern für die Konfiguration unserer Pipelines.“

— Piotr Jagielski, VP Engineering, Gradle Build Tool

Über Gradle Inc.

Gradle, Inc. ist das Unternehmen hinter Gradle Build Tool, einem der beliebtesten Open-Source-Tools zur Build-Automatisierung, sowie Gradle Enterprise, der führenden Lösungsplattform zur Verbesserung der Entwicklungsproduktivität. Gradle hat seinen Hauptsitz in San Francisco (Kalifornien, USA) und beschäftigt ca. 200 Mitarbeitende in 30 Ländern zur Weiterentwicklung des quelloffenen Tools und der Enterprise-Plattform, die weltweit von Millionen Entwickler*innen genutzt werden.

Bei Gradle arbeiten über 100 Entwickler*innen an zwei Codebeständen: Gradle Build Tool und Gradle Enterprise. Beide umfassen mehrere Millionen Codezeilen. Das Unternehmen verwendet TeamCity für beide Codebestände, wobei diese Fallstudie sich auf die Entwicklung von Gradle Build Tool konzentriert.


TeamCity bei Gradle Inc.

Das Gradle-Team verwendet TeamCity seit zehn Jahren für seinen CI/CD-Prozess. In dieser Zeit hat das Team noch kein TeamCity-Update ausgelassen. Dank regelmäßiger Updates nutzt das Team immer die neueste, leistungsstärkste Version des Produkts.


Der Technologiestack von Gradle

Das Team von Gradle Build Tool verwendet Git und GitHub zur Versionsverwaltung. Der Code wird in Java, Kotlin und Groovy geschrieben. Naturgemäß verwendet das Team auch seine eigenen Produkte – Gradle Build Tool für die Build-Automatisierung und Gradle Enterprise für die Build-Beschleunigung und Fehleranalyse. TeamCity wird als CI-Lösung verwendet, um alles auszuführen, was nicht lokal laufen soll: Build-, Deploy- und Cron-Jobs, Agent-Provisioning und mehr.


Die CI-Pipeline von Gradle

Gradle Build Tool verfügt über eine umfassende Testsuite, die überprüft, ob das Produkt in Kombination mit unterschiedlichen Betriebssystemen, Java-Versionen und anderen Komponenten korrekt funktioniert. Ein vollständiger, „releasebereiter“ Build wird über 150.000 Tests unterzogen. Außerdem müssen Änderungen auch die Performance-Suite erfolgreich durchlaufen, bevor sie in den Hauptbranch übernommen werden. Dies erfordert ein komplexes CI-Setup mit Hunderten Build-Agents.

Build-Agent-Typen

Gradle verwendet Windows-, Linux- und macOS-basierte Build-Agents. Etwa die Hälfte der Agents sind „Bare-Metal“-Systeme. Das Team verwendet auch Amazon-EC2-Spot-Agents. So kann Gradle das Buildtempo auch bei hoher Last aufrechterhalten.

Da TeamCity Spot-Instanzen standardmäßig unterstützt, hat das Team keinerlei Probleme mit abgebrochenen Agent-Verbindungen. TeamCity startet Builds automatisch neu, wenn eine Spot-Instanz nicht mehr verfügbar ist.

Wichtige CI/CD-Kennzahlen

Das TeamCity-Setup für das Gradle Build Tool ist öffentlich zugänglich und für jeden einsehbar. Der Main-Branch (master) besteht aus etwa 500 Build-Konfigurationen, die in einer ausgeklügelten Build-Chain angeordnet sind. „Bei Gradle verwenden wir Build-Chains ziemlich ausgiebig. Ohne sie könnten wir gar nicht auskommen“, so Piotr.

Aufgrund der Build-Chain-Komplexität verwendet Gradle die Kotlin-DSL zum Konfigurieren seiner Pipelines.

Teil der Build-Chain von Gradle Build Tool. Die vollständige Version finden Sie hier. Zum Ansehen können Sie sich als Gast anmelden.
Teil der Build-Chain von Gradle Build Tool. Die vollständige Version finden Sie hier. Zum Ansehen können Sie sich als Gast anmelden.

Gradle verfügt über 200 feste Build-Agents und 200 zusätzliche elastische EC2-Agents, die zum Abfedern von Lastspitzen über Cloud-Profile angebunden sind. Die gesamte Buildzeit pro Woche liegt bei 283 Tagen (6792 Stunden).

Gleichzeitig werden etwa 1636 Tage pro Monat von TeamCity optimiert. Anhand intelligenter Algorithmen erkennt TeamCity, wenn ein Build nicht ausgeführt werden muss, weil für denselben Commit im Repository bereits ein Build erstellt wurde.

Gradle verwendet Build-Chains, und da TeamCity die Wiederverwendung von Builds ermöglicht, spart das Team eine erhebliche Menge an Buildzeit ein.

Anzahl der verwendeten Agents
Anzahl der verwendeten Agents

Da TeamCity Prometheus-kompatible Servermetriken bereitstellt, kann das Team die Build-Daten automatisch zur weiteren Visualisierung und Analyse in Grafana exportieren. Das Team behält Kennzahlen wie die Wartezeit für Builds in der Warteschlange, die Nutzung von TeamCity-Agents, die Länge der Warteschlange und die Anzahl der verbundenen Agents im Blick.

Auf dieser Grundlage kann das Team entscheiden, ob aufgrund einer zu hohen Auslastung weitere Build-Agents erforderlich sind.

Verwendung von TeamCity-Agents bei Gradle
Verwendung von TeamCity-Agents bei Gradle

Überwachung der Feedback-Zeit

Die schnellstmögliche Bereitstellung von Feedback steht bei jeder CI-Lösung im Vordergrund. Durch die Überwachung der Feedback-Zeit behält das Entwicklerproduktivitätsteam von Gradle den Überblick darüber, wie lange Entwickler*innen auf das Merging ihrer Pull-Requests warten müssen.

Durchschnittliche Wartezeit für Gradle-Builds in der Warteschlange
Durchschnittliche Wartezeit für Gradle-Builds in der Warteschlange

Um dies zu verfolgen, behält das Gradle-Team den Trigger-Build im Auge – dieser Composite-Build aggregiert die Ergebnisse mehrerer anderer Builds, die durch Snapshot-Abhängigkeiten kombiniert werden, und präsentiert diese an zentraler Stelle.

Die Feedbackzeit variiert je nach Komplexität des Pull-Requests. Bei einfacheren PRs liegt das Feedback innerhalb von 10 Minuten vor, während es bei komplexeren Fällen bis zu einer Stunde dauern kann. Da Gradle quelloffen ist, durchlaufen alle Pull-Requests der GitHub-Community denselben Buildprozess.

Master-Branch-Projekte von Gradle Build Tool in TeamCity
Master-Branch-Projekte von Gradle Build Tool in TeamCity

Build-Trigger

Aus Kostengründen löst nicht jeder Commit automatisch einen Build aus. Stattdessen können Entwickler*innen durch einen Kommentar im entsprechenden Pull-Request einen Build auslösen. Ein Bot startet dann den Build über die TeamCity-API.

Einige Branches, etwa master und release, werden unterschiedlich behandelt. Jeder Push in diesen Branches löst einen TeamCity-Build aus.

Kotlin-DSL – die Revolution

Bei der Verwaltung der komplexen Build-Abhängigkeiten stellt die Kotlin-DSL eine enorme Hilfe für das Gradle-Team dar. Indem die Projektkonfiguration als Code gespeichert wird, kann das Team die Build-Logik effizient projektübergreifend reproduzieren, Updates einheitlich auf zahlreiche Konfigurationen anwenden und die Pipelines systematisch verwalten.

Mithilfe der Kotlin-DSL kann das Team Build-Abhängigkeiten mit viel weniger Aufwand generieren und testen. Dabei ist in fast allen Projekten des Teams die Bearbeitung über die Weboberfläche deaktiviert, da nur die Kotlin-DSL verwendet wird.


Gradle Build Tool + TeamCity: der größte Erfolg

TeamCity beschleunigt den gesamten CI/CD-Prozess von Gradle. Dank TeamCity werden für das Gradle Build Tool 30.000 grüne Builds pro Tag ausgeführt, wobei die Fehlerquote in engen Grenzen bleibt.

Aufgrund seiner reichhaltigen Funktionalität wird TeamCity vom Gradle-Team als Komplettlösung verwendet. Es verfügt über alle Funktionen, die andere Tools bieten – und zusätzlich über viele Funktionen, die in diesen fehlen.

Die Kotlin-DSL bietet Gradle ein ungekanntes Maß an Flexibilität, sodass das Unternehmen komplexe Build-Chains in kürzester Zeit erstellen und testen kann. Die Tests des Teams erstrecken sich auch auf die Kotlin-DSL-Konfigurationsdateien. Die TeamCity-Konfiguration von Gradle ist quelloffen und auf GitHub verfügbar.

Das Gradle-Team schätzt auch die Zuverlässigkeit von TeamCity. Das Team aktualisiert TeamCity, sobald eine neue Version verfügbar ist, und dabei treten kaum Probleme auf. Obwohl TeamCity über 400 Build-Agents verwaltet, muss sich das Team so gut wie nie mit Verbindungs- oder Build-Agent-Problemen herumschlagen.


Zukünftige Skalierung der Infrastruktur

Dem Team von Gradle Build Tool ist es sehr wichtig, eine Infrastruktur zu haben, die mit dem Team mitwächst. Selbst bei einer eventuellen Verdopplung der Teamgröße will Gradle die aktuelle Feedbackzeit beibehalten – oder sogar noch weiter senken.

Um dieses ehrgeizige Ziel zu erreichen, plant das Gradle-Team den umfassenden Einsatz von Developer-Productivity-Engineering-Methoden, wobei menschliche Eingriffe dank Automatisierung zurückgehen und mehr Build-Agents in den gesamten CI/CD-Prozess eingebunden werden.

Ähnliche Kundenstudien

Picnic

Ivan Babiankou, Staff Software Engineer, Picnic

Wir waren auf der Suche nach einer Managed-Lösung für die Gesamtheit unserer CI-Anwendungsfälle. Darüber hinaus benötigten wir selbstgehostete Agents, um die Kontrolle über die verwendete Software und die genauen Tools zu behalten. TeamCity Cloud mit selbstgehosteten Agents ist eine maßgeschneiderte Lösung, die von den mehr als 300 Entwickler*innen unseres Teams gerne genutzt wird und unsere Produktivität auf ein neues Niveau hebt.

Gearbox

Phillip Peterson, Senior Release Engineer

Wir hatten ein Produkt, das schon seit langem intern verwendet wurde. Wir versuchten, zu einem Konkurrenzprodukt zu wechseln, aber keine der Alternativen bewährte sich. Dann sagten uns einige Kolleg*innen, die von einem anderen Gaming-Unternehmen gekommen waren: ‚Wir haben früher ein System namens TeamCity benutzt.‘ Wir haben es uns angeschaut und festgestellt, dass TeamCity für viele unserer Probleme eine Lösung bot.

Playrix

Yuri Trufanov, Executive Technical Director für Technologieplattformen

Wir entschieden uns letztendlich für eine hybride Cloud-Lösung mit TeamCity-Cloud-Profilen und AWS. Darüber hinaus verwendeten wir On-Premises-Computer für die Build-Agents. Durch diese Kombination konnten wir tagsüber beliebig viele Builds unterbringen und gleichzeitig einen Grundstock an Agents für die Nebenzeiten bereitstellen. Wir konnten also standortunabhängig alles ausführen, was wir wollen.

Weitere Kundenstudien