So verkürzt das IntelliJ-Infrastrukturteam mit TeamCity die Buildzeiten um 30%

Die Herausforderung: Skalierung eines CI/CD-Prozesses für Hunderte Entwickler*innen

Wenn ein großes Entwicklungsteam ständig an Änderungen arbeitet, ist die Bereitstellung schneller, zuverlässiger und skalierbarer CI/CD-Pipelines keine einfache Aufgabe. Das IntelliJ-Infrastrukturteam benötigt eine massiv skalierbare Lösung, die ohne Überforderung der Ressourcen Tausende Builds pro Tag ausführen kann. Benötigt wird außerdem eine intelligente Automatisierung, um manuelle Eingriffe zu minimieren und gleichzeitig die Auslieferung von qualitativ hochwertigem Code zu gewährleisten.

Maßgeblich ist darüber hinaus die Unterstützung für verschiedene Infrastrukturumgebungen, einschließlich On-Premises-, AWS-, macOS-, Linux- und Windows-Agents. Um eine hohe Codequalität zu gewährleisten, muss das Team außerdem Hunderttausende automatisierte Tests verwalten und dabei unzuverlässige Tests auf ein Minimum reduzieren.

TeamCity, eine von JetBrains entwickelte leistungsstarke CI/CD-Lösung, hat sich als die perfekte Antwort auf diese Herausforderungen erwiesen.

„Wir bauen IDEs und alles, was dazugehört – interne Services, Statistikservices usw. – in TeamCity. Ich habe mich sehr an TeamCity gewöhnt und habe das Gefühl, einen Hammer in meiner Hand zu haben: Man kann alles damit machen.“

— Dmitrii Panov, technischer Leiter für die IntelliJ-Infrastruktur

So hilft TeamCity dem IntelliJ-Infrastrukturteam

Sichere Pushes

Der Prozess des IntelliJ-Gesamtteams sieht derzeit vor, dass Entwickler*innen ihren Code sofort nach der Fertigstellung pushen, ohne alle Änderungen in einem Branch zu sammeln und darauf zu warten, dass diese gemeinsam getestet werden.

Zur Unterstützung dieses Workflows hat das IntelliJ-Infrastrukturteam den Safe-Push-Mechanismus implementiert, bei dem es sich im Wesentlichen um eine Reihe von Composite-Build-Konfigurationen in TeamCity handelt. Für Benutzer*innen ist der Vorgang ziemlich einfach: Sie pushen ihre Änderungen einfach über ihre IDEs, und das war’s.

Hinter den Kulissen analysiert ein dedizierter interner Service den Safe-Push-Änderungssatz und löst über die REST-API von TeamCity die zum Testen der Änderungen erforderlichen Builds aus. Fehlgeschlagene Builds werden neu gestartet, um unzuverlässige Tests zu wiederholen.

Durch die Wiederverwendung erfolgreicher Builds trägt TeamCity dazu bei, dass Safe Pushes erheblich schneller und kostengünstiger ablaufen, da ein Build für Safe-Push-Tests bis zu 700.000 Tests enthalten kann. Die Wiederverwendungsfunktion sorgt dafür, dass Artefakte, Abhängigkeiten und Testergebnisse wiederverwendet werden, anstatt alles von Grund auf neu auszuführen. Dies verbessert die Buildeffizienz, beschleunigt die CI/CD-Pipelines und reduziert den Ressourcenbedarf.

Ressourceneinsparungen durch Wiederverwendung von Builds

Die Wiederverwendung von Builds ist eine TeamCity-Funktion, die aus Sicht des Teams besonders nützlich ist. So sieht eine typische TeamCity-Build-Chain aus:

Wenn eine Testkette beim ersten Versuch fehlschlägt, wiederholt der Safe-Push-Mechanismus den Vorgang noch zweimal, um sicherzustellen, dass tatsächlich ein Problem vorliegt.

Betrachten wir einen typischen Push, um zu sehen, wie das Wiederholen von Builds durch Wiederverwendung optimiert wird. Beim ersten Durchgang werden alle 329 Builds in der Build-Chain ausgeführt. 319 bestehen die Tests, 10 scheitern jedoch, sodass die Chain wiederholt wird. Dieses Mal werden nur die 10 fehlgeschlagenen Builds ausgeführt – der Rest wird wiederverwendet. 6 weitere Builds schaffen die Tests, aber einige bleiben noch übrig. Beim dritten Versuch müssen also die restlichen 4 Builds ausgeführt werden, während 325 wiederverwendet werden können.

