Como a Gearbox usa o TeamCity para otimizar seu processo de CI/CD

Informações da empresa

A Gearbox é uma empresa americana de videogames com sede em Frisco, Texas, perto de Dallas. Fundada em 1999, a Gearbox produziu alguns dos videogames mais icônicos da história, incluindo o Half-Life, o Brothers in Arms e o Borderlands.

Sentamos com Steve Fortier da Gearbox, engenheiro-chefe de lançamentos, e Phillip Peterson, engenheiro de lançamentos sênior, para falar sobre como a empresa foi capaz de padronizar e aprimorar seus processos de CI/CD com a ajuda do JetBrains TeamCity.

Sobre a equipe

Steve e Phillip fazem parte da equipe principal de engenharia de lançamentos da Gearbox. A equipe está espalhada por Quebec, Montreal e Frisco e tem como missão atender a todos os projetos da empresa, configurando a automação de acordo com a necessidade de cada um. Sempre que um novo projeto é iniciado, a equipe imediatamente configura um depósito no Perforce e garante que haja um projeto no TeamCity vinculado a ele.

A equipe tenta dedicar uma pessoa para cada projeto. Cada engenheiro de lançamento faz parte da equipe de lançamento e também de um projeto de jogo. Isso permite que a equipe responda ao que cada projeto precisa em termos de automação.

Ele também permite que os engenheiros de lançamento compartilhem conhecimentos sobre as melhores práticas do TeamCity e entrem em ação rapidamente caso outro projeto precise de ajuda. Graças às práticas padronizadas de CI/CD e aos modelos de projeto reutilizáveis, eles podem reagir rapidamente a qualquer problema.

Pilha de tecnologias da Gearbox

A equipe trabalha tendo o Perforce como sistema de controle de versão e o Unreal como mecanismo de jogo. Eles criaram scripts C# baseados no Unreal, e são com eles que o TeamCity interage. Essa camada é independente do CI e permite que eles trabalhem com projetos Unity e Unreal.

A equipe também usa a AWS para criar máquinas e armazenamento por meio do Artifactory, para o qual eles usam o plug-in JFrog do TeamCity.

Por que a equipe decidiu procurar uma nova solução de CI/CD

A solução anterior de CI/CD usada pela Gearbox tinha algumas limitações. Ou seja, a solução estava mal integrada ao Perforce. A ferramenta de CI/CD que a equipe estava usando também não oferecia builds pessoais, que estão disponíveis no TeamCity, e a transmissão de informações entre as etapas de build provou ser um desafio.

“Tínhamos um produto que usamos internamente há muito tempo. Procuramos mudar para um concorrente diferente e nenhum deles funcionou. Então, alguns colegas nossos que vieram de outra empresa de jogos disseram: "Costumávamos usar esse tal de TeamCity". Então demos uma olhada e entendemos que o TeamCity resolvia vários dos nossos problemas.”

— Phillip Peterson, Senior Release Engineer

Simplificando conexões entre etapas de build com o TeamCity

Num dos prdutos concorrentes que a Gearbox estava usando, o processo de estabelecer uma conexão entre duas etapas de build era bastante complicado. Por exemplo, se eles tivessem uma etapa de build que produzia um artefato e quisessem transmitir o nome desse artefato para uma tarefa subsequente, o simples início da conversa entre duas etapas de build já seria um grande obstáculo. Por outro lado, fazer isso com o TeamCity pareceu ser extremamente fácil.

A equipe estava sofrendo com a transferência dos resultados dos builds entre as etapas de build, e o TeamCity permitiu que eles fizessem isso com uma dependência.

Os critérios de seleção para uma nova solução de CI/CD

Aplicando alterações em massa entre projetos

Em uma nova solução de CI/CD, a equipe estava à procura de duas coisas principais. Uma era a capacidade de aplicar alterações em massa em projetos com facilidade. Anteriormente, eles precisavam começar cada projeto do zero. À medida que o número de projetos crescia, a equipe começou a procurar modelos que permitissem copiar e colar as configurações do projeto, alterar o nome e executar o projeto.

UI amigável

O segundo requisito era uma UI amigável que facilitasse o trabalho dos usuários finais e administradores com a nova ferramenta de CI/CD.

