Como o Microsoft Office migrou do Source Depot para o Git

• O Microsoft Office usou por muito tempo o seu sistema interno de controle de código-fonte, o Source Depot, e depois realizou uma migração em grande escala para o Git para melhorar a experiência dos desenvolvedores e impulsionar a inovação tecnológica
• O Source Depot tinha limitações de produtividade por ser centralizado, ter branching lento e um fluxo de trabalho pouco prático, e a migração para o Git exigiu vários anos de trabalho e centenas de engenheiros
• Durante a migração, a equipe superou grandes desafios técnicos e organizacionais, como o desenvolvimento de novas tecnologias, como o VFS for Git, a adaptação da infraestrutura existente de build/testes e a operação paralela dos dois sistemas
• Para que a transição fosse bem-sucedida, destacou-se uma abordagem colaborativa e centrada nas pessoas, com um sistema de comunicação baseado em "champions", transparência ousada, treinamento prático e estratégia de rollback imediato
• Após a migração, houve resultados positivos como redução no tempo de onboarding, aumento da preferência pelo Git (89%), ganhos de produtividade e importantes lições sobre mudanças tecnológicas em grande escala

---

Do Source Depot para o Git: a experiência de migração em grande escala do Microsoft Office

Um novo desafio: maximizar a produtividade dos desenvolvedores

• Melhorar a produtividade dos desenvolvedores é um tipo de 'Multiplier work', cujo valor cresce ainda mais em organizações grandes
• O projeto de migração do Microsoft Office do Source Depot para o Git foi um exemplo representativo disso
• Esse trabalho não foi apenas uma troca de ferramenta, mas um grande projeto de longa duração, envolvendo centenas de engenheiros e sistemas complexos

Source Depot: como era o controle de código-fonte naquela época

• No início dos anos 2000, a Microsoft operava o Source Depot, seu sistema próprio de controle de versão baseado na tecnologia Perforce
• O Source Depot tinha limitações de eficiência por conta de branching lento, arquitetura centralizada, longos tempos de checkout de código e um modelo incômodo de merge (Reverse/Forward Integrate)
• Como ele era fortemente acoplado a toda a infraestrutura de desenvolvimento (build, release e workflow), não era possível simplesmente substituí-lo
• A migração do Office para o Git exigiu anos de trabalho e o esforço de centenas de engenheiros

Começando pelo OneNote: o início da migração

• Na organização de engenharia do Office, decidiu-se por uma grande migração para o Git devido ao custo de manutenção e patching do Source Depot e à necessidade de “tecnologia competitiva”
• Como a suíte Office tinha cronogramas de desenvolvimento diferentes conforme o ciclo de lançamento (alguns meses, semestral, mensal e Insider), foi necessário manter por muito tempo uma operação paralela entre Source Depot e Git
• Também surgiram como tarefas essenciais a consistência do controle de versão do Office, a validação dos builds e a adaptação da infraestrutura legada de testes

A escala do Office e a estratégia de comunicação

• Na época, o Office era uma organização gigantesca, com 4.000 engenheiros colaborando
• Cada equipe designou um 'Developer Satisfaction Champion', e foi criado um modelo hub-and-spoke para conectar os times e garantir uma estrutura eficiente de feedback e comunicação
• O autor atuou como champion do OneNote e teve um papel central no campo dessa grande migração

VFS for Git: superando os limites de um codebase gigantesco

• O codebase era tão grande que um único git clone exigiria mais de 200 GB, então o problema foi resolvido com o Virtual File System for Git (VFS for Git), desenvolvido em conjunto com o GitHub
• O VFS for Git superou as limitações do Git tradicional ao baixar apenas os arquivos realmente usados
• Em colaboração com o Microsoft Windows, foi uma experiência de romper os limites de um dos maiores sistemas de controle de versão da indústria

Abordagem da migração por etapas

Etapa 1: universo paralelo (Parallel Universe)

• Foi criado um serviço de ponte que sincronizava Source Depot e Git em tempo real, e os problemas de inconsistência entre os dois sistemas e de diferenças de modelo (estrutura de branches, changelist etc.) foram sendo melhorados repetidamente
• O processo de sincronização e build dos branches principal/privado do Office foi operado por um sistema automatizado 24/7
• Depois de três tentativas, conseguiu-se implementar um sistema paralelo estável