Dadurch wird die Belastung der Build-Agents drastisch reduziert und die Wiederholungszeiten werden erheblich kürzer. Im Vergleich zu drei vollständigen Durchläufen, die jeweils etwa 3 Stunden dauern, verkürzt die Wiederverwendung von Builds die Ausführungszeit um etwa 30%.

Unterstützung für massive Skalierung ermöglicht reibungslose Leistungssteigerungen

Das IntelliJ-Team führt täglich mehr als 158.000 Builds für über separate 180 Benutzer*innen aus – die Effizienz ist daher von großer Bedeutung. Die Fähigkeit von TeamCity, Builds wiederzuverwenden, leistet dazu einen entscheidenden Beitrag:

• 75% der Builds müssen nicht komplett neu erstellt werden, wenn ein Test fehlschlägt.
• Die Wiederholungszeiten sind um durchschnittlich 30% kürzer, wodurch Engpässe deutlich reduziert werden.
• Entwickler*innen können kontinuierlich Merges durchführen, ohne sich gegenseitig in die Quere zu kommen, da über 90 Safe-Push-Tests gleichzeitig ausgeführt werden können.

Kotlin-DSL

Das IntelliJ-Infrastrukturteam verwaltet TeamCity über die Kotlin-DSL. Die Kotlin-DSL verbindet die Vorteile einer vollständigen Programmiersprache mit den Stärken einer DSL, die speziell für die Erstellung von Pipelines als Code konzipiert ist.

Die TeamCity-Instanz enthält derzeit über 2000 Projekte, 15.000 Buildkonfigurationen und fast 300 VCS-Roots. Für das Team wäre es unvorstellbar, eine Instanz dieser Größe mit etwas anderem als der Kotlin-DSL zu verwalten.

„Wir haben nur für die Kotlin-Einstellungen fast 350 Unit-Tests. Mit YAML würde ich da nicht arbeiten wollen.“

— Dmitrii Panov, technischer Leiter für die IntelliJ-Infrastruktur

Agent-Management

Dank der leistungsstarken Agent-Management-Funktionen von TeamCity können CI/CD-Pipelines einfach und effizient skaliert werden. Im Gegensatz zu YAML-basierten CI/CD-Systemen, die komplexe Workarounds wie Anchors, Go-to-Anweisungen und manuelle Wiederholungslogik erfordern, vereinfacht TeamCity diesen Prozess mit einer integrierten Agent-Orchestrierung.

Für Teams, die AWS verwenden, bietet TeamCity eine reibungslose Integration in Cloud-Infrastrukturen, sodass Agents automatisch nach Bedarf gestartet und verwaltet werden können. Zum Beispiel kann TeamCity so konfiguriert werden, dass es genau die in einer bestimmten Situation benötigte Anzahl von Agents aktiviert und sie bei Leerlauf wieder abschaltet, um die Ressourcennutzung zu optimieren.

Diese präzise Steuerung der Agents ist weitaus intuitiver als bei anderen Lösungen, bei denen externe Plugins zu Kompatibilitätsproblemen führen können, die einen erhöhten Fehlersuchaufwand verursachen.

TeamCity bewältigt enorme Arbeitslasten, mit Warteschlangen von mehr als 10.000 Builds und bis zu 5.000 dynamisch verwalteten Build-Agents. Eine herausragende Funktion von TeamCity ist die Fähigkeit, präemptible AWS-Instanzen zu verwenden. Wenn eine Instanz von AWS zurückgefordert wird, kann TeamCity den Build automatisch auf einem anderen Agent neu starten, sodass Serviceunterbrechungen vermieden werden und eine reibungslose Ausführung gewährleistet wird.

Diese Kennzahlen verfolgt das Team

Wenn es darum geht, eine CI/CD-Plattform für Hunderte Entwickler*innen mit Zehntausenden Builds pro Tag zu verwalten, ist es unerlässlich, die wichtigsten Kennzahlen im Blick zu behalten. TeamCity stellt standardmäßig eine Reihe von Diagnosetools und Indikatoren bereit. Da TeamCity Statistiken im Prometheus-Format exportieren kann, lassen sich für komplexere Anwendungsfälle auch eigene Dashboards erstellen.

„TeamCity stellt uns einige grundlegende Bausteine bereit, zum Beispiel statistische Daten über Builds oder Tests. Auf diesen Grundstrukturen können wir dann etwas Komplexeres aufbauen.“

— Aleksei Smirnov, Software-Entwickler im .NET-Infrastrukturteam

Hier sind die wichtigsten Kennzahlen, die das IntelliJ-Infrastrukturteam im Auge behält, um den CI/CD-Prozess mit TeamCity zu optimieren.

Anzahl der Builds pro Tag

