Como a equipe de infraestrutura do IntelliJ reduz em 30% o tempo de execução de builds com o TeamCity

O desafio: dimensionar a CI/CD para centenas de desenvolvedores

Com uma grande equipe de desenvolvedores fazendo alterações constantes, manter pipelines de CI/CD rápidos, confiáveis e dimensionáveis não é uma tarefa simples. A equipe de infraestrutura do IntelliJ precisa de uma solução capaz de lidar com escala maciça, com a capacidade de executar milhares de builds por dia sem sobrecarregar os recursos disponíveis. Eles também precisam de automação inteligente para minimizar a intervenção manual e, ao mesmo tempo, garantir a entrega de código de alta qualidade.

Além disso, é essencial o suporte a diversos ambientes de infraestrutura, incluindo agentes locais, AWS, macOS, Linux e Windows. Para manter a alta qualidade do código, a equipe também precisa gerenciar centenas de milhares de testes automatizados, tudo isso enquanto minimiza falhas de teste instáveis.

O TeamCity, uma poderosa solução de CI/CD desenvolvida pela JetBrains, provou ser a solução perfeita para enfrentar esses desafios.

"Criamos IDEs e tudo relacionado a eles no TeamCity, como serviços internos, serviços para estatísticas, etc. Estou muito acostumado com o TeamCity e sinto que ele é um martelo na minha mão: dá para fazer qualquer coisa com ele."

— Dmitrii Panov, líder técnico de infraestrutura do IntelliJ

Como o TeamCity ajuda a equipe de infraestrutura do IntelliJ

Safe push

O processo maior da equipe do IntelliJ atualmente envolve cada desenvolvedor fazendo push do código assim que ele está pronto, sem acumular todas as alterações em um branch e esperar que elas sejam testadas em conjunto.

Para dar suporte a esse workflow, a equipe de infraestrutura do IntelliJ implementou o mecanismo de safe push, que é essencialmente um conjunto de configurações de build compostas no TeamCity. Para os usuários, o processo é bastante simples e direto: eles simplesmente fazem push das alterações por meio de seus IDEs e pronto.

Nos bastidores, um serviço interno dedicado analisa o conjunto de alterações de safe push e usa a API REST do TeamCity para acionar as builds necessárias para testar essas alterações. Ele também reinicia builds com falha para tentar novamente os testes instáveis.

Ao possibilitar a reutilização de builds bem-sucedidas, o TeamCity ajuda a acelerar significativamente os safe pushes e a reduzir seus custos, já que a build de testes de safe push pode conter até 700.000 testes. O recurso de reutilização de builds reutiliza artefatos, dependências e resultados de testes em vez de criar tudo do zero. Isso melhora a eficiência da build, acelera os pipelines de CI/CD e reduz o consumo de recursos.

Economia de recursos com a reutilização de builds

A reutilização de builds é um dos recursos do TeamCity que a equipe considera particularmente útil. Veja como é uma cadeia de build típica do TeamCity.

Quando uma cadeia de testes não é aprovada na primeira tentativa, o mecanismo de safe push tenta novamente duas vezes para garantir que existe realmente um problema.

Vamos considerar um push típico para ver como a reutilização de builds otimiza as novas tentativas. Na primeira tentativa, todas as 329 builds da cadeia são executadas. 319 são aprovadas, mas 10 falham, então a cadeia é executada novamente. Dessa vez, apenas as 10 builds que falharam são executadas, e o restante é reutilizado. Mais 6 são aprovadas, mas faltam algumas. Portanto, na terceira tentativa, as 4 restantes precisam ser executadas, enquanto 325 são reutilizadas.

Isso reduz drasticamente a carga dos agentes de build e acelera significativamente os tempos de novas tentativas. Em vez de executar três tentativas completas, cada uma levando cerca de 3 horas, a reutilização de builds reduz o tempo de execução em cerca de 30%.

Suporte para escala maciça com desempenho contínuo

A equipe do IntelliJ executa mais de 158.000 builds para mais de 180 usuários únicos por dia, o que torna a eficiência essencial. Graças aos recursos de reutilização de builds do TeamCity:

• 75% das builds não precisam de uma nova execução completa quando um teste falha.
• Os tempos de novas tentativas são reduzidos em uma média de 30%, reduzindo significativamente os gargalos.
• Os desenvolvedores podem fazer merges contínuos sem bloquear uns aos outros, pois mais de 90 testes de safe push podem ser executados ao mesmo tempo.

Kotlin DSL

A equipe de infraestrutura do IntelliJ gerencia o TeamCity por meio do Kotlin DSL. Com o Kotlin DSL, você obtém todos os benefícios de uma linguagem de programação completa, juntamente com os pontos fortes de um DSL projetado para criar pipelines como código.

Atualmente, a instância do TeamCity contém mais de 2.000 projetos, 15.000 configurações de build e quase 300 raízes de VCS. A equipe não consegue imaginar ter que gerenciar uma instância tão grande usando outra coisa que não seja o Kotlin DSL.

"Também temos quase 350 testes de unidade apenas para as configurações do Kotlin. Não gostaria de ter essa experiência em YAML."

— Dmitrii Panov, líder técnico de infraestrutura do IntelliJ

Gerenciamento de agentes

Os poderosos recursos de gerenciamento de agentes do TeamCity tornam o dimensionamento dos pipelines de CI/CD fácil e eficiente. Ao contrário dos sistemas de CI/CD baseados em YAML, que exigem soluções alternativas complexas, como âncoras, instruções go-to e lógica de repetição manual, o TeamCity simplifica esse processo com a orquestração integrada de agentes.

