Industrie: Spielentwicklung
Verwendete JetBrains-Produkte: TeamCity
Organisationsgröße: 500-1000
Land: Vereinigte Staaten
Die Gearbox Entertainment Company mit Sitz in Frisco, Texas (USA) ist ein preisgekröntes Unternehmen für interaktive Unterhaltung mit einer wachsenden transmedialen Präsenz. In den vergangenen drei Jahrzehnten hat Gearbox Entertainment einige der berühmtesten und legendärsten Serien, Charaktere und Erlebniswelten der Videospielgeschichte entwickelt und veröffentlicht, wie z. B. die Borderlands-Reihe und vieles mehr.
Gearbox ist ein amerikanisches Videospielunternehmen mit Hauptsitz in Frisco, Texas, in der Nähe von Dallas. Das 1999 gegründete Unternehmen hat einige der kultverdächtigsten Titel der Videospiel-Geschichte entwickelt, darunter Half-Life, Brothers in Arms und Borderlands.
Wir haben uns mit Steve Fortier, Lead Release Engineer von Gearbox, und Phillip Peterson, Senior Release Engineer von Gearbox, darüber unterhalten, wie das Unternehmen seine CI/CD-Prozesse mit JetBrains TeamCity standardisiert und verbessert hat.
Steve und Phillip gehören zum Release-Engineering-Kernteam von Gearbox. Das Team ist in Quebec City (Montreal, Kanada) und Frisco verteilt und hat die Aufgabe, alle Projekte des Unternehmens zu betreuen und Automatisierungen für die Anforderungen jedes einzelnen Projekts einzurichten. Bei jedem Start eines neuen Projekts richtet das Team sofort ein Depot in Perforce ein und verknüpft ein TeamCity-Projekt damit.
Das Team versucht, jedem Projekt eine Person zuzuweisen. Jeder Release Engineer ist Mitglied sowohl im Release-Team als auch in einem Game-Projekt. So kann das Team auf die individuellen Automatisierungsanforderungen der Projekte reagieren.
Außerdem können die Entwickler*innen dadurch ihr Wissen über Best Practices in TeamCity miteinander teilen und jederzeit einspringen, wenn in einem anderen Projekt Unterstützungsbedarf besteht. Dank standardisierter CI/CD-Verfahren und wiederverwendbarer Projektvorlagen kann das Team sehr schnell auf Probleme reagieren.
Das Team verwendet Perforce als Versionsverwaltungssystem und Unreal als Game-Engine. TeamCity interagiert dabei mit C#-Skripten, die auf Unreal aufsetzen. Diese Schicht ist CI-agnostisch und ermöglicht das Arbeiten sowohl mit Unity- als auch mit Unreal-Projekten.
Das Team nutzt außerdem AWS für Build-Systeme sowie Datenspeicher über Artifactory. Dafür wird in TeamCity das JFrog-Plugin eingesetzt.
Die zuvor von Gearbox eingesetzte CI/CD-Lösung wies einige Einschränkungen auf. Insbesondere war die Integration in Perforce mangelhaft. Das verwendete CI/CD-Tool ermöglichte außerdem im Gegensatz zu TeamCity keine persönlichen Builds, und die Weitergabe von Informationen zwischen den Build-Schritten war eine Herausforderung.
„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.“
— Phillip Peterson, Senior Release Engineer
Bei einem der von Gearbox verwendeten Konkurrenzprodukte war es recht umständlich, eine Verbindung zwischen zwei Build-Schritten einzurichten. Wenn beispielsweise in einem Build-Schritt ein Artefakt erzeugt wurde, sollte der Name dieses Artefakts an einen nachfolgenden Job weitergegeben werden. Bereits diese einfache Kommunikation zwischen zwei Build-Schritten war eine ziemliche Hürde. Im Gegensatz dazu war dies in TeamCity sehr einfach zu bewerkstelligen.
Ein weiteres Problem des Teams war die Weitergabe von Build-Ergebnissen von einem Build-Schritt zum nächsten. Mit TeamCity konnte dies über eine Abhängigkeit gelöst werden.
Bei der Suche nach einer neuen CI/CD-Lösung waren dem Team vor allem zwei Dinge wichtig. Eines davon war die unkomplizierte projektübergreifende Anwendung von Änderungen. Zuvor musste bei jedem Projekt von Grund auf neu begonnen werden. Mit wachsender Projektanzahl wünschte sich das Team Vorlagen, um die Projekteinstellungen einfach per Copy-Paste einfügen, den Namen ändern und das Projekt gleich ausführen zu können.
Die zweite Anforderung war eine einfache Bedienoberfläche, die das Arbeiten mit dem neuen CI/CD-Tool für Endbenutzer*innen und Admins leicht machen sollte.
„Eines der Konkurrenzprodukte hatte eine sehr unfreundliche Oberfläche. Wenn die Leute in ein CI/CD-System einsteigen, sollten sie das Gefühl bekommen, dass es sehr stabil ist, dass es nicht zusammenbricht, wenn sie versuchen, etwas darin zu erledigen. Ich finde, TeamCity hat eine sehr durchdachte Bedienoberfläche. Beim Navigieren bekommt man den Eindruck, dass es ein gut funktionierendes System ist.“
— Steve Fortier, Lead Release Engineer
Dank der ausgefeilten Bedienoberfläche von TeamCity war keine Überzeugungsarbeit nötig. Sobald feststand, dass das Konzept funktionierte, reichte eine einfache Vorführung der Lösung, um die Leute zum Umstieg auf die neue CI/CD-Lösung zu bewegen.
Ein weiterer Faktor bei der Auswahl der neuen CI/CD-Lösung war für Gearbox die Art und Weise, wie die Zugriffsverwaltung in TeamCity funktioniert. Das Team wollte die Benutzerrechte projektweise konfigurieren.
In TeamCity können Hierarchien erstellt werden, die dafür sorgen, dass Zugriffsrechte für ein Projekt gleichzeitig Zugriff auf alle Unterprojekte gewähren. Für Gearbox war dies ein großer Fortschritt.
Als das Team von TeamCity erfuhr, probierte es zunächst die lokal installierbare Version aus. Die Option, TeamCity Cloud zu verwenden, hat in der IT-Abteilung von Gearbox jedoch viel Zuspruch gefunden, da nur noch die Authentifizierung eingerichtet werden musste. Auch die Umstellung verlief deutlich schneller, als die Einrichtung der On-Premises-Version gedauert hätte.
TeamCity Cloud bietet die Wahl zwischen selbst gehosteten und von JetBrains gehosteten Build-Agents. Das Gearbox-Team verwendet selbst gehostete Agents. Dies ermöglicht die vollständige Anpassung der Umgebung, in der die Builds ausgeführt werden.
Bei der Umstellung auf TeamCity begann das Team, alle Projekte von Grund auf neu einzurichten. Allerdings waren die alten Buildskripte bewusst so gestaltet, dass sie vom CI-System unabhängig waren. Obwohl viele neue Projekte in TeamCity einzurichten waren, wurden dadurch im Grunde nur bestehende Befehle aus dem alten System in das neue kopiert.
Nach einigen Workshops, bei denen besprochen wurde, wie die Projekte strukturiert werden sollten, konnte das Team in nur 6 Wochen von der alten CI-Lösung zu TeamCity wechseln.
Derzeit hat Gearbox 340 Committer und 138 Projekte in TeamCity Cloud.
Die Teammitglieder verwenden Agents, die in ihren eigenen AWS-Accounts gehostet werden. Auch die Cloud-Profile von TeamCity kommen zum Einsatz. Je nach den Anforderungen des Builds wählt TeamCity automatisch eine der vom Team verwendeten Instanzen aus: „Base“, „High“, „Mega“ oder „GPU“.
Während der Übergangsphase installierte Gearbox TeamCity parallel auf dem Amazon Machine Image (AMI), das für die vorherige CI/CD-Lösung eingerichtet worden war. Auf diese Weise musste Gearbox nur ein einziges AMI pflegen, das sowohl für das alte als auch für das neue System verwendet wurde. Dadurch gestaltete sich der Migrationsprozess noch einfacher.
Gearbox macht intensiven Gebrauch von Build-Chains in seinem CI/CD-Prozess. Der Unreal-Prozess setzt sich aus fünf Phasen zusammen: Kompilierung, Cooking, Staging, Paketierung und Veröffentlichung.
Wenn ein Game in weniger als 12 Stunden veröffentlicht werden soll und irgendwo in der Kette ein Volume vollläuft und den Vorgang unterbricht, kann man nicht einfach das Volume erweitern und noch einmal von vorn beginnen. Dafür reicht die Zeit nicht.
Dank TeamCity konnte das Gearbox-Team jedes Einzelteil in ein eigenes Build auslagern. Wenn ein Volume während des Buildprozesses voll wird und erweitert werden muss, führt dies zwar zu einem Buildfehler, aber das Team kann das Problem mühelos lösen. Der Prozess kann an der Stelle neu gestartet werden, an der er unterbrochen wurde, das persistente Volume wird wieder verbunden und der Vorgang nahtlos fortgesetzt. Ermöglicht wird dies durch die in TeamCity integrierten Build-Chain-Optimierungen, die auf der Wiederverwendung von Builds beim Einsatz von Snapshot-Abhängigkeiten basieren.
Wenn die Gearbox-Entwickler*innen mit ihren lokalen Tests fertig sind, kann TeamCity noch kräftig nachlegen, indem es die gesamte Testreihe zentral ausführt. Das CI/CD-System kann diese Testläufe auch dynamisch auf unterschiedlichen Systemen orchestrieren, wobei stets so viele Systeme wie nötig hochgefahren und im Anschluss wieder heruntergefahren werden, um die Ressourcennutzung zu optimieren.
Eine der größten Herausforderungen, die Gearbox mit TeamCity lösen konnte, war das Anlegen neuer Projekte. Bei den getesteten Alternativen musste jedes Projekt von Grund auf neu aufgesetzt werden. Durch das Wachstum im Zeitverlauf nahmen die Unterschiede zwischen den einzelnen Projekten immer weiter zu, sodass schließlich für jedes Projekt unterschiedliches Expertenwissen benötigt wurde. Dies erschwerte den Wissensaustausch zwischen den Teams, führte zu Engpässen im Entwicklungsprozess und erhöhte das Risiko von Fehlern und Unstimmigkeiten.
Seit das Team TeamCity als CI/CD-Lösung eingeführt hat, ist alles viel einfacher geworden. Dank der eingerichteten Vorlagen können Ressourcen in mehreren Projekten verwendet werden. Wenn jemand mit einem Projekt vertraut ist, kommt er mit allen anderen Projekten zurecht. Dadurch konnte das Team seine Produktivität steigern und sich auf eine effiziente Entwicklung konzentrieren.
Bei der früheren CI-Lösung von Gearbox wurde der Editor für jeden Build neu kompiliert, was bis zu einer Stunde dauern konnte. Jetzt kann das Team diesen Schritt in einen separaten Build abspalten, der dann überall wiederverwendet wird. Dies hat dem Team zu erheblichen Einsparungen bei den EC2-Instanzen verholfen, da nicht immer wieder das Gleiche kompiliert werden muss.
Als Gearbox begann, Kotlin für die Projektkonfiguration zu verwenden, war das Team sehr angetan. Selbst Leute mit wenig Kotlin-Erfahrung konnten es problemlos verstehen und benutzen. „Es gab zwar eine Lernkurve, aber die allgemeine Stimmung war positiv“, sagt Steve Fortier.
Bei nur einer Änderung in einem einzelnen Projekt verwendet das Team die Bedienoberfläche. Soll jedoch die Funktionsweise einer bestimmten Build-Konfiguration über mehrere Projekte hinweg geändert werden, kommt Kotlin zum Einsatz. Die Flexibilität dieser hybriden Herangehensweise an die Projektkonfiguration ist für Gearbox ein weiteres TeamCity-Highlight.
Gearbox will den Einsatz von TeamCity durch die Implementierung von persönlichen Builds ausweiten, um das Vertrauen in Commits zu erhöhen und funktionierende Builds für die Qualitätssicherung bereitzustellen. Außerdem sollen Build-Chains verkürzt, die Build-Geschwindigkeit erhöht und Fehler minimiert werden.
Aktuell werden die Serverperformance, die Builddauer und Buildfehler verfolgt, das Team plant jedoch, detailliertere Kennzahlen wie Artefaktgröße und Warteschlangendauer einzubeziehen. Das Ziel ist dabei, die zahlreichen anpassungsfähigen Funktionen von TeamCity zu nutzen, um einen effizienteren CI-Prozess einzurichten, der Zeit spart und zuverlässige Builds gewährleistet.
Durch den Wechsel zu TeamCity konnte Gearbox seine CI/CD-Workflows in mehrfacher Hinsicht verbessern.
Mit TeamCity erzielt Gearbox außerdem erhebliche Einsparungen bei den EC2-Instanzen, denn durch die Einrichtung von Abhängigkeiten kann das mehrfache Kompilieren desselben Artefakts vermieden werden.
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.
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.
Tadeas Kriz, CTO und Mitgründer von Brightify
Unsere Code-Reviews haben sich erheblich verbessert, und mithilfe der Webhooks von Space zu TeamCity können wir nach einem erfolgten Review einen Build vom jeweiligen Branch erstellen und für unsere Qualitätssicherung bereitstellen, damit der Branch vor dem Merge getestet werden kann. Abwesenheiten lassen sich jetzt auch einfacher verfolgen.