Cómo Microsoft Office migró de Source Depot a Git

• Microsoft Office usó durante mucho tiempo Source Depot, su sistema interno de control de código fuente, pero luego llevó a cabo una migración masiva a Git para mejorar la experiencia de los desarrolladores e impulsar la innovación tecnológica
• Source Depot tenía límites de productividad por ser centralizado, tener branching lento y flujos de trabajo incómodos, y la migración a Git requirió varios años de trabajo y a cientos de ingenieros
• Durante la migración se superaron grandes retos técnicos y organizacionales, como el desarrollo de nuevas tecnologías como VFS for Git, la migración de la infraestructura existente de build y pruebas, y la operación paralela de ambos sistemas
• Para lograr una transición exitosa, se puso énfasis en un enfoque colaborativo y centrado en las personas, con un sistema de comunicación basado en "champions", transparencia decidida, capacitación práctica y una estrategia de rollback inmediato
• Después de la migración hubo resultados positivos como menor tiempo de onboarding, mayor preferencia por Git (89%), mejor productividad y aprendizajes clave sobre cambios tecnológicos a gran escala

---

De Source Depot a Git: la experiencia de la migración a gran escala de Microsoft Office

Un nuevo reto: maximizar la productividad de los desarrolladores

• Mejorar la productividad de los desarrolladores es un "Multiplier work", y su valor crece cuanto más grande es la organización
• El proyecto de migración de Microsoft Office de Source Depot a Git fue un caso representativo de esa clase de experiencia
• Este trabajo no fue solo un cambio de herramienta, sino un proyecto enorme que involucró a cientos de ingenieros, sistemas complejos y un largo periodo de tiempo

Source Depot: cómo era la gestión de código en esa época

• A inicios de los 2000, Microsoft operaba Source Depot, su propio sistema de control de versiones basado en tecnología de Perforce
• Source Depot tenía límites de eficiencia por su branching lento, centralización, largos tiempos de checkout de código y una forma incómoda de hacer merges (Reverse/Forward Integrate)
• Estaba fuertemente acoplado a toda la infraestructura de desarrollo (build, release, workflow), por lo que no podía sustituirse de manera simple
• La migración de Office a Git requirió años de trabajo y el esfuerzo de cientos de ingenieros

Empezando con OneNote: el inicio de la migración

• Dentro de la organización de ingeniería de Office, se decidió una migración grande a Git por el costo de mantener y aplicar parches a Source Depot y por la necesidad de una “tecnología competitiva”
• La suite de Office tenía calendarios de desarrollo distintos según sus ciclos de lanzamiento (cada pocos meses, semestral, mensual, Insider), así que fue necesario operar Source Depot y Git en paralelo durante un largo tiempo
• Surgieron como tareas esenciales la consistencia del control de versiones en Office, la validación de builds y la migración de la infraestructura legacy de pruebas

La escala de Office y la estrategia de comunicación

• En ese momento, Office era una organización gigantesca en la que colaboraban 4,000 ingenieros
• Se designó un 'Developer Satisfaction Champion' por equipo, y mediante un modelo hub-and-spoke se estableció una estructura de comunicación y retroalimentación fluida entre los equipos
• El autor fue el champion de OneNote y desempeñó un papel clave en el terreno durante la migración a gran escala

VFS for Git: rompiendo los límites de una base de código gigantesca

• Como un solo git clone requería más de 200 GB por el tamaño del código, el problema se resolvió con Virtual File System for Git (VFS for Git), desarrollado junto con GitHub
• VFS for Git superó las limitaciones de Git tradicional al descargar solo los archivos que realmente se usaban
• En colaboración con Microsoft Windows, fue una experiencia de superar los límites de uno de los sistemas de control de versiones más grandes de la industria

Enfoque por etapas de la migración

Etapa 1: universo paralelo (Parallel Universe)

• Se construyó un servicio puente para sincronizar Source Depot y Git en tiempo real, y se mejoraron de forma iterativa los problemas de inconsistencias y diferencias de modelo entre ambos sistemas (estructura de ramas, changelist, etc.)
• El proceso de sincronización y build entre la rama principal/privada de Office se operó con un sistema automatizado 24/7
• Tras tres reintentos, se logró implementar un sistema paralelo que funcionaba de forma estable