Etapa 2: validação de equivalência

• Todos os test suites foram executados repetidamente nos dois sistemas para provar que os resultados dos builds eram exatamente iguais
• Diferenças sutis, como estilo de quebra de linha, maiúsculas/minúsculas e formato dos resultados de teste, foram depuradas e resolvidas ao longo de vários meses
• Com o resultado 'Green across the board' (testes aprovados em ambos os sistemas), a equipe ficou pronta para entrar na fase de transição real

Uma abordagem centrada nas pessoas

Comunicação multicanal e repetida

• Para alinhar os cronogramas de mais de 4.000 engenheiros e dezenas de equipes, foi montado um sistema intenso de comunicação com champions em cada time
• Avisos importantes eram repetidos pelo menos 3 vezes (e-mail, Teams, wiki, reuniões etc.) para minimizar confusões
• Quando surgiam problemas, a confiança era mantida por meio de divulgação imediata e transparente das informações

Treinamento e adaptação ao Git

• Para engenheiros acostumados há 10 anos com o Source Depot, foi preparada uma estrutura gradual de aprendizado com ambiente de treinamento prático e guia de comandos para a transição
• Também foi oferecido aprendizado baseado em cenários reais por meio de recursos como uma biblioteca de vídeos voltada à prática
• A iniciativa foi além de reduzir a ansiedade e fortalecer capacidades, apoiando também a adaptação ao workflow existente

Estratégia de rollback e mecanismos de segurança

• Na transição real, foi dado ao Diretor um 'botão vermelho', permitindo rollback imediato a qualquer momento em caso de problema grave
• Parte do histórico antigo do Source Depot foi preservada por muito tempo, mantendo com segurança o histórico de desenvolvimento anterior

Resultados e principais conquistas

• Após a migração, apareceram ganhos de produtividade como redução de 50% no tempo de onboarding, confirmação de 89% de preferência pelo Git, melhora no desempenho de build, maior eficiência em code review e aumento da colaboração
• Os engenheiros avaliaram positivamente o fato de terem adquirido habilidades transferíveis para o restante da indústria
• Também aumentou a capacidade de colocar novos profissionais em atividade mais rapidamente

Lições centrais de uma migração em grande escala

• Para ter sucesso, é preciso investir mais do que o esperado não só nos aspectos técnicos, mas também em comunicação centrada nas pessoas
• Construção de sistema paralelo, prova de equivalência perfeita, desenho claro de rollback desde o início e valorização de pessoas-chave (champions) foram pontos essenciais
• Também é indispensável medir em paralelo indicadores qualitativos, como satisfação, e o senso de estabilidade organizacional e segurança psicológica é importante durante o processo de mudança
• A essência de uma grande transformação é a gestão de mudanças flexível e sistemática em toda a organização

Conclusão e aplicações futuras

• A migração do Office para o Git foi um projeto histórico, realizado com anos de preparação e meses de execução
• No fim, ficou como um caso de mudança organizacional bem-sucedida, garantindo a continuidade do trabalho de milhares de pessoas
• Em outras grandes transformações, como migração para a nuvem, decomposição de arquitetura monolítica e upgrade de frameworks, os mesmos princípios de validação paralela, comunicação repetitiva e rollback rápido também podem ser aplicados
• Embora detalhes técnicos (infraestrutura de build, questões offline/contratuais etc.) não tenham sido abordados adicionalmente, a lição mais importante é a abordagem estratégica e organizacional para mudanças tecnológicas em larga escala

[ndrgrd]

Se você lida muito com arquivos binários, talvez o Git não seja a melhor opção, mas para repositórios centrados em código parece que o Git é suficiente.

[rtyu1120]

Deve ter sido uma grande mudança também internamente na MS, mas acho positivo que, graças a isso, recursos como partial clone e sparse checkout, além de ferramentas como o Scalar, também tenham sido disponibilizados publicamente para uso rs

[GN⁺]

Comentários do Hacker News

