Setor: Desenvolvimento de software

Produtos da JetBrains usados: TeamCity

Tamanho da organização: 200

País: Estados Unidos

Gradle

A Gradle Build Tool é uma ferramenta open source popular de automação de compilação usada por milhões de desenvolvedores para compilar, testar e implantar projetos de software. A Gradle está no centro do pipeline de entrega contínua em muitas das empresas de SaaS mais populares do mundo, incluindo o LinkedIn e a Netflix.

Como a Gradle Build Tool usa o TeamCity para executar 30.000 builds sustentáveis por dia

A Gradle Build Tool é uma popular ferramenta open-source para automação de builds de código usada por milhões de desenvolvedores para compilar, testar e implantar softwares. O TeamCity é uma solução de CI/CD de uso geral que possibilita workflows flexíveis, colaboração e práticas de desenvolvimento.

Neste estudo de caso, examinaremos detalhadamente como a Gradle Build Tool usa o TeamCity para executar dezenas de milhares de builds por dia, enquanto mantém a taxa de falhas sob controle.

"Confiamos no TeamCity como nosso sistema de CI preferido há mais de uma década. Ele fornece todos os recursos de que precisamos, prontos para uso. Também apreciamos sua confiabilidade e gostamos do Kotlin DSL para configurar nossos pipelines de build."

— Piotr Jagielski, vice-presidente de engenharia da Gradle Build Tool

Sobre a Gradle Inc.

A Gradle, Inc. é a empresa por detrás da Gradle Build Tool, que é uma das ferramentas open source de automação de builds mais populares do setor, e da Gradle Enterprise, que é a plataforma de solução líder para melhorar a produtividade dos desenvolvedores. Com sede em San Francisco, Califórnia, a Gradle emprega cerca de 200 pessoas em 30 países para construir a ferramenta open source e a plataforma corporativa que atendem a milhões de desenvolvedores em todo o mundo.

A Gradle tem mais de 100 engenheiros trabalhando em duas bases de código principais: Gradle Build Tool e Gradle Enterprise. Cada uma inclui milhões de linhas de código. A empresa usa o TeamCity para ambas as bases de código, mas este estudo de caso se concentrará no desenvolvimento da Gradle Build Tool.


TeamCity na Gradle Inc.

Nos últimos 10 anos, a equipe da Gradle Build Tool tem contado com o TeamCity para seu processo de CI/CD. Durante esse tempo, a equipe nunca perdeu uma atualização do TeamCity. Atualizações regulares permitem que a equipe tenha sempre a versão mais recente e repleta de recursos do produto.


Pilha de tecnologias da Gradle

A equipe da Gradle Build Tool usa o Git e o GitHub como sistema de controle de versão. Eles escrevem código em Java, Kotlin e Groovy. Naturalmente, a equipe usa seus próprios produtos: a Gradle Build Tool para automação de builds e a Gradle Enterprise para aceleração de builds e análise de falhas. Eles contam com o TeamCity como sua solução de CI para executar qualquer coisa que não queiram executar localmente: build, implantação, cron jobs, provisionamento de agentes e muito mais.


Pipeline de CI da Gradle

A Gradle Build Tool possui um conjunto de testes abrangente que verifica se o produto funciona corretamente em diferentes sistemas operacionais, versões do Java e outros componentes. O build completo "pronto para lançamento" abrange mais de 150 mil testes. Além disso, alterações devem passar com sucesso pela suite de desempenho antes de serem integradas ao branch principal. Isso requer uma configuração complexa de CI com centenas de agentes de build.

Tipos de agentes de build

A Gradle usa agentes de build Windows, Linux e macOS. Cerca de metade dos agentes são máquinas físicas. A equipe também utiliza agentes spot do Amazon EC2. Isso ajuda a Gradle a manter a velocidade dos builds mesmo quando a demanda é alta.

Graças ao suporte integrado a instâncias Spot do TeamCity, a equipe nunca tem problemas com a desconexão dos agentes. O TeamCity reinicia automaticamente os builds no caso de uma instância Spot desaparecer.

Principais métricas de CI/CD

A configuração do TeamCity para a Gradle Build Tool está disponível publicamente e visível para qualquer pessoa. O branch principal (master) consiste em cerca de 500 configurações de build definidas em uma cadeia muito sofisticada. Como observa Piotr: "Na Gradle, usamos cadeias de builds de maneira bastante extensiva. Na verdade, não podemos viver sem elas".

Devido à complexidade da cadeia, a Gradle depende do Kotlin DSL para configurar seus pipelines.

Parte da cadeia de builds da Gradle Build Tool. Acesse a versão completa aqui. Você pode fazer login como convidado para visualizá-la.
Parte da cadeia de builds da Gradle Build Tool. Acesse a versão completa aqui. Você pode fazer login como convidado para visualizá-la.

A Gradle tem 200 agentes de build fixos e 200 agentes do EC2 elásticos adicionais para gerenciar picos conectados através de perfis de nuvem. O tempo total para executar builds por semana é de 283 dias (ou 6.792 horas).

Ao mesmo tempo, cerca de 1.636 dias por mês estão sendo otimizados pelo TeamCity. Algoritmos inteligentes permitem que o TeamCity decida se o build não deve ser executado devido ao fato de outro build já ter sido executado no mesmo commit do repositório.

A Gradle usa cadeias de build, e o TeamCity ajuda a equipe a economizar uma quantidade significativa de tempo de compilação reutilizando os builds.

O número de agentes usados
O número de agentes usados

