A Uber cria o GitFarm para fornecer operações Git como serviço para monorepos em grande escala
A Uber criou o GitFarm, uma plataforma de «Git como Serviço» destinada a executar operações Git nos seus monorepos em grande escala. Ao transferir as operações dos repositórios para um serviço partilhado, o GitFarm elimina a necessidade de clones locais nos sistemas dos clientes e reduziu a utilização de recursos do lado do cliente em mais de 80%.
Os sistemas de automatização da Uber invocam o Git milhões de vezes por dia em monorrepositórios que suportam Go, Java, Python, Web, Android e iOS. Anteriormente, os serviços individuais mantinham checkouts completos dos repositórios, incluindo para operações como a leitura de ficheiros, a validação de alterações e o cálculo de bases de fusão. A clonagem do monorepositório Go da Uber demora cerca de 15 minutos e requer aproximadamente seis núcleos de CPU, 32 GB de memória e mais de 40 GB de espaço em disco.
A equipa de engenharia da Uber afirmou numa publicação no LinkedIn a descrever o GitFarm que o serviço fornece checkouts completos do Git em menos de 500 milissegundos e elimina os arranques a frio históricos de 10 a 15 minutos ao nível do anfitrião.
A clonagem local e a sincronização repetitiva de repositórios transformam os fluxos de trabalho tradicionais do Git num importante estrangulamento da infraestrutura
Arquitetura do GitFarm (Fonte: Publicação no blogue da Uber)
O GitFarm expõe as operações do Git através de uma API gRPC de alto desempenho. Não se trata de um sistema de gestão de controlo de código-fonte. Em vez disso, funciona como um cliente Git centralizado que executa comandos Git padrão em nome de outros serviços. Um Gateway autentica e autoriza os pedidos antes de os encaminhar para os clusters de backend, onde os comandos são executados em sandboxes isoladas e efémeras.
O backend mantém clones «bare» dos repositórios e mantém-nos sincronizados com os repositórios upstream utilizando atualizações baseadas em «push» e «fetches» periódicos. Também mantém conjuntos de checkouts de repositórios e contentores de sandboxes. Quando chega um pedido, o GitFarm pode montar um checkout pré-aquecido numa sandbox disponível, em vez de criar um clone do repositório e um ambiente de execução a partir do zero. A Uber relata que este agrupamento reduz o tempo de resposta necessário para fornecer um checkout pronto a utilizar para menos de um segundo.
O GitFarm suporta fluxos de trabalho com múltiplos comandos através de sessões de streaming gRPC bidirecionais. Os comandos podem ser executados sequencialmente no mesmo checkout, permitindo fluxos de trabalho como a obtenção de um ramo, o cálculo de uma base de fusão e o envio de uma referência derivada sem ter de inicializar repetidamente o estado do repositório. Os clientes também podem executar explicitamente o `git fetch` quando necessitam do estado mais recente do upstream, enquanto as cargas de trabalho que toleram um certo atraso podem utilizar o estado sincronizado do repositório do backend.
Arquitetura do backend do GitFarm (Fonte: publicação no blogue da Uber)
A Uber relata que um serviço de gestão de propriedade de código eliminou os checkouts locais em seis hosts após a adoção do GitFarm, reduzindo o consumo de CPU de mais de 70 núcleos para 16 e a memória de 400 para 32 GB. O tempo de arranque passou de 15 a 20 minutos para menos de um minuto. Um serviço de auditoria de conformidade que processa entre 10 000 e 20 000 eventos por hora em 9 000 repositórios reduziu a latência mediana de 110 a 160 segundos com o Buildkite para 20 a 30 segundos com o GitFarm, eliminando a sobrecarga de agendamento, inicialização do espaço de trabalho e a sobrecarga de sincronização de repositórios.
A arquitetura também poderia suportar cargas de trabalho de agentes de codificação. Ashish Verma observou no LinkedIn que os agentes repetidamente pesquisam, criam ramos, comparam diferenças, experimentam, tentam novamente e validam alterações, tudo em simultâneo, o que pode aumentar as cargas de trabalho da infraestrutura Git.
Em produção desde o início de 2025, o plano de desenvolvimento do GitFarm inclui a transmissão contínua de resultados do Git, checkouts esparsos, espaços de trabalho «bare», sessões de maior duração, espelhamento de repositórios e integração com o SubmitQueue.