Para equipes que usam a AWS, o TeamCity se integra perfeitamente à infraestrutura de nuvem, permitindo que agentes sejam automaticamente iniciados e gerenciados com base na demanda. Por exemplo, você pode configurar o TeamCity para ativar o número exato de agentes necessários em qualquer situação e desligá-los quando estiverem ociosos, garantindo a utilização ideal de recursos.

Esse nível de controle preciso dos agentes é muito mais intuitivo em comparação com outras soluções, em que plug-ins externos podem introduzir problemas de compatibilidade e exigir solução de problemas adicionais.

Em grande escala, o TeamCity lida com cargas de trabalho imensas, oferecendo suporte a filas de mais de 10.000 builds e gerenciando até 5.000 agentes de build dinamicamente. Um recurso de destaque é a capacidade do TeamCity de trabalhar com instâncias preemptivas da AWS. Se uma instância for recuperada pela AWS, o TeamCity poderá reiniciar automaticamente a build em outro agente, evitando interrupções e garantindo uma execução tranquila.

Métricas que a equipe acompanha

Ao gerenciar uma plataforma de CI/CD para centenas de desenvolvedores com dezenas de milhares de builds por dia, é importante acompanhar as métricas que mais importam. O TeamCity fornece uma série de ferramentas de diagnóstico e indicadores prontos para uso. Como o TeamCity também pode exportar métricas no formato Prometheus, você pode criar dashboards personalizados para casos de uso mais avançados.

"O TeamCity nos fornece alguns blocos de construção básicos, como estatísticas para builds ou testes. Podemos então criar algo mais sofisticado com base nessas estruturas básicas."

— Aleksei Smirnov, desenvolvedor de software da equipe de infraestrutura .NET

Aqui estão as principais métricas que a equipe de infraestrutura do IntelliJ acompanha de perto para otimizar seu processo de CI/CD com o TeamCity.

Número de builds por dia

A equipe monitora cerca de 158.000 builds diariamente para entender a carga de trabalho e o desempenho. Embora o número de builds propriamente dito não seja algo em que a equipe preste muita atenção, ele ainda é uma métrica importante para prever a carga de trabalho dos agentes de build.

Concorrência de safe pushes

A qualquer momento, 80 a 90 verificações de safe push estão sendo executadas simultaneamente. É importante que a equipe acompanhe quanto tempo leva cada verificação de safe push: quanto mais rápido elas forem executadas, mais rápida será a build.

Eficiência na reutilização de builds

A equipe analisa quantas builds são reutilizadas durante as novas tentativas, reduzindo a necessidade de execução redundante e economizando recursos.

Execução de testes

Há quase 700.000 testes em uma build composta no projeto IntelliJ TeamCity.

A equipe acompanha mais de 700.000 testes por cadeia de safe push para identificar falhas. Ela também mede a instabilidade dos testes, repetindo automaticamente os testes que falharam e silenciando os instáveis para investigação adicional.

Uma das métricas que a equipe está tentando melhorar é o número de tentativas necessárias para uma execução de sucesso. Isso os ajudará a economizar recursos e tempo em cada execução.

Utilização de agentes

A equipe monitora mais de 5.000 agentes de build físicos e da AWS, otimizando a alocação de recursos com funcionalidades como a reutilização de builds, que ajuda a reduzir o tempo de build em cerca de 30%.

Coisas que poderiam ser melhoradas no TeamCity

Embora a equipe de infraestrutura do IntelliJ use o TeamCity diariamente para um grande número de tarefas e perceba que ele os ajuda a resolver muitos problemas, há algumas coisas que eles gostariam que fossem adicionadas.

Funcionalidade específica da equipe

Embora o TeamCity permita o acesso a todas as cadeias de build e projetos dentro de uma organização, os desenvolvedores geralmente precisam de uma visão mais focada de suas builds relevantes. Por exemplo, o ideal é que um desenvolvedor que esteja trabalhando no PyCharm veja apenas as builds, os testes e as configurações específicos do PyCharm, sem precisar navegar por projetos não relacionados.

Um dashboard simplificado, exibindo apenas configurações de build, de testes e de testes silenciados relevantes, melhoraria significativamente a usabilidade. A equipe tentou resolver esse problema criando uma solução baseada no Grafana, mas uma abordagem mais integrada e fácil de usar no TeamCity seria ideal.

Gerenciamento de testes silenciados

A equipe acredita que o TeamCity se beneficiaria muito com um sistema de gerenciamento de silenciamento. Considerando o alto volume de testes automatizados, alguns testes precisam inevitavelmente ser silenciados. Embora o TeamCity ofereça a funcionalidade de silenciar testes, ainda é muito fácil silenciar um teste e esquecê-lo, o que complica o trabalho de outros colegas que precisam usá-lo.

Um sistema dedicado de gerenciamento de silenciamento, onde as equipes possam visualizar, gerenciar e rastrear facilmente testes silenciados relevantes para seus projetos, ajudaria a garantir melhor propriedade e transparência.

Conclusão

A equipe de infraestrutura do IntelliJ dominou a eficiência de CI/CD em grande escala com o TeamCity, simplificando as builds, otimizando o uso de recursos e reduzindo significativamente os tempos de execução. Ao aproveitar o safe push, a reutilização de builds e as tentativas de teste automatizadas, eles reduziram os tempos de execução de builds em 30%, garantindo que 700 a 800 desenvolvedores possam fazer alterações sem problemas.

A história da equipe de infraestrutura do IntelliJ prova que o TeamCity não é apenas uma ferramenta de CI/CD: ele é a espinha dorsal do desenvolvimento de software em larga escala.