Das Team überwacht täglich rund 158.000 Builds, um die Arbeitslast und die Performance nachzuvollziehen. Die Anzahl der Builds ist für sich genommen für das Team zwar nicht sehr relevant, aber sie ist dennoch ein wichtiger Arbeitslast-Prädiktor für Build-Agents.

Parallele Safe Pushes

Zu jedem beliebigen Zeitpunkt laufen 80–90 Safe-Push-Prüfungen gleichzeitig. Für das Team ist es wichtig zu verfolgen, wie lange jede Safe-Push-Prüfung dauert – je schneller die Ausführung, desto schneller läuft der Build durch.

Effizienz durch Wiederverwendung von Builds

Das Team analysiert, wie viele Builds bei Wiederholungen wiederverwendet werden, sodass redundante Ausführungen reduziert und Ressourcen gespart werden können.

Testausführung

Ein Composite-Build im IntelliJ-TeamCity-Projekt enthält fast 700.000 Tests.

Das Team verfolgt über 700.000 Tests pro Safe-Push-Chain, um eventuelle Fehler zu identifizieren. Die Zuverlässigkeit von Tests wird ebenfalls erfasst, indem fehlgeschlagene Tests automatisch wiederholt und instabile Tests für eine weitere Untersuchung stummgeschaltet werden.

Eine der Kennzahlen, die das Team zu optimieren versucht, ist die Anzahl der Versuche bis zu einem erfolgreichen Durchlauf. Dadurch können bei jedem Lauf Ressourcen und Zeit gespart werden.

Agent-Nutzung

Das Team überwacht über 5.000 AWS- und physische Build-Agents und optimiert die Ressourcenzuweisung unter anderem durch die Wiederverwendung von Builds, sodass die Buildzeiten um etwa 30% reduziert werden können.

Verbesserungspotenzial in TeamCity

Das IntelliJ-Infrastrukturteam verwendet TeamCity täglich für eine Vielzahl von Vorgängen und hat festgestellt, dass TeamCity zum Lösen zahlreicher Probleme beiträgt. Über einige neue Funktionen würde sich das Team trotzdem freuen.

Teamfunktionen

TeamCity bietet zwar Zugriff auf alle Build-Chains und Projekte innerhalb einer Organisation, aber Entwickler*innen benötigen oft eine fokussiertere Sicht auf die für sie relevanten Builds. Wenn zum Beispiel eine Entwicklerin an PyCharm arbeitet, sollte sie idealerweise nur PyCharm-spezifische Builds, Tests und Konfigurationen sehen, ohne sich durch Projekte zu kämpfen, die nichts mit ihrer Arbeit zu tun haben.

Ein vereinfachtes Dashboard, das nur relevante Buildkonfigurationen, Tests und stummgeschaltete Tests anzeigt, würde die Bedienfreundlichkeit erheblich verbessern. Das Team hat versucht, dieses Problem mit einer Grafana-basierten Lösung anzugehen, aber ein besser integrierter und einfacher zu bedienender TeamCity-interner Ansatz wäre ideal.

Verwaltung von stummgeschalteten Tests

Das Team ist der Meinung, dass ein Stummschaltungs-Management TeamCity sehr guttun würde. Angesichts der großen Anzahl automatisierter Tests müssen einige Tests zwangsläufig stummgeschaltet werden. Zwar bietet TeamCity eine Funktion zum Stummschalten von Tests, aber es passiert sehr leicht, dass ein Test nach dem Stummschalten vergessen wird, und dies erschwert die Arbeit anderer Kolleg*innen, die auf diesen Test angewiesen sind.

Ein spezielles System zur Verwaltung von Stummschaltungen, mit dem Teams die für ihre Projekte relevanten stummgeschalteten Tests unkompliziert anzeigen, verwalten und nachverfolgen könnten, würde für klarere Zuständigkeiten und mehr Transparenz sorgen.

Fazit

Das IntelliJ-Infrastrukturteam hat es mit TeamCity geschafft, ein groß angelegtes CI/CD-System effizient zu betreiben, indem Builds vereinfacht, die Ressourcennutzung optimiert und die Ausführungszeiten erheblich verkürzt werden. Durch den Einsatz von Safe Push, der Wiederverwendung von Builds und der automatisierten Testwiederholung konnten die Build-Ausführungszeiten um 30% reduziert werden. Dadurch können 700 bis 800 Entwickler*innen ihre Änderungen jederzeit reibungslos pushen.

Die Erfahrungen des IntelliJ-Infrastrukturteams zeigen, dass TeamCity nicht nur ein CI/CD-Tool ist, sondern das Rückgrat eines groß angelegten Softwareentwicklungssystems bilden kann.