Etapa 2: verificación de equivalencia

• Se ejecutaron repetidamente todos los test suites en ambos sistemas para demostrar que los resultados de build eran exactamente iguales
• Durante meses se depuraron y resolvieron diferencias sutiles, como el formato de saltos de línea, mayúsculas/minúsculas y el formato de los resultados de pruebas
• Con el logro de "Green across the board" (pruebas aprobadas en ambos sistemas), todo quedó listo para pasar a la etapa de cambio real

Un enfoque centrado en las personas

Comunicación repetida y por múltiples canales

• Para coordinar los calendarios de más de 4,000 ingenieros y decenas de equipos, se construyó un sistema intensivo de comunicación con champions por equipo
• Los avisos importantes se comunicaban al menos 3 veces (correo, Teams, wiki, reuniones, etc.) para reducir al mínimo la confusión
• Cuando surgían problemas, se ganaba confianza con una divulgación inmediata y transparente de la información

Capacitación y adaptación a Git

• Para los ingenieros acostumbrados durante 10 años a Source Depot, se preparó un sistema de aprendizaje gradual con entornos de capacitación prácticos y guías de comandos de transición
• A través de bibliotecas de video centradas en la práctica, se ofreció aprendizaje basado en escenarios reales
• Más allá de reducir la ansiedad y fortalecer capacidades, también se apoyó la adaptación al workflow existente

Estrategia de rollback y mecanismos de seguridad

• Durante el cambio real, se le dio al Director un "botón rojo", de modo que pudiera hacer rollback inmediato en cualquier momento si surgía un problema grave
• Parte del historial anterior de Source Depot se conservó durante mucho tiempo, manteniendo segura la historia de desarrollo existente

Resultados y principales logros

• Después de la migración se observó un recorte del 50% en el tiempo de onboarding, una preferencia por Git del 89%, mejoras en el rendimiento de build y ganancias de productividad como mayor eficiencia en code review y colaboración
• Los ingenieros valoraron positivamente la adquisición de habilidades transferibles dentro de la industria
• También aumentó la posibilidad de que el personal nuevo pudiera integrarse y aportar de inmediato

Lecciones clave de una migración a gran escala

• Para tener éxito, hay que invertir más de lo esperado no solo en los aspectos técnicos, sino también en una comunicación centrada en las personas
• Son fundamentales la construcción de sistemas paralelos, la demostración de equivalencia perfecta, el diseño sólido de rollback desde el inicio y el papel del personal clave (champions)
• También es indispensable medir indicadores cualitativos como la satisfacción, y en procesos de cambio importan mucho la estabilidad organizacional y la sensación de seguridad psicológica
• La esencia de los cambios a gran escala es una gestión del cambio flexible y sistemática en toda la organización

Conclusión y aplicación futura

• La migración de Office a Git fue un proyecto histórico realizado tras años de preparación y varios meses de ejecución
• En última instancia, quedó como un caso exitoso de impulsar un cambio organizacional garantizando la continuidad del trabajo de miles de personas
• En otros cambios a gran escala, como migraciones a la nube, descomposición de arquitecturas monolíticas o upgrades de frameworks, también pueden aplicarse del mismo modo la validación en paralelo, la comunicación repetitiva y el diseño de rollback rápido
• No se abordaron en detalle los aspectos técnicos específicos (infraestructura de build, temas offline/contractuales, etc.), pero la lección más importante es el enfoque estratégico y organizacional ante cambios tecnológicos a gran escala

[ndrgrd]

Si manejas muchos archivos binarios, quizá git no sea lo más adecuado, pero si es un repositorio centrado en código, parece que git es más que suficiente.

[rtyu1120]

Seguramente fue un cambio grande incluso dentro de MS, pero también parece positivo que gracias a eso funciones como partial clone y sparse checkout, así como herramientas como Scalar, se hayan hecho públicas y ahora puedan usarse afuera también jaja

[GN⁺]

Comentarios en Hacker News