• É sempre um prazer ler um texto que reconta bem essa velha história. Apontam que o artigo original menciona que “levou algumas horas para trazer todo o repositório do Office”, mas praticamente omite o fato de que, no Git, isso era quase impossível sem um novo sistema de arquivos como o VFS. No Perforce, os usuários podiam fazer checkout apenas das partes necessárias, então é de se supor que a maioria dos usuários do Source Depot também não baixava o aplicativo inteiro do Office toda vez, mas só o que precisava. O VFS reduz essa diferença ao permitir que o Git baixe apenas os objetos necessários. Perforce/Source Depot eram VCS centralizados e excelentes escolhas na época, mas a sensação é de que os tempos mudaram.
  • Explicam que, no Perforce, também houve empresa que criou uma tecnologia própria para buscar arquivos só no momento em que fossem necessários, como no VFS. Isso é especialmente importante no desenvolvimento de jogos, quando se armazenam grandes ativos binários de origem junto com arquivos de texto. Acho que isso tem a mesma raiz tecnológica dos programas de unidade remota embutidos no Windows. Pessoalmente, ainda quero um VCS baseado em servidor que armazene todo o código da empresa sem exigir que eu replique todo o histórico localmente. Mas o Git é bom o bastante para colaboração pontual entre vários dispositivos, então ainda não senti necessidade de montar um servidor central e até um pipeline de CI/CD. Gosto muito dos vários fluxos de trabalho do Git, como stash, stage por hunk e rebase interativo.
  • Minha empresa ainda usa Perforce, e é triste que hoje ninguém mais goste de Perforce. Já vi com meus próprios olhos o brilho sumir do olhar dos novatos no instante em que dizemos: “aqui a gente não usa Git”.
  • O VFS não substitui totalmente o Perforce. Na prática, a maioria das empresas de jogos AAA ainda usa Perforce. Enfatizam que é essencial poder colocar lock em arquivos de ativos para impedir que duas pessoas editem ao mesmo tempo e acabem numa situação impossível de mesclar, além de evitar o desperdício de ter que descartar o trabalho de um artista.
  • Sinceramente, acho estranho que o Git até hoje não ofereça uma forma de fazer checkout seletivo apenas de partes específicas da árvore do repositório. Parece algo que poderia ser expandido facilmente ao encaixar um serviço intermediário que entenda arquivos de objeto e afins.
• Durante um estágio na Microsoft em 2016, fiz um revisor automático de código que dava suporte ao Source Depot. Eu nem sabia o que era Source Depot e gastei quase uma semana inteira nessa funcionalidade (https://austinhenley.com/blog/featurestheywanted.html). Naquela época, muitos desenvolvedores ainda usavam Source Depot. Fico curioso se agora já migraram todos para Git.
  • Sinto falta do CodeFlow todos os dias. Era uma ferramenta realmente incrível.
  • Dizem que ainda há muitas áreas onde o Source Depot é usado ativamente. Os comandos e as configurações de ambiente do Source Depot sempre me deixam tenso.
  • Hoje em dia, a maior parte do meu trabalho cotidiano já é feita no Git.
• Como alguém que usou vss (Visual SourceSafe) nos anos 90, fiquei surpreso que essa história nem tenha sido mencionada no artigo. O Visual SourceSafe era um protocolo de controle de versão criado pela própria Microsoft, enquanto o Source Depot era diferente por ser licenciado a partir do Perforce.
  • O VSS (Visual SourceSafe) veio com a aquisição da One Tree Software, de Raleigh, e o nome do produto foi mudado de “SourceSafe” para “Visual SourceSafe”, passando a ser distribuído em pacote com Visual C, Visual Basic e outros. Antes disso, a Microsoft vendia um produto de controle de versão chamado “Microsoft Delta”, que era caro, ruim e nem tinha suporte no NT. Entre as pessoas que vieram com a aquisição da One Tree estava Brian Harry, que liderou o Team Foundation Version Control (TFS). Usando o SQL Server como repositório, ele melhorou bastante a administrabilidade e a confiabilidade em relação ao VSS. Ao que parece, Brian Harry já se aposentou e seu blog não é mais atualizado. Uma das coisas de que me lembro ao usar VSS naquela época é que o lock de arquivos na rede era tratado por SMB, então ele era vulnerável a erros frequentes de rede e o repositório se corrompia com frequência. Por isso, era preciso agendar um job em lote para recuperação toda madrugada, restaurando tudo automaticamente durante a noite, porque tinha que estar utilizável pela manhã.
  • Pela minha experiência usando VSS nos anos 90, trabalhar em equipe com aquilo era quase um pesadelo e, pelo que sei, a própria Microsoft mal o usava internamente.
  • Eu usava VSS quando desenvolvia sozinho nos anos 90, e aquilo parecia um novo mundo na época. Na pós-graduação conheci outros VCS (RCS, CVS etc.). Quando entrei na Microsoft em 2004, lembro de alguém me explicar que o VSS era inseguro e se corrompia facilmente. Não sei se isso era verdade, mas, de todo modo, na empresa o VSS nem era uma opção.
• Fui membro da equipe quando a Microsoft migrou de XNS para TCP/IP. Esse trabalho foi menos complicado do que parece, mas trouxe lições semelhantes. Migrar de MSMAIL para Exchange, isso sim, foi realmente difícil.
  • Uma vez vi uma moldura de placa com a frase “Exchange: The Most Feared and Loathed Team in Microsoft”, e fiquei pensando se isso vinha dessa experiência da época. Faz 20 anos, então não lembro a formulação exata.
• “Authenticity mattered more than production value” realmente bateu forte. Como ex-funcionário da Microsoft que trabalhava em uma pequena linha de produto que só começou a migrar de Source Depot para Git quase no fim da minha passagem por lá (2015), eu entendo perfeitamente quanto esforço esse tipo de trabalho exigiu. Foi uma conquista realmente incrível.
  • Eu também não consigo acreditar que passei por tudo isso. Minha gratidão.
• Olhando para a situação que a Microsoft enfrentava no começo dos anos 2000, o Windows estava ficando extremamente complexo e milhões de linhas de código precisavam de controle de versão, mas o Git nem existia e o SVN ainda estava começando a crescer. Fico curioso se a Microsoft considerou seriamente produtos comerciais como o BitKeeper, desenvolvido em 1998 e lançado em 2000. Talvez, naquela época, sistemas centralizados como Perforce fossem o padrão, e soluções distribuídas como o BitKeeper parecessem estranhas ou pouco comprovadas.
  • Naquela época havia o VSS (Visual SourceSafe) e depois veio o TFVC.
• Agradeço aos tech leads que me revelaram os mistérios do Source Depot para alguém iniciante como eu. Quando finalmente entendi a estrutura do Source Depot, foi uma experiência realmente reveladora. Eu só dependia de WinCE e IE, então meu clone levava apenas 20 minutos, não vários dias, e por isso me sinto com sorte. Esqueci os nomes das pessoas que me ajudaram, mas continuo praticando no meu time essa mesma atitude de ajudar quem está chegando para que possa começar a trabalhar com facilidade.
• A maioria das pessoas lembra da adoção do Git como uma vitória técnica, mas a verdadeira inovação foi permitir que cada desenvolvedor controlasse seu próprio fluxo de trabalho. Não era mais preciso esperar pela janela de sincronização nem pedir ao líder acesso a branches. Agora todos podem trabalhar com liberdade e velocidade sem entrar em conflito uns com os outros. Tenho a forte impressão de que essa mudança teve muito mais impacto no clima da equipe do que em qualquer dashboard de produtividade. O Git não foi apenas uma ferramenta: ele mudou até a confiança que tínhamos no ciclo de desenvolvimento.
• Fico curioso sobre quando a Microsoft abandonou internamente o Visual SourceSafe. Acho que deveriam tê-lo descontinuado mais cedo, nem que fosse só para evitar que ele continuasse sendo usado externamente.
  • Acho que a maioria das equipes não usava VSS de fato. Quando trabalhei na Microsoft, nosso time usava Source Depot. Também experimentei o TFS na época e não gostei muito; ainda assim, depois de usar Source Depot, até passei a sentir falta do TFS.
  • Tenho dúvidas se o VSS era usado para fins principais dentro da Microsoft. Se realmente fosse usado internamente, não imagino que o lançariam num estado tão mal-acabado. O TFS foi uma experiência difícil de entender e não era grande coisa, nem interna nem externamente.
  • Deve ter sido por volta de 2000. Até onde eu sei, o único projeto que o usou foi o .NET, e mesmo ele já tinha migrado para Source Depot.
  • Reação de quem nem sabia que existia um Microsoft SourceSafe.
• Não estou entendendo bem essa história de que o shallow clone do OneNote tinha 200 GB.
  • Na verdade, explicam que não era do OneNote, mas sim um shallow clone do Office inteiro.
  • Presumem que havia vídeos ou binários grandes incluídos.