Industrie: Softwareentwicklung
Verwendete JetBrains-Produkte: TeamCity
Organisationsgröße: 200
Land: Vereinigte Staaten
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.