En los sistemas de control de versiones , un monorepo (" mono " que significa "único" y "repo" es la abreviatura de " repositorio ") es una estrategia de desarrollo de software en la que el código de muchos proyectos se almacena en el mismo repositorio. En 2017 [actualizar], varias formas de esta práctica de ingeniería de software tenían más de dos décadas, pero el concepto general solo se había nombrado recientemente. [1] Se han realizado muchos intentos para diferenciar entre aplicaciones monolíticas y otras formas más nuevas de monorepos. [2] [3] [4]
Google , [5] Facebook , [6] Microsoft , [7] Uber , [8] Airbnb y Twitter [9] emplean monorepos muy grandes con diferentes estrategias para escalar sistemas de compilación y software de control de versiones con un gran volumen de código y cambios diarios.
Ventajas
Hay una serie de ventajas potenciales para un monorepo sobre los repositorios individuales: [5] [10]
- Facilidad de reutilización del código : se pueden abstraer funcionalidades o protocolos de comunicación similares en bibliotecas compartidas e incluirlos directamente en los proyectos, sin la necesidad de un administrador de paquetes de dependencia .
- Gestión de dependencias simplificada : en un entorno de repositorio múltiple donde varios proyectos dependen de una dependencia de terceros, esa dependencia puede descargarse o construirse varias veces. En un monorepo, la compilación se puede optimizar fácilmente, ya que todas las dependencias referenciadas existen en la misma base de código.
- Compromisos atómicos : cuando los proyectos que funcionan juntos están contenidos en repositorios separados, las versiones deben sincronizar qué versiones de un proyecto funcionan con el otro. Y en proyectos lo suficientemente grandes, administrar versiones compatibles entre dependencias puede convertirse en un infierno de dependencias . [8] En un monorepo, este problema se puede negar, ya que los desarrolladores pueden cambiar múltiples proyectos de forma atómica. [11]
- Refactorización de código a gran escala : dado que los desarrolladores tienen acceso a todo el proyecto, los refactores pueden garantizar que todas las partes del proyecto continúen funcionando después de una refactorización.
- Colaboración entre equipos : en un monorepo que utiliza dependencias de origen (dependencias que se compilan desde el origen), [9] los equipos pueden mejorar los proyectos en los que trabajan otros equipos. Esto conduce a una propiedad de código flexible.
Limitaciones y desventajas
- Pérdida de información de versión : aunque no es obligatorio, algunas compilaciones de monorepo usan un número de versión en todos los proyectos del repositorio. Esto conduce a una pérdida de versiones semánticas por proyecto . [12]
- Falta de control de acceso por proyecto : con repositorios divididos, se puede otorgar acceso a un repositorio según las necesidades. Un monorepo permite el acceso de lectura a todo el software del proyecto, posiblemente presentando nuevos problemas de seguridad. [13] Tenga en cuenta que existen sistemas de control de versiones en los que esta limitación no es un problema. Por ejemplo, cuando se usa Subversion , es posible descargar cualquier parte del repositorio (incluso un solo directorio), y la autorización basada en la ruta se puede usar para restringir el acceso a ciertas partes de un repositorio.
- Se necesita más almacenamiento de forma predeterminada : con los repositorios divididos, solo obtiene el proyecto que le interesa de forma predeterminada. Con un monorepo, verifica todos los proyectos de forma predeterminada. Esto puede ocupar una cantidad significativa de espacio de almacenamiento. Si bien todos los sistemas de control de versiones tienen un mecanismo para realizar una comprobación parcial, [14] [15] [16] hacerlo anula algunas de las ventajas de un monorepo.
Desafíos de escalabilidad
Las empresas con grandes proyectos se han encontrado con obstáculos con los monorepos, específicamente en lo que respecta a las herramientas de construcción y los sistemas de control de versiones. [6] El monorepo de Google, que se especula que es el más grande del mundo, cumple con la clasificación de un sistema de gran escala [5] y debe manejar decenas de miles de contribuciones todos los días en un repositorio de más de 80 terabytes. [17]
Software de control de versiones de escala
Las empresas que utilizan o cambian a un software de control de versiones existente encontraron que el software no podía manejar de manera eficiente la cantidad de datos necesarios para una gran monorepo. Facebook y Microsoft optaron por contribuir o bifurcar el software de control de versiones existente Mercurial y Git respectivamente, mientras que Google finalmente creó su propio sistema de control de versiones.
Durante más de diez años, Google había confiado en Perforce alojado en una sola máquina. En 2005, los servidores de compilación de Google podían bloquearse hasta 10 minutos a la vez. Google mejoró esto a 30 segundos – 1 minuto en 2010. [18] Debido a problemas de escala, Google finalmente desarrolló su propio sistema de control de versiones distribuido interno llamado Piper. [5]
Facebook tuvo problemas de rendimiento con el sistema de control de versiones Mercurial e hizo contribuciones iniciales al cliente, [19] y en enero de 2014 lo hizo más rápido que una solución de la competencia en Git. [20]
En mayo de 2017, Microsoft anunció que prácticamente todos sus ingenieros de Windows utilizan un monorepo de Git. [7] En la transición, Microsoft hizo contribuciones sustanciales al cliente Git para eliminar el acceso a archivos innecesarios y mejorar el manejo de archivos grandes con Virtual File System para Git . [21]
Software de construcción de escala
Pocas herramientas de compilación funcionan bien en un monorepo, [9] y los flujos en los que las compilaciones y las pruebas de integración continua de todo el repositorio se realizan en el momento del registro causarán problemas de rendimiento. [12] [13] Sistemas de compilación de gráficos dirigidos como Buck , Bazel , Pants y Por favor, resuelva esto compartimentando compilaciones y pruebas en el área activa de desarrollo. [1]
Twitter comenzó el desarrollo de Pants en 2011, ya que tanto Buck de Facebook como Bazel de Google eran de código cerrado en ese momento. [22] Pantalones de código abierto de Twitter en 2012 bajo la licencia Apache 2.0. [23]
Por favor, un sistema de compilación basado en Go fue desarrollado en 2016 por Thought Machine, quien también se inspiró en Bazel de Google y no estaba satisfecho con Buck de Facebook. [24]
Bazel, Buck, Pants y Please utilizan el mismo lenguaje de compilación de Starlark (anteriormente Skylark), un lenguaje específico de dominio basado en Python .
Algunas herramientas especializadas de compilación de monorepo, como Lerna, resuelven la búsqueda de dependencias duplicadas, pero carecen de capacidades gráficas dirigidas. [13]
Bit , una herramienta integrada y de gestión de monorepo de código abierto presentada en 2018, resuelve compilaciones basadas en gráficos y resolución de dependencias para proyectos de varios componentes.
Referencias
- ^ a b Hammant, Paul; Smith, Steve. "Desarrollo basado en troncales" . desarrollo basado en el tronco . Consultado el 24 de julio de 2018 .
- ^ https://medium.com/@brockreece/from-monolith-to-monorepo-19d78ffe9175
- ^ https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
- ^ https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9
- ^ a b c d Levenberg, Rachel Potvin, Josh (julio de 2016). "Por qué Google almacena miles de millones de líneas de código en un solo repositorio" . Comunicaciones de la ACM . Consultado el 20 de julio de 2018 .
- ^ a b GOODE, DURHAM; Lluvia. "Escalando Mercurial en Facebook - Código de Facebook" . código fb . Consultado el 24 de julio de 2018 .
- ^ a b Lardinois, Frederic (24 de marzo de 2017). "Microsoft ahora usa Git y GVFS para desarrollar Windows" . TechCrunch . Consultado el 20 de julio de 2018 .
- ^ a b Aimee Lucido (7 de abril de 2017). Día de la tecnología de Uber: Monorepo a Multirepo y viceversa . Consultado el 24 de julio de 2018 .
- ^ a b c Dorothy Ordogh (5 de abril de 2018). Pantalones y Monorepos . Consultado el 24 de julio de 2018 .
- ^ Brousse, Nicolas. "El tema del monorepo y polyrepo en las grandes empresas" . Biblioteca digital ACM . Consultado el 7 de septiembre de 2019 .
- ^ Santacroce, Ferdinando; Olsson, Aske; Voss, Rasmus; Narebski, Jakub (2016). Git: Dominar el control de versiones . Packt Publishing Ltd. pág. 756. ISBN 9781787122796.
- ^ a b Farina, Matt. "Peligros de los proyectos de Monorepo - DZone DevOps" . DZone . Consultado el 20 de julio de 2018 .
- ^ a b c 点 融 黑帮 (16 de agosto de 2017). "浅谈 monorepo" [Hablando de monorepo]. Sohu (en chino) . Consultado el 20 de julio de 2018 .
- ^ git clon parcial
- ^ Libro Svn: Directorios dispersos
- ^ Perforce: Clon
- ^ Metz, Cade (16 de septiembre de 2015). "Google tiene 2 mil millones de líneas de código, y todo está en un solo lugar" . CON CABLE . Consultado el 20 de julio de 2018 .
- ^ Bloch, Dan. "Aún todo en un servidor: rendimiento a escala" (PDF) . Consultado el 23 de julio de 2018 .
- ^ Claburn, Thomas. "Facebook está escribiendo un servidor Mercurial en Rust. Esto no es un simulacro" . El registro . Consultado el 20 de julio de 2018 .
- ^ Blewitt, Alex (9 de enero de 2014). "Facebook hace que Mercurial sea más rápido que Git" . InfoQ . Consultado el 24 de julio de 2018 .
- ^ Brillante, Peter. "Windows cambia a Git casi completo: 8.500 confirmaciones y 1.760 compilaciones cada día" . Ars Technica . Consultado el 20 de julio de 2018 .
- ^ Mohilo, Dominik (10 de junio de 2016). "8 herramientas de construcción en Vergleich: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt - JAXenter" [8 herramientas de construcción comparadas: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt]. JAXenter (en alemán) . Consultado el 20 de julio de 2018 .
- ^ Moore, Madison (3 de mayo de 2016). "GitLab lanza correcciones de seguridad, Pants 1.0 y la integración de Sauce Labs para JIRA — Resumen de noticias de SD Times: 3 de mayo de 2016 - SD Times" . Tiempos SD . Consultado el 20 de julio de 2018 .
- ^ Ebden, Peter (diciembre de 2017). "Por favor - el sistema de construcción de la máquina del pensamiento" . Blog. Máquina del pensamiento . Archivado desde el original el 28 de diciembre de 2019.