Crear aplicaciones a escala no es nada comparado con crear un sistema operativo como Windows, especialmente cuando se trata de control de código fuente. ¿Cómo se gestiona el repositorio (o repositorios) de un gigante de software de este tipo, con miles de desarrolladores y evaluadores, y con un proceso de compilación complejo que entrega continuamente código nuevo?
Microsoft historial con sistemas internos de control de fuentes es complicado. Se podría pensar que utilizaba Visual SourceSafe, ahora descontinuado, pero era más apropiado para sistemas de archivos locales y proyectos más pequeños. En cambio, Microsoft utilizó muchas herramientas diferentes a lo largo de los años, inicialmente una bifurcación interna del conocido Sistema de control de revisiones Unix, antes de estandarizarlo. Depósito de origen de Perforce.
Git choca contra una pared en Redmond
Mientras tanto, algunas partes de la empresa utilizaban Team Foundation Server de Visual Studio, antes de pasar a utilizar git como base de una plataforma de ingeniería común para toda la empresa. Team Foundation Server admitía Git, y la combinación de una herramienta visual y la línea de comandos admitía muchos casos de uso diferentes en Microsoft.
Ese cambio tenía mucho sentido, ya que Git fue diseñado para lidiar con las complejidades de administrar una enorme base de código con una gran cantidad de desarrolladores distribuidos globalmente. No es sorprendente que existan muchas similitudes entre cómo se construyen Windows y Linux, y Git tiene características que funcionan bien para ambos.
Sin embargo, existe un gran problema para un repositorio masivo como Windows. A pesar de toda su complejidad y sus muchas partes móviles, herramientas como Windows y Office se desarrollan en repositorios únicos, monorrepos masivos que ocupan grandes cantidades de espacio de almacenamiento.unos 300 GB y 3,5 millones de archivos sólo para Windows. El problema surge de cómo Git trata los repositorios: replicarlos, y cada cambio, en cada copia. Para Windows, el tamaño del repositorio abrumaría rápidamente las PC de los desarrolladores y obstruiría rápidamente la red de desarrolladores.
Ingrese a GVFS: el sistema de archivos virtual de Git
Un repositorio masivo podría ser viable si todos los desarrolladores trabajaran en una única red de comunicaciones ultrarrápida y una red de almacenamiento de alta velocidad, pero ciertamente no lo es cuando eres un equipo distribuido globalmente que combina oficinas y trabajadores desde casa. Microsoft necesitaba desarrollar una forma de tratar un repositorio Git como un sistema de archivos virtual, creando archivos locales sólo cuando sean necesarios, en lugar de copiar todo el repositorio a través de una red desconocida.
La herramienta resultante equilibra las capacidades de Git con las necesidades de desarrollo de Microsoft. No cambia Git en absoluto, aunque sacrifica las capacidades fuera de línea de Git. Fue una buena decisión, cuando la gran mayoría de los desarrolladores de Microsoft trabajaban en Redmond.
Sistema de archivos virtuales Git, GVFS, que se envía como un controlador del sistema de archivos de Windows, está diseñado para monitorear su directorio de trabajo y su carpeta .git, desplegando solo lo que se necesita para el trabajo que está realizando y verificando solo los archivos que necesita. Aún puedes ver el contenido del repositorio, como si fuera una extensión del sistema de archivos de tu PC, muy parecido a la forma en que se descargan los archivos de OneDrive solo cuando los seleccionas explícitamente.
Cuando Microsoft comenzó a usar GVFS, notó varios casos extremos que mostraban que Git estaba haciendo trabajo innecesario en archivos, por lo que sus ingenieros pasaron a proporcionar soluciones para estos problemas en el proyecto Git. Estas correcciones fueron diseñadas para mejorar el rendimiento de Git para repositorios grandes, permitiendo a Microsoft cambiar a un enorme monorepo interno para el control de código fuente.
Ampliando Git con Scalar
Las cosas no pararon ahí. Ahora estamos en la tercera versión pública del trabajo de Microsoft para escalar Git, esta vez como parte de la propia bifurcación de Git de la compañía.una distribución Git de propósito especial diseñada para soportar monorepos.
La versión actual se basa en el trabajo publicado en 2020 como Scalar. Scalar es una aplicación que acelera cualquier repositorio Git, sin importar dónde esté alojado. Requiere la implementación personalizada de Git de Microsoft, aunque el objetivo a largo plazo es que gran parte del código del lado del servidor necesario forme parte de la versión oficial de Git. escalar es una herramienta obstinadacon un enfoque en mejorar el rendimiento de Git.
Scalar es una aplicación de línea de comandos .NET que se ejecuta en segundo plano, gestionando los repositorios registrados. Puede usarlo junto con GVFS o como un acelerador independiente. aprovechando las características recientes de Git. Microsoft usa Scalar con GVFS internamente, colocando servidores de caché entre sus repositorios y las PC de los desarrolladores. GVFS no es esencial para Scalar, pero ciertamente ayuda.
Una vez instalado y en ejecución, Scalar se puede utilizar junto con un cliente Git tradicional, clonar repositorios usando un caché local o un servidor de caché remoto y administrar su repositorio local. El valor predeterminado es realizar un pago escaso, lo que permite a Scalar, como lo expresó Microsoft en el publicación de blog de anuncio«centrarse en los archivos que importan».
Scalar configura los clones locales y luego los desarrolladores pueden usar Git normalmente. Esto se maneja ofreciendo un enfoque escalonado para la administración de archivos: un índice de alto nivel de todos los archivos en un repositorio (que puede ser muchos millones), un directorio de trabajo disperso de los archivos que podría necesitar para la tarea en la que está trabajando, y finalmente un conjunto de los archivos que has modificado.
Administrar Git en segundo plano
Gran parte del trabajo de Scalar sucede en el fondo, para que funciones como la recolección de basura de Git no bloqueen las confirmaciones al reescribir y actualizar archivos. Scalar hace esto estableciendo configuraciones clave de Git para evitar operaciones en primer plano. Todavía usas Git como lo haces normalmente, pero lo que podrían ser operaciones de mantenimiento de repositorios que requieren un uso intensivo del procesador y de la red se transfieren al proceso Scalar en segundo plano, donde pueden operar con una prioridad más baja sin afectar el trabajo que estás haciendo.
Con un conjunto de índices que administran su directorio de trabajo, Scalar usa GVFS para clonar repositorios usando solo los archivos raíz y descargando archivos adicionales según sea necesario. Los archivos se almacenan dentro de un directorio escalar, con el directorio de trabajo en un subdirectorio src. Esta estructura de archivos le permite administrar compilaciones y sucursales localmente.
El trabajo de Microsoft en Scalar le ha llevado a lanzar su propia distribución Git con Scalar CLI. Puede encontrar versiones de Git de Microsoft para Windows, macOS y Linux (como un paquete Debian, y otras distribuciones deben compilarse desde el código fuente). También hay una versión portátil para Windows. Microsoft ahora llama a sus funciones “funciones avanzadas de Git”, un enfoque que da sentido al trabajo que está haciendo para demostrar cómo Git puede funcionar a escala masiva.
Si desea probarlo, primero debe configurar su propio servidor Git, listo para alojar sus propios repositorios. Puede utilizar herramientas familiares de Git para comenzar a ejecutar, almacenar código y artefactos, antes de cambiar a Scalar y GVFS. Aunque Scalar funcionará con otras implementaciones de Git, debes buscar una que admita la opción de clonación parcial, que es la alternativa oficial a GVFS.
La versión actual de Microsoft Git incluye mejoras en el lado del servidor para garantizar que los monorepos masivos se comporten de manera muy similar a repositorios más pequeños, sin requerir herramientas adicionales para construir compilaciones a partir de múltiples fuentes.
¿Por qué escalar?
Puede pensar en Scalar como un campo de pruebas para la dirección en la que Microsoft le gustaría que tomara Git. Bifurcar Git permite a la empresa probar estas funciones antes de ofrecerlas nuevamente a la comunidad Git en general. Es un enfoque razonable que hace que el código esté disponible para que la comunidad lo evalúe antes de que alguien realice una solicitud de extracción.
Con tantos proyectos, comunidades y empresas que dependen de Git, es crucial que los cambios no rompan las cosas para sus millones de usuarios y los miles de millones de líneas de código alojadas en repositorios en todo el mundo. No todo el mundo necesita las herramientas de Scalar y GVFS, pero Microsoft ciertamente las necesita, y es posible que otros proyectos necesiten características similares en el futuro.
Los grandes proyectos de estándares abiertos como JavaScript y HTML funcionan demostrando que las principales plataformas posteriores admiten las nuevas características planificadas del proyecto antes de comprometerse con las especificaciones, ocultándolas detrás de indicadores de características para realizar pruebas. El enfoque de Microsoft hacia Git es similar.
Permite a Microsoft aprovechar los beneficios de estas nuevas características en su propia bifurcación, mientras que el resto de nosotros continuamos usando nuestras propias instalaciones de Git o servicios de Git basados en la nube, sin tener que preocuparnos por Scalar y cómo funciona hasta que sea parte del plataforma. Entonces la transición es tan fácil como ejecutar una actualización en un servidor.
Copyright © 2024 IDG Communications, Inc.