Graças à capacidade do TeamCity de fornecer métricas de servidor compatíveis com o Prometheus, a equipe pode exportar automaticamente os dados de build para o Grafana para visualização e análises adicionais. A equipe rastreia métricas como tempo de espera na fila de builds, uso de agentes do TeamCity, comprimento da fila e número de agentes conectados.

Com base nisso, a equipe pode decidir se precisa comprar mais agentes de build se o uso ficar muito alto.

Uso de agentes do TeamCity na Gradle
Uso de agentes do TeamCity na Gradle

Monitorando o tempo de feedback

Fornecer feedback o mais rápido possível está no centro de qualquer solução de CI. Monitorar o tempo de feedback ajuda a equipe de produtividade do desenvolvedor da Gradle a entender quanto tempo os engenheiros precisam esperar até o merge de suas solicitações pull.

Tempo médio de espera dos builds enfileirados na Gradle
Tempo médio de espera dos builds enfileirados na Gradle

Para rastrear isso, a equipe do Gradle Build Tool fica de olho no build Trigger, um build composto que agrega resultados de vários outros builds combinados por dependências de snapshot e os apresenta num só lugar.

O tempo de feedback varia dependendo da complexidade da solicitação pull. Solicitações pull mais simples recebem feedback em 10 minutos, enquanto em casos mais complexos pode levar até uma hora. Como a Gradle é open source, todas as solicitações pull provenientes da comunidade do GitHub passam pelo mesmo processo de build.

Projetos de branches master da Gradle Build Tool no TeamCity
Projetos de branches master da Gradle Build Tool no TeamCity

Gatilho de build

Devido a considerações de custo, nem todos os gatilhos de commit disparam builds. Em vez disso, os desenvolvedores podem facilmente disparar um build comentando na solicitação pull relacionada, e um bot chamará a API do TeamCity para acioná-la.

Alguns branches, como master e release, são tratados de forma diferente. Qualquer push nesses branches aciona uma compilação do TeamCity.

Kotlin DSL: uma revolução

O Kotlin DSL faz uma enorme diferença ao ajudar a equipe da Gradle a gerenciar a complexidade das dependências de build. Ao armazenar a configuração do projeto como código, a equipe é capaz de replicar com eficiência a lógica dos builds entre projetos, aplicar atualizações de forma consistente a diversas configurações e gerenciar sistematicamente seus pipelines.

Com a ajuda do Kotlin DSL, a equipe pode gerar e testar dependências de build com muito menos esforço. A equipe usa o Kotlin DSL com a edição de UI na Web desabilitada para quase todos os seus projetos.


Gradle Build Tool + TeamCity: a maior conquista

O TeamCity acelera todo o processo de CI/CD para a Gradle. Com a ajuda do TeamCity, a Gradle Build Tool executa com sucesso 30.000 builds sustentáveis por dia, mantendo a taxa de falhas sob controle.

O TeamCity é uma solução completa para a equipe da Gradle devido à sua abundante funcionalidade. Ele tem todos os recursos que as outras ferramentas também têm, além de muitos outros que são exclusivos.

O Kotlin DSL oferece à Gradle Build Tool um nível de flexibilidade sem precedentes, que permite à equipe criar rapidamente uma cadeia de builds complexa e testá-la. A equipe também executa testes nos arquivos de configuração do Kotlin DSL. A configuração do TeamCity da Gradle é open source e está disponível no GitHub.

Por fim, a equipe da Gradle Build Tool valoriza a confiabilidade do TeamCity. A equipe atualiza para cada nova versão do TeamCity assim que ela fica disponível e raramente encontra problemas. O TeamCity gerencia mais de 400 agentes de build, mas a equipe quase nunca precisa solucionar problemas de conexão ou de agente de build.


Dimensionando a infraestrutura daqui para frente

A equipe da Gradle Build Tool está comprometida em garantir que sua infraestrutura seja dimensionada à medida que a equipe cresce. Mesmo que o tamanho da equipe dobre no futuro, a Gradle pretende manter o tempo de feedback atual ou reduzi-lo ainda mais.

A equipe da Gradle Build Tool planeja atingir esse objetivo ambicioso adotando totalmente práticas de Engenharia para Produtividade dos Desenvolvedores, aumentando a automação a fim de eliminar a intervenção humana e adicionando mais agentes de build em todo o processo de CI/CD.

Histórias de clientes semelhantes

Picnic

Ivan Babiankou, Engenheiro de Software, Picnic

Estávamos procurando uma solução gerenciada para todos os nossos casos de uso de CI. Além disso, precisávamos de agentes autohospedados para controlar qual software estamos executando e quais ferramentas estão em uso exatamente. O TeamCity Cloud com agentes autohospedados forneceu uma solução sob medida que nossa equipe de mais de 300 engenheiros utiliza com prazer e que leva nossa produtividade para um novo patamar.

Gearbox

Phillip Peterson, Senior Release Engineer

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". Analisamos e entendemos que o TeamCity resolveu muitos dos nossos problemas.

Playrix

Yuri Trufanov, Diretor Técnico Executivo de Plataformas Tecnológicas

Acabamos com uma solução de nuvem híbrida incluindo Perfis do TeamCity Cloud e a AWS. Além disso, tínhamos computadores on-premises para agentes de compilação. Essa combinação nos permitiu acomodar qualquer número de compilações ao longo do dia, ao mesmo tempo em que proporcionou uma contagem básica de agentes para as horas de folga. Assim, poderíamos executar o que quiséssemos e onde quiséssemos.

Mais histórias de clientes