Construir aplicativos em escala não é nada comparado a construir um sistema operacional como o Windows, especialmente quando se trata de controle de código-fonte. Como você gerencia o repositório (ou repositórios) de um gigante de software, com milhares de desenvolvedores e testadores e com um pipeline de construção complexo que fornece continuamente código novo?
A história da Microsoft com sistemas internos de controle de origem é complicada. Você pode pensar que ele usava o Visual SourceSafe, agora descontinuado, mas era mais apropriado para sistemas de arquivos locais e projetos menores. Em vez disso, a Microsoft usou muitas ferramentas diferentes ao longo dos anos, inicialmente uma bifurcação interna do familiar Unix Revision Control System, antes de padronizar o Perforce Source Depot.
Git bate em uma parede em Redmond
Enquanto isso, algumas partes da empresa usavam o Team Foundation Server do Visual Studio, antes de passarem a usar o Git como base de uma plataforma de engenharia comum para toda a empresa. O Team Foundation Server oferece suporte ao Git, e a combinação de uma ferramenta visual e linha de comando oferece suporte a vários casos de uso diferentes na Microsoft.
Essa mudança fez muito sentido, já que o Git foi projetado para lidar com as complexidades do gerenciamento de uma enorme base de código com um grande número de desenvolvedores distribuídos globalmente. Não é surpreendente que existam muitas semelhanças entre a forma como o Windows e o Linux são construídos, e o Git possui recursos que funcionam bem para ambos.
No entanto, há um grande problema para um repositório enorme como o Windows. Apesar de toda a sua complexidade e de suas muitas partes móveis, ferramentas como o Windows e o Office são desenvolvidas em repositórios únicos, monorepos enormes que ocupam grandes quantidades de espaço de armazenamento – cerca de 300 GB e 3,5 milhões de arquivos somente para o Windows. O problema decorre de como o Git trata os repositórios: replicando-os, e cada alteração, para cada cópia. Para o Windows, o tamanho do repositório sobrecarregaria rapidamente os PCs dos desenvolvedores e obstruiria rapidamente a rede do desenvolvedor.
Entre no GVFS – o sistema de arquivos virtuais Git
Um repositório massivo poderia ser viável se todos os seus desenvolvedores trabalhassem em uma única rede de comunicações ultrarrápida e rede de armazenamento de alta velocidade, mas certamente não é quando você é uma equipe distribuída globalmente que mistura escritórios e trabalhadores domésticos. A Microsoft precisava desenvolver uma maneira de tratar um repositório Git como um sistema de arquivos virtual, criando arquivos locais somente quando necessário, em vez de copiar o repositório inteiro em uma rede desconhecida.
A ferramenta resultante equilibra os recursos do Git com as necessidades de desenvolvimento da Microsoft. Isso não altera em nada o Git, embora sacrifique os recursos off-line do Git. Essa foi uma boa decisão, quando a grande maioria dos desenvolvedores da Microsoft trabalhava em Redmond.
O Git Virtual File System, GVFS, fornecido como um driver do sistema de arquivos do Windows, foi projetado para monitorar seu diretório de trabalho e sua pasta .git, baixando apenas o que é necessário para o trabalho que você está fazendo e verificando apenas os arquivos necessários. Você ainda pode ver o conteúdo do repositório, como se fosse uma extensão do sistema de arquivos do seu PC, da mesma forma que os arquivos do OneDrive são baixados apenas quando você os seleciona explicitamente.
À medida que a Microsoft começou a usar o GVFS, ela percebeu vários casos extremos que mostravam que o Git estava fazendo trabalho desnecessário nos arquivos, então seus engenheiros passaram a fornecer correções para esses problemas no projeto Git. Essas correções foram projetadas para melhorar o desempenho do Git para grandes repositórios, permitindo que a Microsoft mudasse para um enorme monorepo interno para controle de origem.
Ampliando o Git com Scalar
As coisas não pararam por aí. Agora estamos na terceira versão pública do trabalho da Microsoft para dimensionar o Git, desta vez como parte do fork do Git da própria empresa – uma distribuição Git de propósito especial projetada para suportar monorepos.
A versão atual baseia-se no trabalho lançado em 2020 como Scalar. Scalar é um aplicativo que acelera qualquer repositório Git, não importa onde esteja hospedado. Requer a implementação personalizada do Git da própria Microsoft, embora o objetivo de longo prazo seja ter grande parte do código necessário do lado do servidor como parte do lançamento oficial do Git. Scalar é uma ferramenta opinativa, com foco em melhorar o desempenho do Git.
Scalar é um aplicativo de linha de comando .NET executado em segundo plano, gerenciando repositórios registrados. Você pode usá-lo junto com o GVFS ou como um acelerador independente, aproveitando os recursos recentes do Git. A Microsoft usa Scalar com GVFS internamente, colocando servidores de cache entre seus repositórios e os PCs dos desenvolvedores. O GVFS não é essencial para o Scalar, mas certamente ajuda.
Uma vez instalado e em execução, o Scalar pode ser usado junto com um cliente Git tradicional, clonando repositórios usando um cache local ou um servidor de cache remoto e gerenciando seu repositório local. O padrão é fazer uma verificação esparsa, o que permite que Scalar, como a Microsoft colocou na postagem do blog de anúncio, “concentre-se nos arquivos que importam”.
Scalar configura os clones locais, então os desenvolvedores podem usar o Git normalmente. Isso é resolvido oferecendo uma abordagem em camadas para gerenciamento de arquivos: um índice de alto nível de todos os arquivos em um repositório (que pode ser muitos milhões), um diretório de trabalho esparso dos arquivos que você pode precisar para a tarefa em que está trabalhando e finalmente, um conjunto de arquivos que você modificou.
Gerenciando o Git em segundo plano
Grande parte do trabalho do Scalar acontece em segundo plano, para que recursos como a coleta de lixo do Git não bloqueiem commits ao reescrever e atualizar arquivos. Scalar faz isso definindo configurações principais do Git para evitar operações em primeiro plano. Você ainda usa o Git normalmente, mas o que poderia ser uma operação de manutenção de repositório com uso intensivo de processador e de rede é transferida para o processo escalar em segundo plano, onde eles podem operar com uma prioridade mais baixa sem afetar o trabalho que você está fazendo.
Com um conjunto de índices gerenciando seu diretório de trabalho, Scalar usa GVFS para clonar repositórios usando apenas os arquivos raiz, baixando arquivos adicionais conforme necessário. Os arquivos são armazenados dentro de um diretório escalar, com o diretório de trabalho em um subdiretório src. Essa estrutura de arquivos permite gerenciar compilações e ramificações localmente.
O trabalho da Microsoft no Scalar levou-a a lançar sua própria distribuição Git com o Scalar CLI. Você pode encontrar versões do Git da Microsoft para Windows, macOS e Linux (como um pacote Debian, com outras distribuições precisando compilar a partir do código-fonte). Há também uma versão portátil do Windows. A Microsoft agora está chamando seus recursos de “recursos avançados do Git”, uma abordagem que dá sentido ao trabalho que está fazendo para provar como o Git pode funcionar em grande escala.
Se quiser experimentar, primeiro você precisa configurar seu próprio servidor Git, pronto para hospedar seus próprios repositórios. Você pode usar ferramentas Git familiares para executar, armazenar código e artefatos, antes de mudar para Scalar e GVFS. Embora Scalar funcione com outras implementações Git, você deve procurar uma que suporte a opção de clone parcial, que é a alternativa oficial ao GVFS.
A versão atual do Microsoft Git inclui melhorias no servidor para garantir que monorepos massivos se comportem como repositórios menores, sem a necessidade de ferramentas adicionais para construir compilações de múltiplas fontes.
Por que escalar?
Você pode pensar no Scalar como um campo de provas para a direção que a Microsoft gostaria que o Git seguisse. Forking Git permite que a empresa experimente esses recursos antes de oferecê-los de volta à comunidade Git mais ampla. É uma abordagem razoável que disponibiliza o código para a comunidade avaliar antes que alguém faça uma solicitação pull.
Com tantos projetos, comunidades e empresas dependendo do Git, é crucial que as mudanças não prejudiquem seus milhões de usuários e os bilhões de linhas de código hospedadas em repositórios em todo o mundo. Nem todo mundo precisa das ferramentas Scalar e GVFS, mas a Microsoft certamente precisa, e outros projetos podem precisar de recursos semelhantes no futuro.
Grandes projetos de padrões abertos, como JavaScript e HTML, funcionam demonstrando que as principais plataformas downstream suportam os novos recursos planejados do projeto antes de serem comprometidos com as especificações, escondendo-os atrás de sinalizadores de recursos para teste. A abordagem da Microsoft para o Git é semelhante.
Ele permite que a Microsoft colha os benefícios desses novos recursos em seu próprio fork, enquanto o resto de nós continua usando nossas próprias instalações Git ou serviços Git baseados em nuvem, sem ter que se preocupar com o Scalar e como ele funciona até que faça parte do plataforma. Então a transição é tão fácil quanto executar uma atualização em um servidor.