• Siempre es un gusto leer una historia vieja bien contada de una manera nueva. Señalan que el artículo original menciona que “tomó varias horas traer todo el repositorio de Office”, pero en la práctica omite que en git eso era casi imposible sin un sistema de archivos nuevo como VFS. En Perforce, los usuarios podían hacer checkout solo de las partes que necesitaban, así que es probable que la mayoría de los usuarios de Source Depot tampoco bajaran toda la app de Office cada vez, sino solo lo necesario. VFS cerró esa brecha al permitir descargar únicamente los objetos necesarios en git. Perforce/Source Depot era un VCS centralizado excelente para su época, pero da la impresión de que los tiempos ya cambiaron.
  • Explican que incluso en Perforce hubo empresas que desarrollaron tecnología propia, similar a VFS, para traer archivos solo en el momento en que se necesitan. Esto es especialmente importante en desarrollo de videojuegos, donde se guardan grandes recursos binarios junto con archivos de texto. Creo que tiene la misma raíz tecnológica que usan los programas de unidades remotas integrados en Windows. En lo personal, todavía quiero un VCS basado en servidor que almacene todo el código de la empresa sin necesidad de clonar todo el historial localmente. Pero git sigue siendo bastante útil para colaboración puntual entre varios dispositivos, así que todavía no siento la necesidad de montar un servidor central y un pipeline completo de CI/CD. Me encantan muchos flujos de trabajo de git, como stash, hacer stage por hunks e interactive rebase.
  • En mi empresa todavía usamos perforce, y es una lástima que ya a nadie le guste. He visto con mis propios ojos cómo se les apaga la mirada a los nuevos cuando les dices: “No usamos git”.
  • VFS no reemplaza por completo a Perforce. De hecho, recalcan que la mayoría de los estudios AAA siguen usando Perforce. Es indispensable poder poner locks a los archivos de assets para evitar que dos personas los modifiquen al mismo tiempo y terminen en una situación imposible de mergear, además de reducir el desperdicio de tiempo de tener que descartar el trabajo de un artista.
  • Sinceramente me desconcierta por qué git todavía no ofrece una forma de hacer checkout selectivo solo de ciertas partes del árbol del repositorio. Me parece que sería fácil extenderlo si se le agrega un servicio intermedio que entienda archivos objeto y similares.
