Desde cierto tamaño de la base de código, ¿todavía tendría Git o hay soluciones más especializadas?
(También para pagar solo una parte de la base de código)
7
Git funciona para monorepos, pero tiene algunos problemas:
Google, probablemente el usuario más famoso de monorepo, desarrolló Piper para manejar sus necesidades. Pero usted no es Google, por lo que sus soluciones probablemente no sean suyas.
Una de las principales ventajas de un monorepo es que puede realizar cambios globalmente atómicos (es decir, no necesita versionar muchas cosas porque puede cambiar la persona que llama y la persona que llama en la misma confirmación). Para potenciar esto, realmente desea tener un sistema de compilación unificado que rastree las dependencias en todo el repositorio. Bazel es una extracción de código abierto del sistema de compilación de Google, Blaze, e intenta hacer eso (aunque es joven e inmaduro y le faltan muchas características que son necesarias para el uso que no es de Google). Pants es un sistema similar fuera de Twitter.
Si está creando toneladas de código cuando realiza un cambio tan atómico, entonces probablemente también desee una granja de compilación que le permita hacer eso no en su máquina local. Del mismo modo, necesitará un poderoso sistema de CI para manejar las pruebas en ejecución en todo mientras actualiza.
La respuesta es: un poco de ambos. Para satisfacer las restricciones de "usar git" y "administrar una vasta base de código", Microsoft desarrolló un nuevo sistema de archivos (anteriormente usaban una variante de Perforce llamada SourceDepot). Es de código abierto pero no tengo experiencia personal en usarlo.
¿Por qué quieres un monorepo? La razón más obvia es que puede modificar una API y todas las personas que llaman de esa API en una confirmación atómica. También hay ventajas de poder hacer una git logbúsqueda en todo el código base ...
Las opiniones difieren sobre qué es una base de código grande. Si habla de una empresa con 100 ingenieros, diría que Git aún debería ser capaz de manejarlo. Ha sido desarrollado para las necesidades del kernel de Linux, que no es un proyecto pequeño por sí solo.
Independientemente de la forma en que almacene el repositorio, puede tener problemas. Por ejemplo, si está trabajando en una gran base de código Java y está utilizando herramientas como Eclipse o IntelliJ, utilizarán más memoria y, en general, se volverán más lentas.
Por otro lado, tener la opción de operar en todo el código a la vez (por ejemplo, al aplicar refactorización o transformaciones de código fuente) es una de las principales ventajas de los repositorios monolíticos.
Cuando pregunta si necesita herramientas especializadas, luego sube un cierto tamaño de código, la respuesta es sí. Según Google, que posiblemente tenga la mayor base de código C ++ del mundo, todas las herramientas disponibles (de código abierto o comerciales) no cumplieron con sus requisitos. Terminaron desarrollando un sistema interno llamado Piper:
Si lo entiendo correctamente, la "necesidad" de un monorepo es simplemente la necesidad fundamental de un esquema de control de versiones único / coherente aplicado a un proyecto de software que contiene múltiples componentes / subproyectos poco relacionados que pueden / podrían ser administrados / versionados de forma independiente en repositorios separados.
Similar, si lo desea, con la necesidad de usar un repositorio fuente regular para proporcionar un esquema de versiones único / coherente para una multitud de archivos fuente, cada uno con su propio historial de modificaciones independiente.
Usar una solución monorepo real es definitivamente una, pero en mi humilde opinión, no es la única forma de abordar esta necesidad.
Otro enfoque posible es usar un repositorio de proyecto paraguas que contenga uno o más archivos de manifiesto con la versión exacta de cada uno de los repositorios de componentes de proyecto individuales.
Incluso si los repositorios de componentes tienen sus versiones modificadas por compromisos independientes, no atómicos, el proyecto en sí se puede administrar de manera coherente simplemente combinando todos los cambios relacionados con la versión del repositorio de componentes en un solo compromiso para los archivos de manifiesto en el repositorio general.
Tal enfoque tiene varias ventajas sobre la migración a una solución monorepo real: