¿Por qué Google, Microsoft y Huawei ponen miles de millones de dólares en código fuente en un solo repositorio?
Autor | Yu Yan
Editor | Recién
Campamento base de tecnología de IA (ID: rgznai100)
Cómo gestionar grandes ¿Código de empresas? ¿Qué se puede aprender del desarrollo y la adopción de VFS para Git por parte de Microsoft, así como del propio sistema? Para obtener más información sobre VFS For Git y la gestión de código, AI Technology Basecamp (ID: rgznai100) entrevistó a Zou Xin, director jefe de I+D de Microsoft Research Asia, quien respondió estas preguntas.
¿Por qué elegir VFS para Git?
Zou Xin recordó que antes de migrar el código a GVFS, Microsoft utilizaba varias plataformas importantes de administración de código, incluidas SLM, Source Depot (iniciado en la década de 1990) y TFS, control de código fuente TFVC (iniciado en 2006). (Desde 2006). No fue hasta 2017 que Microsoft completó la migración del código a Git en tres meses y lanzó una variante de Git: GVFS para repositorios muy grandes, que todavía está en uso hoy.
GVFS es un sistema de archivos virtual de Git que le permite a Git manejar repositorios de tamaño terabyte, como el repositorio de Windows de 270 GB. La V en GVFS significa virtual y resuelve el defecto de diseño original de Git de tener todas las versiones de su código en cada cliente. La V en GVFS significa virtual, que resuelve el defecto de diseño original de Git (cada cliente tiene todas las versiones del código) y reemplaza los archivos locales innecesarios con archivos virtuales, aliviando así en gran medida la carga de la transferencia de archivos y la presión y el almacenamiento de la máquina local. permitir que el personal técnico interno de Microsoft colabore de manera eficiente.
Por cierto, GVFS ha sido controvertido desde el principio, porque el sistema de archivos virtual del proyecto GNOME también se llama GVfs, y GVfs de GNOME se lanzó por primera vez en 2006. Desde entonces, se han publicado tutoriales, documentación y foros. Siempre usé este nombre. Después del lanzamiento del proyecto GVfs de Microsoft, su clasificación de búsqueda superó rápidamente al proyecto GVfs de Gnome. Dado que ambos están relacionados con sistemas de archivos virtuales, los usuarios se confunden fácilmente al buscar información. Por lo tanto, muchos desarrolladores pidieron a Microsoft que cambiara el nombre. Después de muchos contratiempos, Microsoft finalmente cambió el nombre del proyecto "GVFS" a "VFS For Git" en 2018.
Zou Xin dijo que en ese momento, Microsoft migró el código a Git principalmente para unificar las herramientas que estaban floreciendo dentro de Microsoft. El equipo de liderazgo no tenía la mejor opción absoluta, pero a juzgar por los resultados actuales, esta es una mejor opción. Hoy, Microsoft continúa mejorando la serie de herramientas Git y retribuyendo a la comunidad Git.
VFS For Git ahora se ha convertido en una herramienta estandarizada dentro de Microsoft y ha sido adoptada por otras grandes organizaciones: /microsoft/VFSForGit
Además de Microsoft, también hemos visto muchas grandes empresas Migró el alojamiento de su código a un sistema de control de versiones desarrollado internamente como Google, que aloja más de mil millones de archivos, casi 100 terabytes de archivos, en varios idiomas.
Por ejemplo, Google almacena más de mil millones de archivos y casi 100 TB de código fuente escrito en diferentes idiomas en su sistema de gestión de versiones de desarrollo propio Piper, el popular Git de la industria, que solo se utiliza cuando el proyecto es de código abierto y requiere colaboración externa. ( Para obtener más información, consulte el artículo "¿Por qué Google almacena miles de millones de líneas de código fuente en un repositorio?"
Otro ejemplo es la plataforma Inner Source de Huawei, que alberga 110 mil millones de líneas de código fuente de Huawei. Más más de 600.000 bases de código, 60 terabytes de descargas por día y un pico de descargas simultáneas de 10.000 veces por segundo.
¿Significa esto que el repositorio único popular entre las grandes empresas es la mejor práctica? ¿Cuáles son las diferentes cuestiones que estas empresas deben considerar al optar por adoptar un enfoque de alojamiento de código?
Zou Xin explicó que, en su opinión, también es factible utilizar GVFS para crear varios repositorios independientes. El uso de un conjunto de herramientas facilita compartir código dentro de la empresa, lo que hace que sea más fácil y eficiente mover a las personas, revisar el código y mejorar las herramientas.
En segundo lugar, las grandes empresas tienen una gran cantidad de código, una larga trayectoria y muchas herramientas. Si eligen nuevas herramientas rápidamente, se producirán los siguientes problemas:
a) Algunos. Las herramientas del mercado no están diseñadas para aplicaciones a gran escala. Están diseñadas para manejar grandes cantidades de código. Habíamos utilizado un analizador de código de terceros pero fallaba al trabajar con código en Office. Una vez utilizamos una herramienta de análisis de código de terceros, pero fallaba al procesar el código de Office. La razón fue que el código de Office era demasiado grande y los desarrolladores de la herramienta no diseñaron el software para una cantidad tan grande de código.
b) Muchas herramientas han evolucionado a lo largo de la historia y tienen sus propias capacidades únicas, muchas de las cuales son relevantes para necesidades específicas dentro de una organización, todas las cuales son difíciles de lograr con herramientas externas.
Muchas herramientas se unen para formar un ecosistema de herramientas, pero si cambias solo una herramienta y haces que las demás sean incompatibles, muchos flujos de trabajo en todo el equipo se interrumpirán.
Además, Zou Xin dijo que la combinación de alojamiento de código e inteligencia artificial es la dirección del desarrollo futuro. Por ejemplo, esta combinación le dirá que hubo un problema al verificar el código anoche, o que el código verificado es similar al código de otros equipos y se recomienda su reutilización. O bien, podría indicarle que el código que está examinando se copió de la web y que los errores del código original se copiaron.
Finalmente, AI Technology Camp citó una publicación de blog de Brian Harry, ex vicepresidente de Servicios de Desarrollo de Nube de Microsoft, en 2017, tres meses después de que Microsoft lanzara VFS For Git, para compartir más sobre la plataforma. sobre VFS For Git para obtener detalles y objetivos futuros, incluida la ampliación del código fuente abierto y la mejora de su rendimiento en Microsoft. Para obtener más información sobre VFS para Git, lea atentamente este artículo:
Pago diario
/bharry/the-largest-git-repo-on-the-planeta/