"Um dos concorrentes tinha uma UI muito hostil. A sensação que as pessoas deveriam ter quando encontram um sistema CI/CD é que ele é muito resistente e não quebrará quando tentarmos fazer alguma coisa nele. Acho que o TeamCity tem uma UI muito robusta. Você tem confiança de que é um sistema que funciona bem quando utilizado."

— Steve Fortier, Lead Release Engineer

A UI refinada do TeamCity facilitou as vendas. Depois que a equipe provou que o conceito funcionaria, bastou mostrá-lo às pessoas para convencê-las rapidamente a mudar para a nova solução de CI/CD.

Gerenciamento de acesso

Outro fator na escolha da Gearbox de uma nova solução de CI/CD foi o gerenciamento do acesso e como ele funciona no TeamCity. A equipe estava procurando uma maneira de editar o acesso do usuário por projeto.

No TeamCity, é possível criar hierarquias nas quais as pessoas recebem acesso a um projeto e podem acessar todos os seus subprojetos. Isso fez uma grande diferença para a Gearbox.

Escolhendo entre o TeamCity Cloud e o On-Premises

Quando a equipe ouviu falar do TeamCity, eles inicialmente experimentaram a versão on-premises. No entanto, a opção de usar o TeamCity Cloud deixou o departamento de TI da Gearbox extremamente feliz, sabendo que tudo o que eles precisavam fazer era configurar a autenticação. Também tornou a transição significativamente mais rápida do que suas estimativas caso tivessem instalado a versão on-premises.

Os usuários do TeamCity Cloud podem escolher entre agentes de build hospedados pela JetBrains e auto-hospedados. A equipe da Gearbox utiliza agentes auto-hospedados, o que lhes permite personalizar totalmente o ambiente onde executam seus builds.

O processo de transição

Ao fazer a transição para o TeamCity, a equipe começou a configurar todos os seus projetos do zero. No entanto, eles deliberadamente deixaram seus scripts de build antigos independentes do sistema de CI. Isso significava que, embora eles começassem a configurar muitos novos projetos no TeamCity, basicamente copiavam e colavam comandos existentes do sistema antigo.

Com alguns workshops para discutir como organizar os projetos, a equipe conseguiu mudar da antiga solução de CI para o TeamCity em apenas 6 semanas.

Métricas de CI/CD

Atualmente, a Gearbox possui 340 committers e 138 projetos no TeamCity Cloud.

A equipe usa agentes hospedados em suas próprias contas da AWS. Eles também usam perfis de nuvem do TeamCity. Dependendo das necessidades de um build, o TeamCity seleciona automaticamente as instâncias "base", "high", "mega" ou "GPU" que a equipe usa.

Durante o período de transição, a Gearbox usou a Amazon Machine Image (AMI) que estava em execução para sua solução de CI/CD anterior e instalou o TeamCity do lado dela. Dessa forma, a Gearbox apenas precisou manter uma única AMI, já que a mesma era utilizada tanto pelo sistema antigo quanto pelo novo. Isso facilitou ainda mais o processo de migração.

Crie cadeias no TeamCity

A Gearbox usa cadeias de build extensivamente em todo o processo de CI/CD. O processo Unreal passa por cinco etapas: compilação, preparação, preparo, empacotamento e publicação.

Se um jogo está para ser lançado em menos de 12 horas, e em algum lugar dessa cadeia um volume fica lotado e interrompe o processo, é impossível expandir o volume e começar de novo. Simplesmente não há tempo suficiente para fazer isso.

Com a ajuda do TeamCity, a equipe da Gearbox conseguiu separar cada uma dessas peças em seu próprio build. Dessa forma, se o volume ficar lotado e precisar ser estendido durante o processo de build, o build falhará, mas a equipe poderá lidar com isso rapidamente. Eles podem reiniciar o processo de onde ele foi interrompido, remontar esse volume persistente e continuar de onde parou. Isso é possível graças às otimizações da cadeia de build integrada do TeamCity, que são facilitadas pela reutilização de builds ao empregar dependências de snapshots.

Processo de teste da Gearbox: de local a centralizado com orquestração dinâmica