• En unas prácticas en Microsoft en 2016 hice un revisor automático de código que soportaba Source Depot, y me pasé casi una semana metido en esa función sin siquiera saber qué era Source Depot (https://austinhenley.com/blog/featurestheywanted.html). En ese momento todavía muchos desarrolladores lo usaban. Me pregunto si ahora ya se habrán pasado todos a git.
  • Extraño CodeFlow todos los días. De verdad era una herramienta increíble.
  • Dicen que todavía hay muchas áreas donde Source Depot se usa activamente. Los comandos de Source Depot y su configuración de entorno siempre me ponen tenso.
  • Hoy en día, la mayor parte del trabajo cotidiano ya la hago en git.
• Como alguien que usó vss (Visual SourceSafe) directamente en los 90, me sorprende que en este artículo ni siquiera lo mencionen. Visual SourceSafe era un protocolo de control de versiones de código hecho por Microsoft, mientras que Source Depot era distinto porque estaba licenciado de Perforce.
  • VSS (Visual SourceSafe) vino de la adquisición de One Tree Software en Raleigh, y renombraron el producto de “SourceSafe” a “Visual SourceSafe” para incluirlo en paquetes junto con Visual C, Visual Basic y otros. Antes de eso, vendían un producto de control de versiones llamado “Microsoft Delta”, que era caro, de mala calidad y ni siquiera tenía soporte en NT. Entre las personas que llegaron con la compra de One Tree estaba Brian Harry, quien luego lideró Team Foundation Version Control (TFS). Al usar SQL Server como repositorio, mejoró mucho la administración y la confiabilidad frente a VSS. Parece que Brian Harry ya se retiró y su blog ya no se actualiza. Una de las cosas que recuerdo de usar VSS en esa época es que manejaba el file locking de red mediante SMB, así que era muy vulnerable a errores frecuentes de red, y el repositorio se corrompía seguido. Por eso teníamos una tarea por lotes todas las madrugadas para repararlo automáticamente durante la noche, porque tenía que estar utilizable por la mañana.
  • Por mi experiencia usando VSS en los 90, era casi una pesadilla para trabajo en equipo, y según recuerdo, Microsoft tampoco lo usaba mucho internamente.
  • Yo usé VSS cuando desarrollaba solo en los 90, y en ese momento me parecía algo revolucionario. En posgrado conocí otros VCS (RCS, CVS, etc.). Recuerdo que cuando entré a Microsoft en 2004, alguien me explicó que VSS era inseguro y propenso a corromperse. No sé si era totalmente cierto, pero de cualquier forma en la empresa VSS ni siquiera era una opción.
• Fui parte del equipo cuando Microsoft migró de XNS a TCP/IP. Ese trabajo no fue tan complicado como podría pensarse, pero dejó lecciones parecidas. Migrar de MSMAIL a Exchange sí fue realmente difícil.
  • Una vez vi un marco de placa que decía “Exchange: The Most Feared and Loathed Team in Microsoft”, y me pregunto si venía de esa experiencia. Fue hace 20 años, así que no recuerdo la frase exacta.
• “Authenticity mattered more than production value” realmente me llegó. Como ex empleado de Microsoft que trabajó en una línea de producto pequeña donde apenas estaban empezando a cambiar de Source Depot a Git justo antes de que yo me fuera (2015), conecto totalmente con la enorme cantidad de esfuerzo que debió requerir esto. Es un logro impresionante.
  • Yo también siento que no puedo creer que de verdad hayamos pasado por todo eso. Gracias.
• Si se mira el contexto que enfrentaba Microsoft a principios de los 2000, Windows se estaba volviendo extremadamente complejo y millones de líneas de código necesitaban control de versiones, pero git ni existía y SVN apenas iba despegando. Me pregunto si Microsoft consideró seriamente productos comerciales como BitKeeper, desarrollado en 1998 y lanzado públicamente en 2000. Supongo que en ese momento los sistemas centralizados como Perforce eran la norma, y que algo distribuido como BitKeeper quizá parecía extraño o todavía poco probado.
  • En ese entonces estaba VSS (Visual SourceSafe) y después llegó TFVC.
• Agradezco a los leads de desarrollo que me explicaron los misterios de Source Depot cuando yo era un ingeniero novato. Entender bien cómo estaba estructurado Source Depot fue una experiencia realmente reveladora. Yo solo dependía de WinCE e IE, así que mi clone tardaba apenas 20 minutos y no varios días, por suerte. Ya olvidé los nombres de las personas que me ayudaron, pero esa actitud de ayudar a los recién llegados para que puedan empezar a trabajar con facilidad es algo que sigo practicando hoy con mi propio equipo.
• La mayoría recuerda la adopción de git como una victoria técnica, pero en realidad la verdadera innovación fue que cada desarrollador pudo tomar control de su propio flujo de trabajo. Ya no había que esperar una ventana de sincronización ni pedirle al lead acceso a una rama. Ahora todos pueden avanzar con libertad y rapidez sin chocar entre sí. Me da la fuerte impresión de que este cambio mejoró mucho más el ambiente que cualquier dashboard de productividad. Git no solo cambió la herramienta, sino también la confianza en el loop de desarrollo.
• Me pregunto cuándo dejó Microsoft internamente Visual SourceSafe. Pienso que debieron descontinuarlo antes, aunque fuera solo para evitar que siguiera usándose afuera.
  • Dudo que la mayoría de los equipos realmente usaran VSS. Cuando trabajé en Microsoft, mi equipo usaba Source Depot. También probé TFS en esa época y no me gustó mucho; aun así, después de usar Source Depot, hasta terminé extrañando TFS.
  • Dudo que VSS se usara internamente para algo importante. Si de verdad lo hubieran usado adentro, no habrían sacado un producto en un estado tan descuidado. TFS fue una experiencia difícil de entender, tanto dentro como fuera.
  • Supongo que fue alrededor del año 2000. El único proyecto que conozco que lo usó fue .NET, y aun ese ya se había pasado a Source Depot.
  • Ni siquiera sabía que existía Microsoft SourceSafe.
• No termino de entender eso de que el shallow clone de OneNote fuera de 200GB.
  • En realidad no era OneNote, sino el shallow clone de todo Office.
  • Supongo que incluía videos o binarios muy grandes.