Domaine : Développement de jeux
Produits JetBrains utilisés : TeamCity
Taille de l'organisation : 500-1000
Pays : États-Unis
Gearbox Entertainment Company est une société de divertissement interactif primée et une force transmédia en pleine expansion basée à Frisco, au Texas. Au cours des trois dernières décennies, Gearbox Entertainment a développé et publié certaines des franchises, des personnages et des expériences les plus mémorables et les plus emblématiques de l’histoire du jeu vidéo, avec par exemple la série de jeux Borderlands.
Gearbox est une société américaine de jeux vidéo dont le siège se trouve à Frisco, au Texas, près de Dallas. Fondée en 1999, Gearbox a produit certains des jeux vidéo les plus emblématiques de l'histoire, notamment Half-Life, Brothers in Arms et Borderlands.
Nous avons rencontré Steve Fortier, Release Engineer en chef, et Phillip Peterson, Release Engineer senior, de Gearbox, pour discuter de la façon dont la société a pu standardiser et améliorer ses processus de CI/CD avec l'aide de JetBrains TeamCity.
Steve et Phillip font partie de l'équipe principale de release engineering de Gearbox. L'équipe est répartie entre Québec, Montréal et Frisco, et a pour mission de gérer tous les projets de l'entreprise, en mettant en place une automatisation pour répondre aux besoins de chacun. Chaque fois qu'un nouveau projet est lancé, l'équipe configure immédiatement un dépôt dans Perforce et s'assure qu'un projet y est lié dans TeamCity.
L'équipe s'efforce de dédier une personne à chaque projet. Chaque release engineer fait partie à la fois de l'équipe de release et d'un projet de jeu. Cela améliore la réactivité de l'équipe face aux besoins d'automatisation de chaque projet.
Il permet également aux release engineers de partager leurs connaissances sur les bonnes pratiques de TeamCity et d'intervenir si un autre projet a besoin d'aide. Grâce à des pratiques de CI/CD standardisées et à des modèles de projet réutilisables, il est possible de réagir rapidement à tout problème.
L'équipe utilise Perforce comme système de contrôle de version et Unreal comme moteur de jeu. Elle a créé des scripts C# qui se superposent à Unreal, avec lesquels TeamCity interagit. Cette couche est indépendante du CI et permet de travailler avec des projets Unity et Unreal.
L'équipe utilise également AWS pour les machines de build et le stockage via Artifactory, pour lequel elle utilise le plugin TeamCity JFrog.
La précédente solution de CI/CD utilisée par Gearbox présentait quelques limites. En particulier, la solution s'intégrait mal avec Perforce. L'outil de CI/CD utilisé par l'équipe ne proposait pas non plus de builds personnels (contrairement à TeamCity), et la transmission d'informations entre les étapes de build s'est avérée assez complexe.
« Nous avions un produit que nous utilisions en interne depuis longtemps. Nous avons cherché à passer à un autre concurrent, mais aucune de ces solutions n'a fonctionné. C'est alors que des collègues qui venaient d'une autre société de jeux nous ont dit : “Nous utilisions ce produit qui s'appelle TeamCity”. Nous nous sommes penchés sur la question et avons compris que TeamCity résolvait bon nombre de nos problèmes. »
— Phillip Peterson, Release Engineer senior
Dans l'un des concurrents utilisés par Gearbox, le processus de configuration d'une connexion entre deux étapes de build était assez fastidieux. Par exemple, une étape de build produisait un artefact. Il fallait ensuite transmettre le nom de cet artefact à une tâche ultérieure. Le simple fait d'établir une conversation entre deux étapes de build représentait un véritable obstacle. En revanche, cela semblait extrêmement facile à réaliser dans TeamCity.
L'équipe avait également du mal à transmettre les résultats du build entre les étapes de build, et TeamCity a permis d'accomplir cela avec une dépendance.
Dans le cadre d'une nouvelle solution de CI/CD, l'équipe recherchait principalement deux choses. La première, la possibilité d'appliquer facilement des changements par lot dans l'ensemble de ses projets. Auparavant, elle devait recommencer chaque projet à zéro. Avec l'augmentation du nombre de projets, l'équipe a commencé à chercher des modèles qui lui permettraient de copier-coller les paramètres du projet, d'en changer le nom et de l'exécuter.
La deuxième exigence concernait l'ergonomie de l'interface utilisateur, pour permettre aux utilisateurs finaux comme aux administrateurs de travailler facilement avec le nouvel outil de CI/CD.
« L'un des concurrents avait une interface utilisateur très peu conviviale. L'impression que doit donner un système de CI/CD est qu'il est très robuste, qu'il ne se cassera pas lorsque je tenterai d'y faire quelque chose. Je pense que TeamCity a une interface utilisateur très bien finie. Vous avez la certitude que le système fonctionne bien lorsque vous y naviguez. »
— Steve Fortier, Release Engineer en chef
L'interface utilisateur soignée de TeamCity a facilité son adoption. Une fois que l'équipe a prouvé que le concept fonctionnait, le simple fait de le montrer aux gens les a rapidement convaincus de passer à la nouvelle solution de CI/CD.
Autre facteur qui a orienté Gearbox vers une nouvelle solution de CI/CD : la gestion des accès et son fonctionnement dans TeamCity. L'équipe cherchait un moyen de modifier l'accès des utilisateurs par projet.
Dans TeamCity, vous pouvez créer des hiérarchies dans lesquelles chaque personne se voit accorder l'accès à un projet et peut ensuite accéder à tous ses sous-projets. Cela a fait une grande différence pour Gearbox.
Lorsque l'équipe a entendu parler de TeamCity, elle a d'abord essayé la version on-premise. La possibilité d'utiliser TeamCity Cloud a toutefois fait le bonheur du service informatique de Gearbox ; il n'a eu qu'à configurer l'authentification. Cela a également permis une transition beaucoup plus rapide que ce que l'entreprise avait prévu pour une installation sur site.
Avec TeamCity Cloud, il est possible de choisir entre des agents de build hébergés par JetBrains ou des agents de build autohébergés. L'équipe de Gearbox utilise des agents autohébergés, ce qui lui permet de personnaliser entièrement l'environnement dans lequel s'exécutent ses builds.
Lors de la transition vers TeamCity, l'équipe a commencé par configurer tous ses projets à partir de zéro. Elle avait toutefois délibérément créé ses anciens scripts de build de façon indépendante vis-à-vis du système de CI. Par conséquent, même si elle a commencé à mettre en place un grand nombre de nouveaux projets dans TeamCity, il s'agissait essentiellement d'un copié-collé des commandes de l'ancien système dans ces projets.
Avec quelques ateliers pour discuter de l'organisation des projets, l'équipe a pu passer de l'ancienne solution de CI à TeamCity en seulement 6 semaines.
Actuellement, Gearbox compte 340 validateurs et 138 projets dans TeamCity Cloud.
L'équipe utilise des agents hébergés dans ses propres comptes AWS. Elle utilise également les profils cloud de TeamCity. En fonction des besoins d'un build, TeamCity sélectionne automatiquement les instances « base », « high », « mega » ou « GPU » utilisées par l'équipe.
Pendant la période de transition, Gearbox a pris l'Amazon Machine Image (AMI) utilisée pour sa solution de CI/CD précédente et a installé TeamCity juste à côté. De cette manière, Gearbox n'a eu à maintenir qu'une seule AMI, puisque l'ancien système et le nouveau utilisaient la même. Cela a encore facilité le processus de migration.
Gearbox a beaucoup recours aux chaînes de build tout au long de son processus de CI/CD. Le processus Unreal passe par cinq étapes : la compilation, la préparation (ou cooking), le staging, l'empaquetage et la publication.
Si un jeu doit sortir dans moins de 12 heures et que, quelque part dans la chaîne, un volume se remplit et interrompt le processus, il est impossible d'augmenter la taille de ce volume et de recommencer. Vous n'avez tout simplement pas assez de temps pour ça.
Avec l'aide de TeamCity, l'équipe de Gearbox a été en mesure de diviser chacun de ces éléments dans son propre build. De cette façon, si le volume se remplit et doit être étendu au cours du processus de build, le build échoue, mais l'équipe peut y remédier rapidement. Elle peut redémarrer le processus là où il s'est arrêté, remonter ce volume persistant et reprendre là où elle en était. C'est possible grâce aux optimisations intégrées de la chaîne de build de TeamCity, qui sont facilitées par la réutilisation des builds lors de l'emploi de dépendances d'instantanés.
Chez Gearbox, une fois que les développeurs ont exécuté des tests locaux, TeamCity peut prendre le relais en exécutant toute la suite de tests de manière centralisée. Le système de CI/CD peut également orchestrer ces tests de façon dynamique sur différents types de machines ; il lance autant de machines que nécessaire à un moment donné et les arrête par la suite pour optimiser les ressources.
L'un des plus grands défis que TeamCity a aidé Gearbox à relever concernait la création de nouveaux projets. Avec les alternatives essayées auparavant, chaque projet devait être configuré à partir de zéro. Au fur et à mesure que les projets se développaient, ils divergeaient les uns des autres, devenant suffisamment différents pour que l'entreprise ait besoin d'un expert dédié par projet. Il était donc difficile de partager les connaissances entre les équipes, ce qui provoquait des goulets d'étranglement dans le processus de développement et augmentait le risque d'erreurs et d'incohérences.
Depuis que l'équipe a adopté TeamCity comme solution de CI/CD, ce travail a grandement été simplifié. Grâce au templating que l'équipe a pu réaliser, elle peut partager les ressources entre ses projets. Une fois que l'on connaît un projet, on connaît tous les autres. Cela a permis à l'équipe de gagner en productivité et de se concentrer sur l'efficacité du développement.
Dans l'ancienne solution de CI de Gearbox, chaque build devait générer l'éditeur, ce qui pouvait prendre jusqu'à une heure. Désormais, l'équipe peut utiliser un build distinct pour cette étape, puis le réutiliser partout. Cela lui a permis d'importantes économies en matière d'instances EC2, car elle n'a pas à compiler la même chose plusieurs fois.
Lorsque Gearbox a commencé à utiliser Kotlin pour configurer ses projets, l'équipe a montré un grand enthousiasme. Même les personnes qui avaient peu d'expérience avec Kotlin ont pu assez rapidement le comprendre et commencer à l'utiliser. « Un temps d'apprentissage est nécessaire, mais de façon générale, le feeling était positif. », a déclaré Steve Fortier.
Dans l'état actuel des choses, lorsque l'équipe a besoin de changer quelque chose pour un seul projet, elle utilise l'interface utilisateur. Si elle a besoin de changer la façon dont une configuration de build donnée fonctionne dans plusieurs projets, elle utilise Kotlin. Cette approche hybride et souple des configurations de projet est un autre atout de TeamCity pour Gearbox.
Gearbox souhaite améliorer son utilisation de TeamCity grâce à l'implémentation de builds personnels. L'entreprise souhaite ainsi augmenter le niveau de confiance dans les commits et fournir des builds fonctionnels pour les tests d'assurance qualité. L'équipe cherche également à améliorer la vitesse de build, à raccourcir les chaînes de build et à minimiser les défaillances.
Gearbox suit actuellement les performances du serveur, la durée de build et les échecs de build, mais prévoit d'inclure des mesures plus granulaires telles que la taille des artefacts et la durée de la file d'attente. Son objectif consiste à tirer parti de la gamme de fonctionnalités personnalisables de TeamCity pour mettre en place un processus de CI plus efficace, permettant de gagner du temps et de garantir la fiabilité des builds.
Le passage à TeamCity Cloud a amélioré les pratiques de CI/CD de Gearbox sur plusieurs points.
TeamCity permet également à Gearbox de réaliser d'importantes économies en matière d'instances EC2, puisque l'utilisation des dépendances permet d'éviter de compiler plusieurs fois la même chose.
Yuri Trufanov, directeur exécutif technique de la plateforme technologique
Nous nous sommes retrouvés avec une solution de cloud hybride incluant TeamCity Cloud Profiles et AWS. En plus de cela, nous disposions d’ordinateurs sur site pour les agents de build. Cette association nous a permis de prendre en charge un nombre illimité de builds tout au long de la journée, et fournit également un nombre d'agents de base pour les heures creuses. Nous pouvions ainsi exécuter ce que nous voulions, où nous le voulions.
Ivan Babiankou, ingénieur logiciel en chef chez Picnic
Nous recherchions une solution gérée pour tous nos cas d'utilisation de CI. Nous avions également besoin d’agents autohébergés pour contrôler les logiciels que nous exécutons et les outils précis utilisés. TeamCity Cloud, combiné à des agents autohébergés, a fourni une solution sur mesure. Notre équipe de plus de 300 ingénieur·es l’utilise avec plaisir et elle booste notre productivité.
Tadeas Kriz, CTO et cofondateur, Brightify
Nos révisions de code se sont considérablement améliorées et nous avons pu tirer parti des webhooks de Space avec TeamCity pour générer chaque branche révisée et la déployer vers notre assurance qualité afin de tester la branche avant de la fusionner. Il est désormais également plus facile de savoir qui est absent du bureau.