Na Gearbox, depois que os desenvolvedores executam testes locais, o TeamCity pode fazer muito mais, executando todo o conjunto de testes centralmente. O sistema de CI/CD também pode orquestrar dinamicamente essas execuções de teste em diferentes tipos de máquinas, ativando quantas máquinas forem necessárias em um determinado momento e desligando-as posteriormente para otimizar os recursos.

Simplificando a configuração de projetos e o compartilhamento de recursos com o TeamCity na Gearbox

Compartilhamento de conhecimento facilitado

Um dos maiores desafios que o TeamCity ajudou a Gearbox a resolver foi criar novos projetos. Com as alternativas exploradas, cada projeto tinha que ser feito do zero. À medida que os projetos cresciam com o tempo, eles divergiam entre si, tornando-se diferentes o suficiente para que a empresa precisasse de um especialista no assunto para cada projeto. Isso dificultava o compartilhamento de conhecimento entre as equipes, causando gargalos no processo de desenvolvimento e aumentando o risco de erros e inconsistências.

Maior produtividade

Desde que a equipe adotou o TeamCity como sua solução de CI/CD, as coisas ficaram significativamente mais fáceis. Graças ao modelo que a equipe conseguiu criar, eles podem compartilhar recursos entre projetos. Ao se familiarizar com um projeto, você acaba se familiarizando com todos eles. Isso ajudou a equipe a aumentar a produtividade e se concentrar no desenvolvimento eficiente.

Economias significativas em termos de instâncias do EC2

Na solução de CI anterior da Gearbox, cada build construia o editor, o que poderia levar até uma hora. Agora, a equipe pode realizar essa etapa no seu próprio build, que é reutilizado em todos os lugares. Isto ajudou a equipe a economizar significativamente em termos de instâncias do EC2, porque eles não precisam compilar a mesma coisa várias vezes.

Configuração como código no Gearbox

Quando a Gearbox começou a usar o Kotlin para configuração de projetos, a equipe ficou muito animada. Mesmo aqueles que tinham pouca experiência com Kotlin conseguiram decifrá-lo e começar a usá-lo rapidamente. "Existe uma curva de aprendizado, mas, em geral, a vibe era positiva", disse Steve Fortier.

Do jeito que as coisas estão agora, quando a equipe precisa mudar alguma coisa em um projeto, eles usam a UI. Se eles precisarem alterar a maneira como uma determinada configuração de build funciona em múltiplos projetos, eles usarão o Kotlin. A capacidade de usar com flexibilidade essa abordagem híbrida para projetar configurações é outro dos destaques do TeamCity para a Gearbox.

Os planos da Gearbox para o futuro

A Gearbox visa aprimorar o uso do TeamCity implementando builds pessoais para aumentar a confiança nos commits e fornecendo builds funcionais para testes de controle de qualidade. A equipe também procura melhorar a velocidade dos builds, encurtar as cadeias de build e minimizar as falhas.

Atualmente, eles monitoram o desempenho do servidor, a duração do build e suas falhas, mas planejam incluir métricas mais granulares, tais como tamanho do artefato e duração da fila. Seu objetivo é aproveitar a gama de recursos personalizáveis do TeamCity para estabelecer um processo de CI mais eficiente que economize tempo e garanta a confiabilidade de seus builds.

Conclusão

Mudar para o TeamCity Cloud melhorou as práticas de CI/CD da Gearbox de várias maneiras.

• A facilidade de adoção permitiu que a equipe migrasse de sua solução de CI anterior para o TeamCity em apenas 6 semanas.
• A integração com o Perforce incorporada do TeamCity ajudou a equipe a simplificar todo o processo de CI/CD e economizou o tempo que eles teriam gastado criando soluções alternativas de integração.
• Com o modelo de projeto do TeamCity, a equipe agora pode lançar novos projetos com muito mais rapidez e menos esforço, seguindo uma prática padronizada.
• Graças à solução em nuvem e à UI amigável do TeamCity, a equipe percebeu que a manutenção de projetos ficou muito mais fácil do que antes.

O TeamCity também ajuda a Gearbox a obter economias significativas em termos de instâncias do EC2, já que a capacidade de usar dependências permite evitar compilar a mesma coisa várias vezes.